“This status code is set by your domain's Registry Operator. Your domain is not activated in the DNS.”
Also the serverDeleteProhibited status is active, which ICANN also admits is a weird and rare one:
“This status code prevents your domain from being deleted. It is an uncommon status that is usually enacted during legal disputes, at your request, or when a redemptionPeriod status is in place.”
Edit: I didnt even notice until someone pointed out this was on the Nex-n2 repo not the rio one, now I understand the OP’s confusion!
It wasnt framed as an issue which is the norm breakage I think you’re reacting to, as in they didnt ask that the readme be updated etc, but it is common now for folks to use a project’s issue tracker to name and shame them in a place they cant easily ignore.
Whether that’s right, prosocial, or professional is up for debate (as well as if any single definition of etiquette can be expected in 2026 on an issue tracker).
But surely you can see the optics reason why someone would take their complaint to the repo directly? It pressures the maintainers to respond, it allows for a pile on from the internet, and makes any decision to lock down a hostile thread into its own kind of statement.
The maintainers should absolutely post an official response and lock the thread though, it will likely get ugly in there.
I am so incredibly stoked to see this! It is the piece which can FINALLY make it so Trusted Publishing can be safely used.
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.
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.
Not to beat the dead horse, but ths floored me when I realized it so I keep trying to shout it at the top of my lungs.
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.
I agree with you that TP is an improvement over long lived npm tokens in CI.
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
I tested approving a deployment via API last week w/ my gh cli token (well, had claude do it while I watched). Again, I really want to be wrong about this, but my testing showed that it is indeed trivial to use the default token from my gh cli to approve via API. (repo admin scope, which I have bc I am admin on said repo)
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
I have not read that blog post. But unfortunately (and I'd love to be wrong!) it doesn't matter for if a repo admin's token gets exfiled, because if you put your gates within Github, an admin repo token is sufficient to defang all of them from the API without 2fa challenge.
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 is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: changed "still not secure" to "still not enough by itself" bc that is the point I want to make)
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.
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 ¯\_(ツ)_/¯
This article only rehashes primary sources that have already been submitted to HN (including the original researcher’s). The story itself is almost a month old now, and this article reveals nothing new.
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.
I currently pay them $200/month out of my own pocket for this already, so for me it is not a free trial but subsizing my usage.
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 want to misrepresent, I am not the original author of any of these projects. I am not JDD of lodash (who is still involved and part of the TC) nor TJ Holowaychuk of express.
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.
maintaing express, lodash, cors, body-parser, etc etc