Summarizer

Account security failures

Discussion of how the maintainer's npm account was hijacked despite 2FA requirements, with speculation about token theft or phishing

← Back to Axios compromised on NPM – Malicious versions drop remote access trojan

The recent hijacking of a lead axios maintainer's npm account underscores the inadequacy of traditional TOTP-based security against sophisticated phishing and token theft, especially when bypass tokens allow attackers to circumvent standard CI/CD pipelines. Commenters argue that this incident is part of a broader "chain of compromise" across major packages like Trivy and LiteLLM, emphasizing the urgent need for mandatory hardware-based authentication and OIDC Trusted Publishing to eliminate stealable secrets. The discussion also highlights a troubling pattern of maintainer negligence, noting that suspicious activities—such as a flurry of deleted issues used as a distraction—could have been caught sooner with better operational security. Ultimately, the community remains divided over whether the solution lies in stricter package manager controls or a more fundamental reduction of dependency trees in favor of native platform features like fetch.

38 comments tagged with this topic

View on HN · Topics
Jia Tan
View on HN · Topics
In this case, the author's NPM account was taken over, email address changed to one the attacker controls, and the package was manually published. Since the attacker had full control of the NPM account, it is game over - the attacker can login to NPM and could, if they wanted, configure Trusted Publishing on any repo they control. Axios IS using trusted publishing, but that didn't do anything to prevent the attack since the entire NPM account was taken over and config can be modified to allow publishing using a token.
View on HN · Topics
Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).
View on HN · Topics
https://docs.npmjs.com/configuring-two-factor-authentication > Important: Publishing to npm requires either: Two-factor authentication (2FA) enabled on your account, OR A granular access token with bypass 2FA enabled
View on HN · Topics
I'm assuming the author must have been grandfathered in to TOTP?
View on HN · Topics
TOTP although venerable was better than no second factor at all.
View on HN · Topics
TOTP isn't phishing resistant
View on HN · Topics
No it's not but it's better than nothing. Don't let the perfect be the enemy of the good.
View on HN · Topics
It's not much better than nothing. It basically solves "I reused my password across sites" exclusively, that's it. If you use a unique password it's questionable if it adds any value at all.
View on HN · Topics
TOTP seems effectively useless for npm so that seems fine to me
View on HN · Topics
Well, that sucks! It’ll be interesting to learn how they obtained a valid second factor or 2FA bypass; that will inform the next round of defenses here.
View on HN · Topics
One wonders if Microsoft/npm.js should allow new packages to be published immediately following an account email address change? I mean changes to email address are already recognized as potential attack vectors, so emails are sent to the old address warning of potential account take over. But this seems to have been done at night, so the warning email would not be seen yet. Even so a new package could be published and served to the world immediately. Unless I misunderstand something about the facts this would indicate an extreme lack of imagination in the people at Microsoft who already went through several cycles of hardening the service against supply chain poisoning attacks.
View on HN · Topics
How much do you want to bet me that the credential was stolen during the previous LiteLLM incident? At what point are we going to have to stop using these package managers because it's not secure? I've got to admit, it's got me nervous to use Python or Node.js these days, but it's really a universal problem.
View on HN · Topics
More like the Trivy incident (which led to the compromise of LiteLLM).
View on HN · Topics
The postinstall script vector is getting all the attention, but IMO the scarier part is how the attacker chain works: compromise one package's credentials, use that access to pivot to the next target. Trivy -> LiteLLM -> now potentially axios. Each compromised package becomes a credential harvester for the next round.\n\nThe min-release-age configs (now in npm, pnpm, bun, uv) are a good start, but they only work as herd immunity — you need enough early adopters installing fresh releases to trigger detection before the 7-day window expires for everyone else. It's basically a bet that security researchers will catch it faster than your cooldown period.\n\nFor Node specifically: if you're still using axios for new projects, it's worth asking why. Native fetch has been stable in Node since v21. One less dependency in your tree is one less attack surface.
View on HN · Topics
Has anyone else noticed there was a recent sudden flurry of 3000 deleted issues on axios/axios? The jump happened on March 23. Was this a first sign of compromise? Or just coincidence of an AI agent going rogue. There are pretty much exactly 3000 deleted issues, with the range starting at https://github.com/axios/axios/issues/7547 (7547) and ending at https://github.com/axios/axios/issues/10546 (10546 which is 7547+2999) Maybe just a coincidence but they have cubic-dev-ai edit every single PR with a summary. And that bot edits PR descriptions even for outside contributors.
View on HN · Topics
Maintainer replied here https://github.com/axios/axios/discussions/10612 > nope this was just someone bombing the repo throught the API it seemd > i then just closed and deleted them with a script.. seems it is happening with a couple repos, blocked the users who were doing this I think it could well have been the attacker trying to hiding any notifications of suspicious activity (email address changed, suspicious login) in the flurry of issue related emails.
View on HN · Topics
It's not there isn't good libraries everywhere. It just the practice around NPM that people are appalled with. It's all about lowering the barrier for developers, even in spite of security and quality.
View on HN · Topics
A lot of libraries are maintained by a single person.
View on HN · Topics
Are those the ones typically involved in supply chain attacks? There are no perfect solutions; but, let's be reasonable.
View on HN · Topics
Actually, yes, they are the prime targets: https://en.wikipedia.org/wiki/Npm_left-pad_incident or seemingly https://en.wikipedia.org/wiki/XZ_Utils_backdoor as well.
View on HN · Topics
xz has dozens of contributors and two active maintainers. It was the actual example I was thinking of. The code was submitted by a third party and not a result of a developer machine compromise. left pad wasn't a security incident. It was a capitalism incident.
View on HN · Topics
There's a package manager discussion, but the bit that stands out to me is that this started with a credential compromise. At some point when a project gets big enough like axios, maybe the community could chip in to buy the authors a couple of YubiHSM or similar. I wish that _important keys live in hardware_ becomes more standard given the stakes. Dealing with dependencies is another question; if it's stupid stuff like leftpad then it should be either vendored in or promoted to be a language feature anyway (as it has been).
View on HN · Topics
The frustrating thing here is that axios versions display on npmjs with verified provenance. But they don’t use trusted publishing: https://github.com/axios/axios/issues/7055 - meaning the publish token can be stolen. I wrongly thought that the verified provenance UI showed a package has a trusted publishing pipeline, but seems it’s orthogonal. NPM really needs to move away from these secrets that can be stolen.
View on HN · Topics
> Both versions were published using the compromised npm credentials of a lead axios maintainer, bypassing the project's normal GitHub Actions CI/CD pipeline. Doesn’t npm mandate 2FA as of some time last year? How was that bypassed?
View on HN · Topics
Apparently it's possible to create access tokens that bypass 2FA. Might've been this. https://docs.npmjs.com/creating-and-viewing-access-tokens
View on HN · Topics
https://docs.npmjs.com/trusted-publishers/#recommended-restr... This helps mitigate spear phished privileges employees pushing hacked npm packages entirely.
View on HN · Topics
So the root cause was again a developer's opsec. For improving things, I haven't seen many new initiatives on that side (beyond 2FA, but even that seems unenforced in these repositories, I reckon).
View on HN · Topics
Not at all, it was a regular maintainer account that was hijacked (probably through phishing) and used to push a malicious payload, not a threat actor posing as a contributor and adding a backdoor like in the Jia Tan case.
View on HN · Topics
I use Jia Tan as a figurehead for malicious maintainers. This clearly was a targeted hack. Does it really matter how long it took to get the job done?
View on HN · Topics
I'd argue this has not much in common with Jia Tan apart from both being supply chain attacks, there is no malicious maintainer here, a trusted maintainer had their account taken over. I guess the end result is the same, a malicious package pushed by an account that was thought to be trusted, but I think the Jia Tan case is worth being looked at differently than just simple account takeover.
View on HN · Topics
It's just a longer backstory. All the same in the end. Hackers targeted a popular package. The lead maintainer was compromised. The pattern fits. There will be more of these.
View on HN · Topics
> published manually via a stolen npm access token with no OIDC binding and no gitHead So this and litellm one would’ve been preventable by proper config of OIDC Trusted Publishers.
View on HN · Topics
Please can we just have a 2FA step on publishing? Do we really need a release to be entirely and fully automated? It won't stop all attacks but definitely would stop some of these
View on HN · Topics
This is the part that's tough — we push everyone to keep dependencies updated and automate it with Renovate or Dependabot, but that's exactly the pipeline that would have pulled this in before anyone noticed. Lockfiles and pinning help slow it down, but most teams pair those with automated update PRs which kind of negates the point. You can reduce your dependency surface area to lower the odds but one compromised maintainer on a top-10 package and none of that matters.
View on HN · Topics
I lost respect for Axios when they made a breaking change in a patch release. Digging into the root cause, I found the maintainer had approved an outside PR with an obvious AI slop PR description: https://github.com/axios/axios/issues/7059 Looks like the maintainer wasn't just careless when reviewing PRs.
View on HN · Topics
That maintainer (also the one whose creds got stolen) also has an obvious chatgpt slop profile picture on github.
View on HN · Topics
If someone from github is reading this, https://github.com/axios/axios/issues/10604#issuecomment-416... I think that jason might like if someone from github team can contact them as soon as possible. (8 minutes ago at the time of writing)