decrypted · 1 september 2026 · ransomware and cybercrime · supply chain · uk policy and law

A GitHub comment was all it took to hijack a trusted npm release

The npm package @7nohe/openapi-react-query-codegen, pulled into roughly 671,000 builds a month, spent four days this week shipping malware to anyone who installed it. Nobody stole a password to do it. They found a release workflow that would publish a new version whenever someone commented the words "npm publish" on a pull request, and it never checked who was doing the commenting.

The workflow that trusted the wrong thing

Modern npm publishing is supposed to be safer than it used to be. Instead of a long-lived secret token sitting in a repository's settings, waiting to be leaked, many projects now use "trusted publishing": GitHub issues a short-lived credential to a workflow, npm checks it came from the right repository, and the package gets a cryptographic provenance record saying so. It is a genuine improvement on the old model.

But the improvement only holds if the workflow that receives that credential is itself trustworthy. This one listened for comments on pull requests, and the moment it saw the phrase "npm publish" it checked out the pull request's code, built it and published it, all under the repository's verified identity. It never asked whether the commenter had any right to trigger a release. According to Socket's research team and a separate technical writeup from StepSecurity, an outside account opened two pull requests, added obfuscated code, then simply commented the trigger phrase. Ten malicious versions went out on 28 August, each carrying a valid, cryptographically signed provenance attestation, because the signature was true even though the authorisation behind it was fiction. The payload harvested GitHub tokens, cloud credentials and SSH keys from anyone who ran npm install.

The lesson isn't "npm is broken"

It's that a security control aimed at one failure mode (leaked long-lived tokens) can leave a different door wide open (who gets to ask for a fresh token in the first place). Provenance and signed attestations tell you a release came from the workflow it claims to. They tell you nothing about whether that workflow's own logic was sound. For any UK team running CI/CD, the practical question is not "do we use trusted publishing" but "can anything an outsider types, in a comment, an issue title or a pull request, cause a privileged job to run?" Restricting release triggers to accounts with write access, and never checking out untrusted pull request code inside a job holding a publishing credential, would have stopped this outright.

Also this week

The Cyber Security and Resilience Bill reached committee stage in the House of Lords on 1 September, its first line-by-line scrutiny since clearing the Commons. The bill brings managed service providers and, for the first time, data centres into the UK's critical infrastructure regime, and lets regulators designate specific suppliers as regulated in their own right when their failure would disrupt essential services. It also shortens incident reporting to an initial 24-hour notification, ahead of the fuller 72-hour report organisations are used to under GDPR. Royal Assent is expected by the end of the year, though the substantive duties won't bite until secondary legislation lands, likely around 2028. Worth reading alongside this week's npm incident: it is precisely the kind of digital dependency chain, MSPs, data centres, critical suppliers, the bill is trying to bring into view.

Healthcare distributor McKesson disclosed a breach this week after the extortion group ShinyHunters claimed to have taken roughly a terabyte of data, including Social Security numbers, Medicaid details and medical records, between 21 and 25 August. The group told BleepingComputer it got in by vishing McKesson employees for their Okta single sign-on credentials, then walked from Okta into Salesforce and Snowflake. No malware, no exploit, just a phone call and an SSO session with more reach than anyone had accounted for. ShinyHunters demanded $55.2 million and says McKesson never replied. It's the same playbook that has hit several large firms this year: phishing-resistant MFA on SSO, and tighter scoping of what a single sign-on session can touch across SaaS platforms, would have blunted it well before the data left the building.

Sources

If your CI/CD pipeline or third-party access controls need a second look, get in touch.

More like this

Get the next post by email: subscribe to Decrypted. Double opt-in, unsubscribe any time, or take the RSS feed.

Prefer to listen? Decrypted on Apple Podcasts, or paste the podcast feed into any app.