Poisoned npm Packages Hit AsyncAPI and Jscrambler in Back-to-Back Supply Chain Attacks

Criminals injected malware into nine widely used JavaScript packages distributed through npm between 11 July and 15 July 2025, targeting developer machines that power software built by thousands of organisations worldwide.

What Happened

Two separate open-source projects, AsyncAPI and Jscrambler, were hit within days of each other. Both attacks followed a similar playbook: steal a publishing credential, push malicious package versions, and wait for developers to install them. Supply chain attacks work because a single poisoned dependency can reach thousands of downstream applications in one move.

The affected package versions are:

• `jscrambler` 8.14.0, 8.16.0, 8.17.0, 8.18.0, and 8.20.0
• `@asyncapi/generator-helpers` 1.1.1
• `@asyncapi/generator-components` 0.7.1
• `@asyncapi/generator` 3.3.1
• `@asyncapi/specs` 6.11.2
• Secondary packages `jscrambler-webpack-plugin` 8.6.2 and `gulp-jscrambler` 8.6.2, which list the above as dependencies, may also carry the payload.

If you installed any of these versions, stop reading and start your incident response now.

How Attackers Got In

The AsyncAPI Breach: A GitHub Actions Configuration Flaw

At 05:08 UTC on 15 July 2025, an attacker submitted what looked like a routine text file change to the AsyncAPI repository. It was not routine. Buried beneath roughly 1,000 blank characters sat hidden JavaScript that exploited a known weakness in the project's GitHub Actions pipeline.

GitHub Actions is the automated system that builds and publishes code when developers submit changes for review. The configuration flaw, first reported in April 2025 and left unresolved since a proposed fix sat unreviewed since May, gave any submitted pull request full access to the repository's secret tokens. That is the equivalent of leaving a master key in the front door and inviting strangers to ring the bell.

The hidden script grabbed a service account token and used it to push malicious commits into two AsyncAPI repositories. The automated build pipeline then did exactly what it was designed to do: it compiled and published the packages to npm without any human reviewing what was inside.

The Jscrambler Breach: A Stolen Publishing Credential

The Jscrambler attack started four days earlier, on 11 July. Attackers obtained a credential that granted direct publishing rights to the Jscrambler packages on npm. Jscrambler confirmed this in its public advisory. The company has not yet disclosed how that credential was exposed.

This distinction matters. The AsyncAPI intrusion exploited a misconfigured automated pipeline. The Jscrambler intrusion required a stolen credential. Same destination, different routes.

What the Malware Does

The payload embedded in all nine packages shares code patterns with a known malware framework called Miasma. Security researchers at Socket.dev, Wiz, and Upwind analysed the samples and confirmed that the malware downloads a second-stage program targeting Linux, Windows, and macOS systems equally.

Once running, it hunts for:

• Browser-saved passwords across major browsers
• Cryptocurrency wallet extensions
• SSH keys used to authenticate into servers
• Cloud account credentials for AWS, Azure, and Google Cloud
• API keys from AI coding tools
• Messaging app session tokens for platforms including Discord and Slack

This is a comprehensive credential harvest. A single infected developer machine could hand attackers the keys to production cloud infrastructure, private code repositories, and internal communication channels simultaneously.

Which Controls Failed

Two distinct failure modes made these attacks possible, and neither required zero-day exploits.

For AsyncAPI, the root cause was a misconfigured CI/CD pipeline with an unpatched known flaw. A vulnerability disclosed in April 2025 remained open for three months. That gap gave attackers time to plan and execute a precise, low-noise intrusion. NIST's Secure Software Development Framework SP 800-218 explicitly calls for securing build environments and limiting the privileges of automated systems. Granting a pull-request workflow access to production secrets violates the principle of least privilege at a foundational level. The fix existed. It was not applied.

For Jscrambler, the failure is almost certainly weak identity hygiene around publishing credentials. Whether the token was phished, reused from a compromised account, or stored insecurely is unknown. What is clear is that a single credential granted unilateral power to publish trusted software to a global package registry, with no second factor, no peer review gate, and no anomaly alert that fired in time.

This is where human factors training becomes directly relevant. Attackers targeting developer credentials frequently rely on phishing emails, social engineering through GitHub notifications, or credential stuffing against reused passwords. A workforce trained to recognise suspicious authentication requests, handle secrets hygienically, and report anomalies quickly closes attack surface that technical controls alone cannot cover. Training developers to treat their own machines and credentials as high-value targets, not just end users, is a gap many security teams leave open. Programmes built for recognised security standards can help organisations close that gap systematically.

What Defenders Should Do Right Now

Security researchers are unambiguous: any machine that installed a poisoned version should be fully rebuilt from a clean backup. Patching or removing the package is not sufficient because the malware may have already established persistence or exfiltrated credentials.

Organisations should also:

• Audit `package-lock.json` and `yarn.lock` files across all projects for the affected version numbers listed above.
• Rotate every credential that existed on any affected developer machine, including SSH keys, cloud IAM tokens, npm auth tokens, and API keys for any integrated services.
• Review GitHub Actions configurations across all repositories and remove any workflow that grants secret access to untrusted pull requests.
• Enable npm two-factor authentication for all accounts with publishing rights, a control npm itself has supported since 2022.
• Consider implementing software composition analysis tools in your CI pipeline to flag unexpected package changes before they reach production.

The Verizon 2024 Data Breach Investigations Report found that 68 percent of breaches involved a human element, including credential misuse. Supply chain attacks are scaling that statistic into developer infrastructure. Tightening pipeline permissions is urgent. Rotating credentials is urgent. Rebuilding affected machines is urgent.

Speed matters. Credentials harvested from a developer machine do not stay idle.

For organisations assessing their security-awareness posture, the Train2Secure free trial offers a starting point to evaluate where developer-focused training fits into your programme. Transparent pricing options are available for teams of any size.