Shai-Hulud Worm Evolves, Tests New Attack on npm Developers

Cybersecurity researchers are sounding the alarm about a fresh iteration of the Shai Hulud worm that's been detected on the npm registry. This new strain shows some interesting tweaks compared to the wave observed just last month, suggesting the attackers are actively refining their methods.

The culprit this time? An npm package called "@vietmoney/react-big-calendar." According to the record, it was first uploaded to npm way back in March 2021 by a user going by "hoquocdat." Fast forward to December 28, 2025, and the package got its first update, bumping it to version 0.26.2. Since its debut, it's been downloaded 698 times, with the latest version accounting for 197 of those downloads.

The good news? Aikido, the security firm that flagged this package, says they haven't seen any major spread or infections in its wake. Fingers crossed it stays that way!

"This suggests we may have caught the attackers testing their payload," security researcher Charlie Eriksen explained. "The differences in the code suggests that this was obfuscated again from the original source, not modified in place. This makes it highly unlikely to be a copy-cat, but was made by somebody who had access to the original source code for the worm."

If you're just tuning in, the Shai-Hulud attack first surfaced in September 2025. Back then, the attackers were using trojanized npm packages to snatch sensitive data – API keys, cloud credentials, npm and GitHub tokens – and then siphon it off to GitHub repositories using those very same stolen tokens. And in the second wave in November 2025, the repositories even cheekily declared "Sha1-Hulud: The Second Coming."

But the real kicker with Shai-Hulud is its ability to hijack npm tokens. Once it has those tokens, it can grab the 100 most-downloaded packages linked to the developer, inject the same malicious code, and then push those tainted packages back to npm. That's how it turns a simple compromise into a full-blown supply chain nightmare, spreading like a digital worm.

So, what's new with this strain? Here's the rundown:

• The initial file now goes by the name "bun_installer.js," and the main payload is dubbed "environment_source.js." Sneaky!
• The GitHub repositories where the stolen secrets end up now have the description "Goldox-T3chs: Only Happy Girl."
• The files containing those secrets are named: 3nvir0nm3nt.json, cl0vd.json, c9nt3nts.json, pigS3cr3ts.json, and actionsSecrets.json.
• And, perhaps most importantly, they've ditched the "dead man switch" that would wipe data if it couldn't find any GitHub or npm tokens to abuse. That suggests they're focusing on stealth and persistence.

But wait, there's more! Other tweaks include better error handling for when TruffleHog's credential scanner times out, improvements to OS-specific package publishing, and adjustments to the order in which data is collected and stored.

Fake Jackson JSON Maven Package Delivers Cobalt Strike Beacon

In related news, Aikido also uncovered a malicious package ("org.fasterxml.jackson.core/jackson-databind") lurking on Maven Central. This one's impersonating a legitimate Jackson JSON library extension ("com.fasterxml.jackson.core"), but under the hood, it's running a multi-stage attack that ultimately drops platform-specific executables. The good news is that this package has since been removed from Maven Central.

The malicious Java Archive (JAR) file contains heavily obfuscated code that springs into action as soon as an unsuspecting developer adds the tainted dependency to their "pom.xml" file.

"When the Spring Boot application starts, Spring scans for @Configuration classes and finds JacksonSpringAutoConfiguration," Eriksen explained. "The @ConditionalOnClass({ApplicationRunner.class}) check passes (ApplicationRunner is always present in Spring Boot), so Spring registers the class as a bean. The malware's ApplicationRunner is invoked automatically after the application context loads. No explicit calls required."

The malware then hunts for a file named ".idea.pid" in the current working directory. This filename isn't random – it's designed to blend in with IntelliJ IDEA project files. If the file exists, the malware assumes another instance is already running and quietly exits.

Next, the malware checks the operating system and reaches out to an external server ("m.fasterxml[.]org:51211") for an encrypted response. This response contains URLs pointing to payloads tailored to the specific operating system. The payload turns out to be a Cobalt Strike beacon, a legitimate tool for simulating attacks that can, unfortunately, be abused for post-exploitation and command-and-control.

On Windows machines, it's set to download and run a file called "svchosts.exe" from "103.127.243[.]82:8000," while macOS systems get a payload named "update" from the same server.

Further digging revealed that the typosquatted domain fasterxml[.]org was registered through GoDaddy on December 17, 2025 – just a week before the malicious Maven package was discovered.

"This attack exploited a specific blind spot: TLD-style prefix swaps in Java's reverse-domain namespace convention," Eriksen pointed out. "The legitimate Jackson library uses com.fasterxml.jackson.core, while the malicious package used org.fasterxml.jackson.core."

Aikido says the core issue is Maven Central's inability to catch copycat packages that use similar prefixes to trick developers into downloading them. They're urging the package repository maintainers to consider flagging such packages for review and to maintain a list of high-value namespaces, subjecting any packages published under similar-looking namespaces to extra scrutiny to ensure they're legitimate.