Imagine you're quietly sipping your coffee, coding away in your favourite editor, when suddenly a tiny nasty worm sneaks into your codebase via a seemingly innocent npm package. This is pretty much what happened in September 2025 when a self-propagating malicious package campaign (nick-named “Shai‑Hulud”) infected dozens of packages in the npm registry. Aikido Security have now discovered a more sophisticated and far more destructive version. This new wave, which the attackers call “The Second Coming,” is not just a repeat - it’s an escalation.
What happened? (First Wave Recap)
- Attackers compromised one or more trusted maintainer accounts on npm (via phishing or similar means).
- They published malicious versions of packages that injected a bundle.js script to scan for secrets on developer machines or CI/CD environments (GitHub tokens, npm tokens, AWS keys) and exfiltrate them.
- The payload even behaved like a “worm” - once a maintainer account was hit, the attacker used it to publish further infected versions of other packages maintained by the same account, thus propagating downward into the dependency tree.
On the flip side, defenders such as Cloudflare’s “Page Shield” system claim they could detect the malicious JavaScript in this incident via ML and structure-based scans, and that for their clients it became “a non‐event” thanks to detection and rapid patching.
The Second Wave: What’s New and Why It’s Worse
The latest attack described by Aikido Security shows significant changes - all designed to spread faster, hide better, and cause more damage.- Instead of relying on a simple injected script, the malware now installs Bun via setup_bun.js and then uses it to run bun_environment.js, which contains the true malicious payload.
- Stolen credentials are no longer shared in a single, fixed GitHub repository - the worm now creates a randomly named repo for each victim to hide its tracks.
- Propagation capacity has been significantly expanded: it now attempts to infect up to 100 npm packages, a sharp increase from the ~20 packages seen in the previous wave.
Even though this started in the JavaScript/npm ecosystem, the core lesson is universal: your dependencies can become attack vectors. If a library your mobile app or backend uses gets trojaned, the impact radiates. The worm-style behaviour means once one component is compromised, others may follow - dependency graphs are tangled, and mobile apps are not isolated from this kind of supply-chain risk.
Safeguarding Your Software Supply-Chain
Audit your dependencies now. Have you got packages updated around Sept 2025? Check version histories, see if any maintainer names changed, dig into commit logs.
- Rotate everything that might have leaked. npm tokens, GitHub tokens, cloud service keys; if they appear in build logs or have been in loosely-secured environments, treat them like they’ve been exposed.
- Lock down your supply-chain. Use lock-files, pin known-good versions, consider trusted-publisher restrictions or allow-lists for libraries your team uses.
- Scan client-side assets. If your mobile apps use JS bundles, hybrid frameworks, or embed web-views, consider runtime scanning of scripts for obfuscation, unusual network calls, or wallet-address replacements (the attackers replaced legit wallet addresses with theirs).
- Prepare for the next wave. Supply-chain attacks won’t disappear. Worm-style propagation and maintenance-account compromises are now part of the threat model.
It’s easy to think “that’s a JavaScript registry problem - nothing to do with mobile.” But the reality: any software ecosystem with dependencies, publish rights, build pipelines, and tokens is vulnerable. At Approov, we focus on protecting mobile backends, securing APIs and verifying mobile clients - but the chain doesn’t stop at your app code. It extends to every package, script and service you rely on. Treat each dependency like a mini third-party vendor, and apply the same scrutiny, controls and monitoring you would to any other critical part of your stack.
