NPM: aNother Pummeling, Man
Supply chain attacks have been ramping up, but NPM has had a particularly bad time this past month - what can we learn from it?
Why supply chain?
Attackers started targeting the software supply chain years ago, but things have really started ramping up lately. We see two goals related to these broad supply chain attacks: stealing cryptocurrency and stealing credentials. It is likely no coincidence that this is exactly what infostealer malware aims to do as well, and we’ve seen a distinct rise in infostealer activity over the same period.
From the attacker’s perspective, the logic is simple:
Attacks leveraging stolen creds have a high success rate
What are the best ways to steal creds?
Who has the creds we want to steal?
Developers and engineers have access to credentials that have access to critical resources, so attackers are targeting software, operating systems, and ecosystems where engineers and devs live and get work done: GitHub, MacOS, plugin libraries, and software repos.
Stealing cryptocurrency is a bonus for attackers these days, while I imagine the primary goal is stealing creds that could lead to more crypto, or a ransomware attack opportunity.
RIP Software Supply Chain
You’ve probably seen the XKCD comic musing on the fragility of the software supply chain. Despite multiple tech companies worth north of a trillion dollars US, independent and largely unsupported developers are responsible for some of the most critical software that our devices, the Internet, and economy depend on.
When this XKCD comic was originally created, we were worried about availability - what happens if this Nebraskan stops maintaining this project, or pulls a ‘left pad’ and deletes their repo? These days, this comic applies from a threat perspective as well - the lone maintainer as an attack target. Defeat the security of this one individual and attackers could gain access to the millions of systems and organizations trusting the software they’re responsible for.
That’s a LOT of pressure for someone probably not even being compensated for maintaining the software they’re targeted for (though there is more financial and operational support than at any point in the past for folks like this).
The scale of this problem works in attackers’ favor. They don’t need all of these developers to fall for a phishing email, just a few. They don’t need all software consumers to fall for a typo-squatting attack, just a few.
NPM is getting pummeled
We’ve now seen 3 major NPM attacks over the last few weeks. NPM is the most popular javascript package manager, owned by GitHub, which itself is owned by Microsoft. Why NPM? Javascript is the most popular programming language and NPM is the most popular package manager for it, making it an ideal choice for attackers to target.
The Nx s1ngularity attack
August 26, 2025
Nx NPM compromise that leveraged developers’ local AI agents to do infostealing (grabbing credentials and cryptocurrency). This was dubbed the s1ngularity NPM compromise, after the name given to repos used to steal the data. Malware was embedded in post-install scripts, which is very common - rarely do attackers add the malware to the package code itself.
The attack stole secrets and cryptocurrency from compromised systems and created a public repo within the victim’s account to exfiltrate the spoils. It also made private repos belonging to the victim public.
Initial point of compromise: a vulnerability in an Nx workflow that allowed attackers to perform command injection via pull request titles.
Novel Attack TTPs
Leveraged CLI AI agents (Claude Code, Amazon Q, Gemini), to locate and steal sensitive data. Basically, the victim’s AI agents became willing accomplices, helping the attackers achieve their goals.
Appended
sudo shutdown -h -0to login scripts, aiming to frustrate manual remediation attempts
Attacker Motives: Steal credentials, cryptocurrency, and source code.
Control Failures
Custom GitHub Actions workflow failed to validate input from untrusted sources
Outcomes
Over 1000 valid GitHub tokens compromised, dozens of cloud credentials and npm tokens, ~20k files leaked
Malware ran on an unknown number of dev/engineer systems, often via the Nx VSCode extension
Malware also executed within the context of build pipelines, like GitHub Actions
The npmjs.help phishing attack
September 8, 2025
Just a week after the Nx attack, owners of high-profile npm packages were targeted in a phishing campaign designed to steal credentials and defeat MFA. It was a typical high-pressure “do this thing or you’ll lose access to your account” scam. The campaign targeted the owners of extremely popular packages with millions of weekly downloads. Two package owners and 20 packages appeared to be affected.
Notably, this attack was spotted and shut down very quickly. Aside from creating a lot of extra work for npm maintainers, GitHub, and npm consumers, the only impact was a few hundred dollars worth of crypto stolen. The malware was designed to inject itself into the victim’s browser and intercept cryptocurrency transactions. Unlike other NPM compromises, the malicious code was appended to the package software itself rather than install scripts, likely because it needed to get loaded within the context of the web browser to steal crypto.
Initial Point of Compromise: Josh Junon and potentially other package maintainers. Josh Junon (who hilariously chose the social media handle bad-at-computer) was open about the fact that he fell for the phish and shared a ton of details about the attack that helped the industry quickly respond and shut the attacks down. The phish was unremarkable aside from the fact that it was well constructed (screenshot below) and used a very legit-looking domain, npmjs dot help. Reportedly, there was even a functional TOTP generator that victims were tricked into using.
Attacker Motives: Steal cryptocurrency - wallet drainers.
Control Failures
Phishing scam (human training)
the npmjs.help domain was only 3 days old - avoiding newly coined domains is a tried and true method for avoiding scams and attacks
Outcomes: $600 in crypto stolen and a lot of inconvenience.
The Shai Hulud npm compromise
September 16, 2025
Also named for the names attackers chose for the repositories that contained stolen artifacts, this incident appears to be linked to the Nx incident from a few weeks back. Many of the TTPs and IoCs are the same, leading many to believe it to be the same threat actor. Notably, the use of https://webhook.site links the two.
Like the Nx attack, the malware was in a post install script, targeted credentials, migrates private repos to public, uses webhook.site and victim-owned repos to exfiltrate secrets. The post install script used GitHub Action workflow scripts to execute the attacks.
Initial Point of Compromise: we don’t yet know, though the compromise of ctrl’s package tinycolor was a major inflection point.
Novel Attack TTPs: the malware in the post install script includes worm functionality, automatically replicating itself to other packages the victim has control over. This behavior led to a much higher number of packages being compromised - perhaps 500 or more.
Outcomes: At least 477 npm packages and 36 GitHub accounts were affected. At least 8 private repos were forced to public. These numbers will likely trend much higher once we have more details.
Conclusions
These are tough issues to solve. Devs/engineers aren’t fond of additional friction in CI/CD pipelines, but on the other hand, if the entire software industry depends on your package, you should probably add some additional layers of security and sanity checks, especially when updating production packages.
There are commercial security products that add wrappers around npm, GitHub Actions, and other parts of the CI/CD pipeline, looking for malicious code and other common attack TTPs. Best of all, these products are free to use for individual open source maintainers. I don’t need to name them or give out free advertising - search for the blog posts on these compromises and you’ll find them easily enough.
It’s time to assume compromise for your repos, particularly if you have any package ownership or write-access linked to your account.
While there were no disastrous outcomes that I’m aware of from these three incidents, it is important to keep in mind that it could be months or years before we hear the full story. It is entirely possible that some of these credential thefts led to large-scale ransomware attacks that have been kept quiet, or just haven’t been linked to these incidents yet.





I appreciate you, Adrian!
Good writeup! It seems like one attack group was successful and then many more saw their success and piled on.