Supply Chain Attacks Are Spreading: NPM, PyPI, and Docker Hub All Hit in 2025

When npm was hit in September, it was tempting to see it as an isolated supply chain attack. A maintainer fell for a phish, popular packages were swapped out, and downstream projects scrambled. But npm wasn’t the only ecosystem in the spotlight this year. PyPI and Docker Hub both faced their own compromises in 2025, and the overlaps are impossible to ignore.

 What’s unfolding isn’t a string of unlucky breaks. It’s the same pattern repeating across ecosystems: maintainers get phished, credentials get abused, and malicious code lingers far too long. Whether you’re pulling a package from npm, installing from PyPI, or building with Docker Hub container images, the risks don’t stay confined to one registry.

At its core, a software supply chain attack is about broken trust. The code that developers rely on, whether it’s a library, an image, or a dependency buried five layers deep, isn’t always what it claims to be. That trust is fragile, and as the incidents across 2025 show, attackers are exploiting the same weak spots in multiple ecosystems.

This article connects incidents we found across npm, PyPI, and Docker Hub to highlight the shared root causes. The point isn’t to retell one breach in detail, but to explain why registry compromises aren’t flukes and why admins and developers can’t afford to rely on registries alone.

Root Cause #1: Maintainer Phishing

Phishing has always been the low-hanging fruit. In 2025, it wasn’t just effective once — it was the entry point for multiple registry breaches, all occurring close together in different ecosystems. That tells us something bigger: attackers don’t need new tricks when the old ones still work.

On npm, a maintainer of chalk and debug (widely used Node.js libraries for formatting and logging) got caught in a phish. That single slip let attackers push poisoned versions downstream, with aggregate weekly downloads in the billions pulling them in before anyone realized. Weeks earlier on PyPI, four maintainers were taken by a spoofed login page. With stolen credentials, attackers uploaded malicious packages like num2words, briefly slipping them into production pipelines.

The overlap is what matters here. Two different registries, separated by weeks, were targeted by the same tactic. That isn’t a coincidence. It’s attackers running the same play across ecosystems, proving that the path of least resistance is still the human sitting behind a maintainer account.

For sysadmins and developers, this should hit uncomfortably close to home. A maintainer account is a trust anchor. When it’s phished, the registry itself becomes the attacker’s distribution system, and there’s no obvious red flag for anyone pulling code downstream.

The real problem isn’t that phishing happened. It’s that there weren’t enough safeguards to blunt the impact. One stolen password shouldn’t be all it takes to poison an entire ecosystem. Yet in 2025, that’s exactly how it played out. This brings us to the next root cause: authentication and provenance checks that were simply not in place when they were needed most.

Root Cause #2: Weak Authentication and Provenance

Phishing isn’t the only way in. Even if every maintainer spotted every lure, registries left gaps that attackers could walk through without much effort. The problem wasn’t social engineering this time. It was how little verification stood between an attacker and the “publish” button.

Weak authentication and missing provenance were the quiet enablers in 2025. They didn’t make the same headlines as phishing, but they mattered just as much. A few examples show how little stood in the way:

• npm: before Trusted Publishing, a stolen token was enough to push code.
• PyPI: expired maintainer domains could be re-registered for account resets.
• Docker Hub: several official Debian base images carrying the XZ backdoor remained available for over a year, with derivative images continuing to spread the tainted code.

It’s clear these weren’t edge cases. Weak authentication and missing provenance let attackers publish as if nothing was wrong. Sometimes the registry itself offers the path in. When the failure is at the registry level, admins don’t get an alert, a log entry, or any hint that something went wrong. That’s what makes it so dangerous. 

The compromise appears to be a normal update until it reaches the downstream system. At LinuxSecurity, the lesson from 2025 is straightforward. If the root of trust is weak, local monitoring won’t catch the compromise until it’s too late. That’s why this class of software supply chain attacks deserves as much attention as phishing. It shifts the risk from human error to systemic design.

And once that weakly authenticated code gets in, it doesn’t always go away quickly, which leads straight into the persistence problem.

Root Cause #3: Malicious Content Persists Too Long

A supply chain attack doesn’t end when the breach is flagged — it lives on in poisoned code that stays available long after disclosure. That’s what makes persistence so dangerous: it quietly extends the life of a compromise.

