Summarizer

Trusted publishing and OIDC

Discussion of how npm's trusted publishing via GitHub Actions OIDC could prevent attacks, noting axios uses this but the account takeover bypassed it

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

The recent axios compromise highlights a recurring vulnerability where attackers hijack maintainer accounts to manually publish malicious code via the CLI, effectively bypassing intended CI/CD pipelines. While Trusted Publishing via OIDC is designed to eliminate long-lived secrets, commenters argue that it remains insufficient if an account takeover allows an attacker to revert to token-based publishing or modify repository configurations. To address this, many advocate for npm to mandate Trusted Publishing for high-download packages and introduce strict enforcement options that prevent any manual overrides during a compromise. Beyond platform-level settings, some suggest more radical shifts, such as adopting cryptographic attestations like Sigstore or moving away from packaged artifacts entirely in favor of direct source code imports from git repositories.

15 comments tagged with this topic

View on HN · Topics
The other thing that keeps coming up is the github-code-is-fine-but-the-release-artifact-is-a-trojan issue. It really makes me question if "packages" should even exist in JavaScript, or if we could just be importing standard plain source code from a git repo. I understand why this doesn't work well with legacy projects, but it's something that the language could strive towards.
View on HN · Topics
This is where attestation/sigstore comes into play. Github has a first-party action for it and I wish more projects would use it. Regarding javascript specifically, I believe npm has builtin support for sigstore. * https://docs.github.com/en/actions/concepts/security/artifac... * https://www.sigstore.dev/ * https://github.com/actions/attest
View on HN · Topics
Their analysis was triggered by open source projects upgrading en-masse and revealing a new anomalous endpoint, so, it does require some pioneers to take the arrows. They didn't spot the problem entirely via static analysis, although with hindsight they could have done (missing GitHub attestation).
View on HN · Topics
There’s a recurrent pattern with these package compromises: the attacker exfiltrates credentials during an initial phase, then pivots to the next round of packages using those credentials. That’s how we saw them make the Trivy to LiteLLM leap (with a 5 day gap), and it’ll almost certainly be similar in this case. The solution to this is twofold, and is already implemented in the primary ecosystems being targeted (Python and JS): packagers should use Trusted Publishing to eliminate the need for long lived release credentials, and downstreams should use cooldowns to give security researchers time to identify and quarantine attacks. (Security is a moving target, and neither of these techniques is going to work indefinitely without new techniques added to the mix. But they would be effective against the current problems we’re seeing.)
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
Your account is separate from your publishing. That is, in order to go to my account to change configuration values, 2FA must be required. Publishing should be handled via something like Trusted Publishing, which would leverage short lived tokens and can integrate with cryptographic logs for publish information (ie: "Published from the main branch of this repo at this time").
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
How is it we've made it this far and we still don't have any kind of independent auditing of basic publish security on NPM? You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance).
View on HN · Topics
> You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance). Because all mainstream packages are published via CI/CD pipeline not by an MFA'd individual uploading a GZIP to npm.com
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
If GitHub, gitlab, or circleci, trusted publishing is available. No access token whatsoever.
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
This is the second major npm supply chain attack this year and the playbook is identical every time: hijack a maintainer account, publish via CLI to bypass CI/CD, inject a dependency nobody's heard of. The fix isn't better scanning (though Socket catching it in 6 minutes is impressive). The fix is npm making Trusted Publishers mandatory for packages above a download threshold. If axios can only be published through GitHub Actions OIDC, a stolen password is useless. We run a fleet of AI agents that depend on npm packages. First thing we did tonight was audit every lockfile. Clean — but only because we aggressively minimise dependencies. The real victims here are the thousands of teams who npm install with ^ ranges and never check what changed.
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
npm really needs to provide a options to set individual packages to only be publishable via trusted publishing.