If you were hoping for a relaxing summer break without a software supply chain attack, the latest news will disappoint. Early on July 14th OpenSourceMalware identified that an attacker compromised AsyncAPI repositories and used the projects’ own CI/CD pipelines to publish four malicious npm packages. Together these packages see more than 2.9 million downloads a week, with @asyncapi/specs accounting for roughly 2.7 million of them.

Here’s what we know so far, why so many conventional defenses would have let these packages through, and what a governed control layer does about it.

How the attack happened

The attacker exploited a misconfigured GitHub Actions workflow in the asyncapi/generator repository to steal a highly privileged token belonging to the project's automation account. They used that token to push a commit that triggered the release pipeline, which published trojanized packages to npm under the trusted @asyncapi namespace. A second repository in the same organization was then used to publish the highest-impact package, @asyncapi/specs.

For a full breakdown of the attack, Wiz’s post provides an excellent overview.

This attack has two details that matter for what follows. First, the malicious code was hidden inside otherwise legitimate source code and it ran on package import rather than install. Second, once triggered it installed a persistent credential stealer that swept for browser passwords, SSH keys, npm and GitHub tokens, and cloud credentials.

Why security scanners may have allowed these packages through

None of the usual signals a build environment relies on would have stopped these downloads.

• The name and the source were legitimate: The packages came from the correct namespace, published through the project’s real release pipeline using a real maintainer token.
• The versions were brand new, so no intelligence existed yet: At the moment of publication, no advisory named these versions as malicious. A team pulling @asyncapi/specs@latest in the minutes or hours after publication would have received a clean bill of health from every feed, because the community hadn't identified the compromise yet. This is the zero-hour window, and pulling directly from a public registry means running straight into it.
• Install-time scanning looked in the wrong place: Many defenses focus on preinstall and postinstall hooks, because that's where supply chain payloads have historically lived. This payload executed on import instead. Tooling watching only the install lifecycle would have seen nothing.
• The code was hidden from human review: Even a developer inspecting the source would have had to scroll past hundreds of blank spaces to find the payload.

This pattern is consistent across many of this summer’s software supply chain attacks. When packages flow directly from a public registry into a build without a control point in between, a compromise can reach your environment because nothing was positioned to intercept it.

What security teams can do now

• Check your lockfiles for the compromised versions
  • @asyncapi/generator - v3.3.1
  • @asyncapi/generator-helpers - 1.1.1
  • @asyncapi/generator-components - 0.7.1
  • @asyncapi/specs - 6.11.2
  • @asyncapi/specs - 6.11.2-alpha.1
• Assume secrets are exposed on any developer machine or CI runner that installed an affected version. Rotate npm tokens, GitHub tokens, SSH keys, AWS access keys, and browser stored credentials.
• Audit CI/CD secrets for any pipeline that ran npm install during the compromise window.

The steps above are helpful but reactive, taking place only after a malicious package is already inside your environment. These steps also don’t scale, relying on someone to spot the advisory, trace which builds pulled what, and rotate the right credentials before an attacker uses them.

Artifact management platforms can add a control layer ahead of package pulls to prevent some of these dangers from ever becoming present. Simply put, when detection and response move upstream and run automatically, compromised packages are stopped or contained upstream.

Cloudsmith is that governed control layer. Every package that enters a Cloudsmith workspace, whether proxied from a public registry or published internally, is evaluated against policies that assess risk, and permitted or blocked before it reaches a developer machine or CI pipeline. Two capabilities map directly to how the AsyncAPI attack played out.

With Cloudsmith as a private registry proxying npm, PyPI, Maven Central, and others, npm install routes through Cloudsmith rather than straight to the public registry. Every package, including transitive dependencies, flows through one control point you can see and govern. Without that layer, there's no place to intercept a poisoned @asyncapi/specs on its way into a build.

Cloudsmith offers cooldown policies to help businesses vet new packages for risk: they set a minimum age a package must reach before it can be used. That closes the window most of these attacks target, the gap between a malicious package going live and an advisory going out, Cloudsmith’s cooldown policies are enforced at the index level. Versions younger than the age you set are filtered out before the package manager ever sees them, with builds resolving cleanly to the next available version.

Cooldown with Cloudsmith this summer. Relax knowing that Cloudsmith checks every open source dependency your team pulls, keeping malware like this out of your artifacts. Talk to our team today about defending against malicious package attacks.