Registries struggle with this because of how they’re built. Their job is distribution, not recall. Once an artifact is published, it spreads into mirrors, caches, and derivative builds. Removing the original upload doesn’t erase all the copies.

One example was XZ backdoor persistence. In 2025, official Debian base images on Docker Hub were still shipping the backdoored utility a year after disclosure. Dozens of derivative images quietly inherited the same tainted code.

From our perspective at LinuxSecurity, this isn’t about slow cleanup; it’s about architecture. Registries have no universally reliable kill switch once trust is broken. Even after removal, poisoned base images replicate across mirrors, caches, and derivative builds, meaning developers may keep pulling them in long after the registry itself is “clean.”

We also saw it with malicious npm packages. When a maintainer was phished, chalk and debug (widely used Node.js libraries for formatting and logging) were hijacked and published as malicious versions. Even though the bad releases were removed from npm within hours, billions of aggregate weekly downloads meant many builds had already integrated the poisoned code, keeping the compromise alive long after the registry fix.

That’s the multiplier effect of persistence. Once a malicious version gets pulled into production, it outlives the registry fix. Teams may still be running compromised builds today, long after the packages were “cleaned up.”

This is why persistence ranks among the most dangerous types of supply chain attacks. It turns a short-lived breach into a long tail of exposure. The registry may mark the problem as fixed, but for admins and developers, the risk continues every time an old cached copy or a derivative build that inherited the tainted code is pulled back into use.

And if poisoned code can persist for this long, the natural question is why registries take so long to detect and remove it in the first place.

Root Cause #4: Detection is Reactive, Not Proactive

Attackers don’t need weeks to cause damage. A poisoned package can move from registry to production in a matter of hours. That’s what makes detection lag so dangerous. When registries only react after the breach is public or downstream damage is already happening, prevention isn’t even on the table. What we’re left with is cleanup, and by then, the compromise has already spread.

The npm ecosystem offered the clearest warning this year. The Shai-Hulud worm wasn’t just another malware drop. It propagated through hundreds of packages before being taken down. By the time researchers documented the infections, secrets had been stolen, and CI pipelines were already compromised. That gap between compromise and detection is where the damage really happened.

PyPI showed a smaller but similar delay. After maintainers were phished, malicious packages were uploaded and briefly available to anyone installing them. They were eventually pulled, but only after discovery. There was no point-of-publish block, no mechanism that recognized a stolen token for what it was.

Docker Hub fell into the same pattern. The persistence of XZ-tainted Debian images was only discovered when external researchers brought it to their attention. The registry didn’t surface the problem itself, and users continued to pull compromised content in the meantime.

From our perspective at LinuxSecurity, this is why detection deserves its own focus. A weak password or poisoned base image is bad enough, but the real story is how long attackers get to operate before registries notice. In practice, that means defenders aren’t stopping supply chain cyber attacks; they’re inheriting them.

And if delays like this are the norm, then the question shifts. It’s not only about why poisoned artifacts stick around, but why registries so often miss them in the first place.

Systemic Weaknesses (Why This Isn’t a Fluke)

From our research, the critical pattern isn’t the specific exploit in npm or PyPI or Docker Hub, but that each registry failed at the same structural points. When you map them side by side, the overlap is impossible to ignore.

To us at LinuxSecurity, the real vulnerability isn’t phishing emails or stolen tokens — it’s the way registries are built. They distribute code without embedding security guarantees. That design ensures supply chain attacks won’t be rare anomalies, but recurring events.

Takeaways for Admins and Developers

The incidents across npm, PyPI, and Docker Hub show the same pattern. Registries move code quickly, but they don’t secure it. When new policies appear, they usually come late and unevenly, leaving defenders to clean up the mess. That shifts the real responsibility onto the teams consuming these artifacts.

For admins and developers, this is the practical side of supply chain cybersecurity. A registry compromise doesn’t appear to be a breach when it reaches you; it looks like a normal update. That means every download has to be treated as suspect, even if it comes from an “official” source.

So, how do we suggest preventing supply chain attacks in day-to-day operations? Start with controls you can enforce yourself:

• Verify artifacts with signatures or provenance tools.
• Pin dependencies to specific, trusted versions.
• Generate and track SBOMs so you know exactly what’s in your stack.
• Scan continuously, not just at the point of install.

These steps won’t block every risk, but they give you the edge in a race where attackers still move faster than registries. The only safe assumption is that the code you consume may already be compromised, and your defenses need to reflect that.