This releases a lot of pressure on maintainers, who until now needed to be experts in securing CI infrastructure in order to reduce the risks inherent in TP being a step backwards compared to local publishing with a second factor.

Will it be perfect? No, Im inclined to think nothing is perfectly secure. But I believe this will go a long way towards improving our ecosystem’s posture against at least the attack vectors we are seeing today.

Comments URL: https://news.ycombinator.com/item?id=48215575

Points: 4

# Comments: 1

They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache

The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

There is no gate you can put on a Trusted Publisher setup in github which requires 2fa to remove. Full stop. 2fa on github gates some actions, but with a token with the right scope you can just disable the gating of workflow-runs-on-approve, branch protection, anything besides I think repo deletion and renaming.

And in my experience most maintainers will have repo admin perms by nature of the maintainer team being small and high trust. Your point is well taken, however, that said stolen token does need to have high enough privileges. But if you are the lead maintainer of your project, your gh token just comes with admin on your repo scope.

However, the threat Im most afraid of still does involve dev environment compromise. Because if your repo admin gets their token stolen from their gh cli, they can trivially undo via API (without a 2fa gate!) any github level gate you have put in place to make TP safe. I want so badly to be wrong about that, we have been evaluating TP in my projects and I want to use it. But without a second factor to promote a release, at the end of the day if you have TP configured and your repo admin gets pwned, you cannot stop a TP release unless you race their publish and disable TP at npm.

TP is amazing at removing long lived npm tokens from CI, but the class of compromise that historically has plagued the ecosystem does not at all depend on the token being long lived, it depends on an attacker getting a token which doesnt require 2fa.

I am begging for someone to prove me wrong about this, not to be a shit, but because I really want to find a secure way to use TP in lodash, express, body-parser, cors, etc

Nothing in this link [1] proves what I said, but it is the test repo I was just conducting this on, and it was an approval gated GHA job that I had claude approve using my GH cli token

I also had claude use the same token to first reconfigure the enviornment to enable self-approves (I had configured it off manually before testing). It also put it back to self approve disabled when it was done hehe

[1] https://github.com/jonchurch/deploy-env-test/actions/runs/25...

That is why I want 2fa before publish at the registry, because with my gh cli token as a repo admin, an attacker can disable all the Github branch protection, rewrite my workflows, disable the required reviewers on environments (which is one method people use for 2fa for releases, have workflows run in a GH environment whcih requires approval and prevents self review), enable self review, etc etc.

Its what I call a "fox in the hen house" problem, where you have your security gates within the same trust model as you expect to get stolen (in this case, having repo admin token exfiled from my local machine)

it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

different times, different threat model I suppose

Going to Trusted Publishing / pipeline publishing removes the second factor that typically gates npm publish when working locally.

The story here, while it is evolving, seems to be that the attacker compromised the CI/CD pipeline, and because there is no second factor on the npm publish, they were able to steal the OIDC token and complete a publish.

Interesting, but unrelated I suppose, is that the publish job failed. So the payload that was in the malicious commit must have had a script that was able to publish itself w/ the OIDC token from the workflow.

What I want is CI publishing to still have a second factor outside of Github, while still relying on the long lived token-less Trusted Publisher model. AKA, what I want is staged publishing, so someone must go and use 2fa to promote an artifact to published on the npm side.

Otherwise, if a publish can happen only within the Github trust model, anyone who pwns either a repo admin token or gets malicious code into your pipeline can trivially complete a publish. With a true second factor outside the Github context, they can still do a lot of damage to your repo or plant malicious code, but at least they would not be able to publish without getting your second factor for the registry.

The guidelines talk about primary sources and story about a story submisisons https://news.ycombinator.com/newsguidelines.html

Creating a new URL with effectively the same info but further removed from the primary source is not good HN etiquette.

Plus this is just content marketing for the ai security startup who posted it. Theyve added nothing, but get a link to their product on the front page ¯\_(ツ)_/¯

The researcher who first reported the vuln has their writeup at https://adnanthekhan.com/posts/clinejection/

Previous HN discussions of the orginal source: https://news.ycombinator.com/item?id=47064933

https://news.ycombinator.com/item?id=47072982

I love these questions bc they both can be answered with some slight heuristics, and they are quite surprising!

As of January 2026, there were > 13k npm packages w/ more than 1 Million monthly downloads [1]

Answering "how many total developers does that cover" is a lot harder (more expensive, rather, as I am not going to pay for the query on Google BigQuery to answer it, not after I spent $3k by accident last time doing similar exploration in the past)

I wont try to make a SWAG about how many devs have write access across those repos, but in the npm ecosystem alone I'm comfortable saying it is an order of magnitude more than 100.

[1] - https://gist.github.com/jonchurch/1dd845f4d26823fce5590af1aa...

Agreed that $200 USD would be preferable (credits dont pay rent). My comment is directed at the strong words others have left about this being in bad faith on the whole. Even if it is, then their bad faith efforts are better than most.

Opinions here will vary, I wanted to share mine <3

I dont know what the future will look like, but IMO open source is the intersection of code and community (aka the squishy bits) and for that reason I dont think AI will make it obselete, not now nor in the future.

I maintain Express.js and Lodash, as well as a number of express direct deps (as a TC member of both Express and Lodash).

OSS has been my fulltime focus for over a year (aka Im unemployed). In 2025 I made $10 from open source, in the form of an amazon gift card for fixing a bug in another random open source project (I think they have VC money).

Call it skill issue on my part, sure valid. But having a form that says “give us your email and handle, we can easily verify your contributions, and in exchange you get $200/month of value and we ask nothing of you” is the most generous gift Ive seen.

Is it enough to fix the well known power dynamics of OSS? Of course not. Is it cheap PR for Anthropic? Yes, as is every other corporate OSS fund initiative. Im not going to give them a standing ovation and a key to the city bc they cleared the extremely low bar.

My point is that, regardless of motives, from this maintainer’s perspective this is a kind offer which is respectful of me and my time. If you fall into the camp that training on OSS is stealing, I can see why youd think that this is a slap in the face. I personally do not see it that way, as my work is a conduit for me to serve millions Ill never meet, and what they do with my labor is not a personal concern. I do what I do because the process itself has value to me.