npm and PyPI supply chain worms: what is happening, and what to actually do about it 

A package you have trusted for years can turn hostile overnight, and the version number will look completely normal. That is the reality of the supply chain attacks now hitting npm and PyPI, the two registries most of your software quietly depends on. If you build or run software-enabled medical devices, digital health products or fintech services, this is for you. The good news: you do not need to panic. A small number of sensible controls cut most of the risk, and they are the same controls that strengthen your evidence for DTAC, EU MDR and FDA submissions. 

Key Takeaways

• This is self-spreading malware. Worms in the “Shai-Hulud” family steal credentials, then use them to poison more packages automatically. The source code is now public, so this is no longer one group and will not stop soon. 

• Signed does not mean safe. Attackers have published properly signed, legitimately named packages. A valid signature or trusted name is no longer proof a version is clean. 

• Time is your cheapest defence. Most malicious versions are caught and pulled within hours to days, so not installing the moment a version appears avoids the bad one almost every time. 

• Credentials are the prize. These worms exist to harvest tokens and keys. Short-lived, tightly scoped credentials make a stolen token nearly worthless. 

• An inventory turns panic into a five-minute check. A software bill of materials (an SBOM, a list of every component in your software) lets you answer “are we affected?” quickly, and is evidence regulators and NHS buyers increasingly expect. 

What is actually happening

Modern software is assembled, not written from scratch. A single application can pull in hundreds of third-party packages from registries like npm (for JavaScript and Node.js) and PyPI (the Python Package Index), most of which pull in further packages you never chose directly. Attackers abuse that trust: they take over a legitimate, popular package and publish a tampered version, so anyone who installs it runs their code, and because installs are automated it spreads before anyone notices. The current wave began in September 2025 with Shai-Hulud, the first self-replicating malware seen in npm, and has escalated through several campaigns since. The UK’s National Cyber Security Centre (NCSC) confirmed the pattern in guidance published on 4 June 2026. 

The escalation of the Shai-Hulud worm family. Dates are first public detection. Figures from CISA, NCSC, Unit 42, Datadog, Snyk, Wiz and StepSecurity. 

Why it is getting worse, not better

Our managing director Neil put it plainly to a client recently: the attacks have worked, so attackers are motivated to do more, and because the source code is now public it is no longer one group. The summary: 

• The attacks are automated. In a single hour in May 2026, one wave published more than 600 malicious package versions. No manual review keeps pace. 

• Signatures and trusted names no longer settle it. We now have properly signed malicious packages and compromises of real, well-known projects. 

• It crosses ecosystems. The same actors have compromised legitimate Python packages on PyPI, including widely used AI tooling. If your teams use both Node.js and Python, both fronts are live. 

• The newest variants fight back. Some install a watcher that tries to delete files if it detects its stolen token being revoked. That changes how you should respond. 

What this means for regulated software

If you ship into regulated healthcare or financial markets, a compromised dependency is not only a security problem. It is a compliance problem, because the frameworks you answer to increasingly ask how you manage exactly this risk. 

Where it bites	What is now expected of you
NHS DTAC (version 2.0, in force from 6 April 2026)	The technical security domain (C3) now asks suppliers to confirm they meet the government’s Software Security Code of Practice, which covers how dependencies are introduced and maintained.
NHS Cyber Security Supply Chain Charter (2026)	From January 2026 the Charter shifted from self-assertion to evidence. NHS buyers can ask for documented proof of your controls, including an SBOM on request.
EU MDR	Security must be built into the device lifecycle and your ISO 14971 risk file. An unmanaged dependency that introduces a vulnerability is a risk you are expected to have controlled.
FDA Section 524B (for cyber devices)	Premarket submissions must include an SBOM and a plan for monitoring and patching vulnerabilities. An inadequate SBOM can lead the FDA to refuse to accept the submission.

The throughline is consistent: know what is in your software, control how it changes, and prove both. Do the security work properly and the compliance evidence is largely a by-product. For how this maps across markets, see our guide, EU MDR and NHS DTAC cybersecurity requirements for UK market entry. 

The five controls that actually move the needle

There is no single switch that makes this go away. What works is a handful of layered controls, none exotic, that line up closely with the NCSC’s June 2026 recommendations. 

The five controls, aligned with NCSC guidance published 4 June 2026 and CISA advisory AA25-266A. 

The card above is the summary. A little extra colour on each: 

• Wait before you update. In the June 2026 Red Hat compromise, most malicious versions were revoked the same day. The NCSC calls this balancing fast security patching against slow routine updates. 

• Block install scripts. This is the most common way these worms execute, yet most packages do not need it, so a default block breaks very little. 

• Scope and rotate tokens. Prefer short-lived, automatically issued credentials for build pipelines over static keys stored on disk. 

• Keep an SBOM. Generate it automatically on every build and feed it into a scanner; it doubles as compliance evidence, so the effort counts twice. 

A worked example: the cost of one missed token. In May 2026 a well-known monitoring company was hit by a compromised package and did the right thing, detecting the activity and rotating its credentials. But one build-pipeline token was missed, and the attacker used that single token to reach the company’s private source code. The lesson is not that rotation failed. It is that broad, long-lived credentials turn one missed item into a serious breach. 

Free download: the artefacts that prove you have this under control 

►  10 Core Procurement Artefacts (PDF): the most-requested artefacts, including the SBOM and vulnerability monitoring, with the minimum standard and how each maps to DTAC, EU MDR and FDA. 

►  Access to Markets, key differences and overlaps (PDF): how cyber evidence compares across DTAC, EU MDR and FDA 510(k). 

If you are not sure where you stand, the fastest way to find out is a focused conversation. We will not try to sell you a programme you do not need. 

In 30 minutes we will: 

• Sense-check how your teams currently introduce and update npm and PyPI dependencies. 

• Identify the one or two changes that would cut the most risk for the least effort. 

• Tell you honestly whether your SBOM and credential practices would stand up to an NHS or regulatory evidence request. 

• Set up a lightweight daily check, in whatever tooling you already use, that flags any of your key packages caught in a known compromise. 

FAQs

We use packages that have been around for years. Are we still at risk? 

Yes. These attacks specifically target established, trusted packages by taking over the maintainer’s account or publishing tools, so longevity and popularity are no longer reliable signals of safety. What matters is controlling how and when you adopt new versions. 

Is this only an npm problem, or does it affect Python too? 

It affects both. The same actors have compromised legitimate Python packages on PyPI, including widely used AI and developer tooling. Node.js, Python and Rust are especially exposed because they lean on large numbers of small packages, so if your teams use more than one, monitor all of them. 

A package we use has just been compromised. What do we do first? 

Isolate the affected machine from the network first, then remove the malware before rotating any exposed credentials from a separate, clean machine. Do not revoke tokens while the malware is still running, because some recent variants try to destroy data when they detect revocation. Rotate regardless, just in that order. 

About the author

Luke Hill, Senior Security Consultant, Cyber Alchemy 

Luke brings deep expertise in security consultancy, penetration testing and regulatory-aligned security for the Health and Social Care sector. He leads Cyber Alchemy’s technical and regulatory efforts in the MedTech space, supporting a broad range of MedTech companies in building resilient devices and applications that comply with complex UK, US, and EU regulations. 

Related reading 

• EU MDR and NHS DTAC cybersecurity requirements for UK market entry: what cyber evidence each market and route actually asks for, including the SBOM. 

• NCSC: Software supply chain attacks, check your dependencies: the UK national guidance this article aligns with, published 4 June 2026. 

• Medical device regulation in the UK and post-market surveillance: how ongoing monitoring obligations connect to dependency and vulnerability management.