What an npm Attack Says About the Risks of Open-Source Software

The history of open-source security is littered with examples of catastrophic failings and near misses. A crypto-malware campaign discovered in early September falls somewhere between the two. According to reports, an unidentified threat actor compromised a single npm maintainer account, and with that access, deployed malicious code across packages with over two billion weekly downloads.

It has already been described as the largest supply chain compromise in the history of npm—itself the world’s largest software registry. If this is a sign of things to come, how do corporate users of open source insulate themselves from mounting cyber risk?

What Happened to npm?

On September 8, developer and open-source maintainer Josh Junon (aka “qix”) took to social media to reveal his npm account had been compromised. He found out after said account began posting trojanised versions of popular packages such as chalk (300 million weekly downloads), debug (357 million), and ansi-styles (371 million).

The malicious code “silently intercepts crypto and web3 activity in the browser, manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user,” according to Aikido.

Junon was reportedly targeted by a sophisticated social engineering attack. The threat actors registered a typosquatting domain several days prior and used it to impersonate legitimate npm admins in a two-factor authentication reset email. Junon claimed it “looked very legitimate”.

A Lucky Escape?

In the end, the open-source community rallied round and – impressively – all malicious package versions had been taken down less than four hours later.

“Everyone works together. Information can be shared. The number of people now working on this isn’t just larger than your security team, it’s larger than your company,” said Anchore VP of security, Josh Bressers. Reports at the time suggested that the threat actors had managed to steal less than $1000 from victims’ crypto wallets, despite the potentially huge reach of the campaign.

However, that wasn’t the end of the story. Even in the short time window during which the packages were circulating in the wild, they spread far and wide. According to security vendor Wiz, 10% of cloud environments were impacted.

“During the short two-hour timeframe in which the versions were available for download, if they were incorporated into frontend builds and shipped as web assets, any browsers loading the affected website would execute a malicious payload that hooks network and wallet APIs in order to silently rewrite cryptocurrency recipients/approvals before signing, so that transactions would be diverted to attacker-controlled wallets,” the vendor claimed.

It later emerged that the threat actors also targeted other maintainers and packages, including duckdb, proto-tinker-wc, prebid-universal-creative, and prebid and prebid.js. While it’s fortunate that the malicious payload was “only” crypto-stealing malware, rather than something more serious, it’s surely a warning for the future.

Maintainers in the Crosshairs

There’s no putting the open-source genie back in the bottle. Over 6.6 trillion open-source components were downloaded in 2024, with npm accounting for 4.5 trillion requests, according to Sonatype. But it’s concerning that maintainers of hugely popular packages, often under-resourced and over-stressed, are being targeted in greater numbers. Sonatype regional VP, Mitun Zavery, likens this latest campaign to the one targeting xz Utils last year.

“We’ve seen a clear pattern emerge where threat actors target maintainers of widely used but under-resourced projects. The recent compromise of npm packages like chalk and debug mirrors what we observed with the xZ Utils backdoor attempt. In both cases, the adversary patiently built trust to gain control, showing that social engineering is now a key stage in supply chain compromise,” he tells ISMS.online.

“Industry must recognise that open-source maintainers are part of our critical infrastructure and start resourcing them accordingly with funding, security tooling, and support networks. Our work on xz Utils showed that collaborative early warning and rapid response across the ecosystem can stop these attacks before they spread.”

Assume Compromise

JFrog VP of security research, Sachar Menashe, argues that the challenge with such attacks is their speed.

“Once a trusted package is compromised, it can spread rapidly through CI/CD pipelines and across projects. A zero-trust approach is critical: no package should be trusted purely because it is popular,” he tells ISMS.online. “To mitigate these attacks, organisations should mandate two-factor authentication. This is already enforced in npm and PyPI, but not in other repositories such as Maven and NuGet.”

Ideally, packages should be vetted before they enter an organisation, with defined rules and analysis of direct and transitive dependencies in context, Menashe continues.

“Delaying upgrades also helps. In fact, our research shows that waiting at least 14 days before deploying new package versions provides a strong safeguard, as hijacked packages are almost always detected and removed within this timeframe,” he says.

Sonatype’s Zavery argues that visibility into open-source components and packages is also key.

“Organisations need to assume compromise is possible and be ready to respond by maintaining accurate software bills of materials (SBOMs), monitoring for suspicious dependency changes, and sandboxing builds,” he explains. “When we investigated the xz Utils incident, we saw how having this visibility made it possible to quickly identify and remove tainted components.”

Security standards could also help organisations, Zavery argues.

“Frameworks like ISO 27001 can help by enforcing disciplined risk management, access control, and incident response processes, but they need to be applied with a supply chain lens,” he concludes. “Embedding open-source security controls into these standards can make organisations more resilient to the kind of account takeover we’ve just seen.”

One thing is certain: these attacks will keep coming back stronger each time. Just days after this campaign landed, the first ever wormable malware hit the npm ecosystem. Whatever happens, CISOs can’t afford to have an open-source security blind spot in their organisation.