Software Supply Chain Attacks in 2026: Inside the npm and PyPI Registry Poisoning Wave

Direct answer: A software supply chain attack compromises the open-source packages, build pipelines, or maintainer accounts that modern software depends on, rather than attacking a target application directly — so a single poisoned npm or PyPI release can reach every downstream project that installs it, often without anyone noticing until well after the damage is done. It is trending because 2026 has produced an unrelenting cadence of registry compromises — roughly one major, independently confirmed campaign a month between March and July — with malicious open-source package identifications up over 1,400% between 2024 and 2025, anchored by named incidents including a 60-plus-package npm campaign tied to incomplete credential rotation, the March 26 LiteLLM PyPI compromise by the group TeamPCP, Axios releases that stayed poisoned for roughly three hours, and a May 11 coordinated attack touching more than 170 npm packages and 2 PyPI packages across ecosystems including TanStack, Mistral AI's SDK, UiPath, OpenSearch, and Guardrails AI. That cadence has turned supply chain compromise from a rare emergency into a recurring operational risk that any team shipping software with open-source dependencies now has to plan around continuously.

A Year of Monthly Registry Compromises

Modern software isn't really "written" so much as assembled. A typical web or backend application might contain a few thousand lines of code its own team actually authored, sitting on top of hundreds or thousands of open-source packages pulled in transitively through npm, PyPI, and similar registries. That arrangement is what makes software development fast — nobody rewrites an HTTP client or a date-formatting library from scratch — and it's also what makes a single compromised package disproportionately dangerous: an attacker doesn't need to breach your infrastructure directly if they can get malicious code installed inside it voluntarily, through a dependency your build process already trusts.

2026 is the year that risk stopped being theoretical and started being a monthly occurrence. Security researchers tracking the space have documented roughly one major, independently confirmed registry-poisoning campaign per month between March and July alone — not isolated incidents months apart, but a steady, recurring cadence that increasingly resembles a patch-cycle problem more than a rare-emergency one. Layered on top of that cadence is a steeper underlying trend: identifications of malicious open-source packages rose more than 1,400% between 2024 and 2025. Some of that increase reflects genuinely better detection tooling catching activity that was likely always happening beneath the surface, but even accounting for improved visibility, the volume and frequency of named, verified campaigns through 2026 shows an accelerating curve rather than a static baseline that's simply better lit than before.

What makes this particular wave different from the supply chain scares of prior years is the diversity of what's being targeted and how quickly attackers are moving. The incidents anchoring 2026's reporting span multiple ecosystems (npm and PyPI simultaneously in more than one case), multiple attack techniques (credential theft, CI/CD pipeline abuse, Git history manipulation), and multiple categories of victim package — from general-purpose HTTP libraries to AI/ML SDKs to enterprise automation tooling. That breadth is the real headline: this isn't a story about one careless maintainer or one poorly secured registry feature, it's a story about the open-source supply chain being probed everywhere at once, by multiple distinct threat actors, because the payoff for a successful compromise scales with how many downstream projects install the package — and for the most popular libraries, that number is enormous.

Anatomy of the Named 2026 Incidents

Four incidents anchor most of the 2026 reporting on this trend, and each illustrates a different failure mode worth understanding on its own terms.

The 60-Plus-Package npm Campaign and Incomplete Credential Rotation (Feb–Mar 2026)

Between February and March 2026, a multi-phase campaign compromised more than 60 npm packages, and the detail that makes it instructive rather than just alarming is what let it continue: incomplete credential rotation. After an initial compromise was identified and maintainer credentials were rotated, the rotation didn't cover every token or session that had been exposed, leaving the attacker a residual foothold to resume publishing malicious versions in a later phase. It's a reminder that "we rotated the credentials" is not automatically the same statement as "we rotated all the credentials" — a distinction that matters enormously to an attacker looking for exactly the one forgotten token that survived the cleanup.

The LiteLLM PyPI Compromise and TeamPCP (March 26, 2026)

On March 26, 2026, LiteLLM — a PyPI package used heavily in AI/ML pipelines, with roughly 3.4 million downloads a day — was compromised by a group tracked as TeamPCP. A package moving that much daily download volume represents an unusually large blast radius by itself, and LiteLLM's specific role as plumbing inside AI application stacks means the exposure wasn't confined to traditional web backends — it reached directly into the AI infrastructure layer that a growing share of 2026's software investment sits on top of.

Poisoned Axios Releases: A Three-Hour Window

Malicious versions of the widely used Axios HTTP client library were live on npm for roughly three hours before being pulled. Three hours sounds short in ordinary terms, but it's a long time relative to how automated build systems actually work: continuous integration pipelines that pull "latest" dependency versions on every run, and package managers configured to accept minor version bumps automatically, can easily install a poisoned release and ship it into a production build well inside a three-hour window, entirely without a human in the loop making a conscious decision to trust the new version.

The May 11, 2026 Mass Attack: 170+ npm and 2 PyPI Packages

On May 11, 2026, a coordinated attack compromised more than 170 npm packages and 2 PyPI packages in a single campaign, spanning ecosystems as varied as TanStack, Mistral AI's SDK, UiPath, OpenSearch, and Guardrails AI — one of the largest registry-poisoning events observed to date. The significance isn't just the raw package count; it's the breadth of what got hit simultaneously. TanStack is frontend framework tooling used across an enormous number of web applications. Mistral AI's SDK sits inside AI application pipelines. UiPath is enterprise robotic process automation. OpenSearch is search and observability infrastructure. Guardrails AI is, ironically, a library built to add safety checks around AI systems. A single coordinated campaign touching all of those categories at once demonstrates that attackers aren't specializing in one type of target — they're going wherever registry-level access can be gained, regardless of what the package is actually for.

How Attackers Actually Get In

Behind the named incidents sit a handful of recurring techniques, and understanding them is what turns "supply chain attacks are scary" into something a team can actually defend against.

Typosquatting relies on human error at the point of installation: an attacker publishes a malicious package under a name deliberately close to a popular legitimate one — a single transposed letter, a common misspelling, a different but plausible separator — betting that someone will mistype npm install or copy a slightly wrong name from an unreliable tutorial and pull in the malicious version without noticing the difference.

Dependency confusion exploits how package managers resolve names across public and private registries. If an organization has an internal package with the same name as one it hasn't yet claimed on the public registry, an attacker can publish a malicious package under that name publicly, and depending on how the build system is configured, it may prefer the higher-versioned public package over the intended private one — pulling attacker-controlled code into an internal build without any typo involved at all.

Maintainer account takeover targets the human holding publish rights rather than the code itself: phishing a maintainer's registry credentials, stealing a session token, or compromising a personal device that has a valid publish token cached on it. Once an attacker holds legitimate publish credentials, they can push a malicious version through entirely normal-looking channels — no exploit required, because the registry correctly sees an authenticated, authorized publisher.

CI/CD pipeline compromise targets the automated build and release infrastructure itself rather than a human maintainer. Build systems routinely hold long-lived publish tokens and secrets so releases can happen automatically; if an attacker can inject code into that pipeline — through a compromised dependency used only at build time, a misconfigured workflow permission, or a leaked secret — they can get a malicious release published through the project's own trusted, automated release process.

Git history and tag manipulation is a quieter technique: rewriting a repository's Git tags after the fact so that a previously published, benign release now points to different, malicious commit history, or that a build process pulling "the tagged release" pulls something the original maintainer never actually approved. It's a technique that specifically exploits the assumption that a Git tag, once published, reliably still points to what it originally pointed to.

These techniques rarely operate in isolation, either — a campaign frequently chains two or three of them together in sequence. A maintainer account takeover might be the initial entry point, which then gets used to plant a change in a CI/CD workflow file that grants a broader, longer-lived publish token than the original one held, which in turn survives an incomplete credential rotation and enables a second wave of malicious releases weeks after the "initial" incident was believed closed. Treating each technique as a separate, independent risk to defend against misses this compounding quality — a defense that only checks for typosquatting, for instance, does nothing to catch a pipeline-level compromise that never involved a suspiciously-named package at all, which is exactly why the layered defenses covered later in this piece matter more than any single control chosen in isolation.

Each of these techniques shows up somewhere in 2026's incident list beyond the four headline campaigns — coordinated multi-package operations, poisoned releases caught within minutes by automated scanners, and version-history manipulation across hundreds of package releases have all been documented this year, which the questions and answers later in this piece cover in more specific detail.

Why AI-Era Tooling Raises the Stakes

Two threads running through 2026's incident list point at the same underlying shift: attackers are increasingly targeting the software supply chain that AI systems themselves depend on, not just the traditional web and backend ecosystem.

LiteLLM and Mistral AI's SDK weren't incidental victims — they're both pieces of plumbing that sit directly inside AI application pipelines, meaning a successful compromise doesn't just affect "a web app," it affects whatever AI-powered product or internal tool was built on top of that plumbing, potentially including the prompts, retrieved context, or model outputs flowing through it. As more of the software being built in 2026 has an AI component somewhere in its stack, the AI/ML dependency layer becomes a more valuable target in exactly the same way any widely-reused layer of infrastructure does — the difference is that this layer is newer, faster-growing, and in many organizations less rigorously vetted than the traditional dependencies sitting alongside it.

The second thread is how AI-assisted development tooling itself is changing how dependencies get chosen and installed. Security researchers have started framing this year's supply chain risk explicitly around AI-enabled surfaces — VS Code extensions, AI coding assistants, and agentic development tools — because these tools increasingly suggest, and sometimes directly install, packages as part of completing a coding task, often with less deliberate human scrutiny than a developer manually typing npm install after reading a package's README and checking its download count. An AI coding assistant that suggests a dependency doesn't inherently know whether that package was quietly compromised last week, and a developer who's used to trusting the assistant's suggestions may install faster than they'd otherwise pause to verify. None of this means AI-assisted coding is unsafe to use — it means the same dependency-vetting discipline that should already exist has to extend to AI-suggested packages just as rigorously as to manually chosen ones, rather than getting waived because the suggestion came from a tool that feels authoritative.

Who Feels This First: Businesses, Developers, and Regulators

Supply chain compromise doesn't stay contained to the company that originally published the poisoned package — it radiates outward to every organization with that package anywhere in its dependency tree, which in practice means almost everyone building software touches this risk somewhere, whether they realize it or not.

For businesses running production software, the exposure is largely invisible until an advisory drops, because most organizations don't maintain a real-time view of every transitive dependency their applications actually pull in. A company that never directly chose to depend on a compromised package can still be running it three or four levels deep in its dependency tree, inherited through a framework or utility library someone selected years ago for an unrelated reason.

For developers and platform teams, the exposure is operational and time-sensitive: when an advisory names a compromised version, the window to react is measured in hours, not the days or weeks a typical patch-management cycle assumes. That mismatch — patch cadences built for planned updates being applied to an unplanned, urgent compromise — is one of the more uncomfortable adjustments teams are being forced to make in 2026.

For regulators and sector bodies, the response has started becoming concrete rather than purely advisory. NHS England Digital issued a specific cyber alert, reference cc-4781, directly warning UK healthcare-sector organizations about the npm and PyPI supply chain attacks — a clear, sector-specific regulatory response rather than a generic "be careful with dependencies" bulletin. That kind of targeted alert is a signal of where this is heading: sector regulators treating open-source supply chain exposure as a named, trackable risk category worth their own dedicated communication, not just a general IT hygiene footnote.

The Global Picture

Reporting on 2026's supply chain wave is heavily concentrated around the specific named incidents and the vendors and researchers who caught them, and that shapes how thin or thick the picture looks region by region.

In the United States, no separate US-specific statistic was identified beyond the fact that most of the named affected projects and maintainers — LiteLLM, the Axios maintainers, TanStack, OpenSearch, Guardrails AI — sit inside the globally-used, largely US-centric open-source ecosystem. The exposure is described at the level of "everyone using these packages," which includes US organizations heavily, without a distinct US government or industry-specific breakout in the research reviewed.

In the United Kingdom, the picture is genuinely distinct: NHS England Digital's cyber alert cc-4781 is a concrete, named, sector-specific regulatory response to exactly this wave of npm and PyPI attacks, aimed at UK healthcare organizations. That makes the UK the one region in this research with a clear, documented institutional reaction rather than only general global exposure.

In the UAE and wider Gulf market, no distinct regional-specific reporting was found. Given how broadly npm and PyPI packages are used across globally-built software regardless of where a company is headquartered, the underlying exposure is plausibly comparable to other markets with fast-growing tech sectors, even without a locally-reported incident or statistic to point to.

In Australia, the same holds — no region-specific reporting surfaced in the sources reviewed, with the trend presented globally rather than broken out by market.

In Germany, public reporting specific to this wave of incidents is thin so far, notable given Germany's generally strong attention to software and data security more broadly — it may simply reflect that no single named incident in this wave had a distinctly German angle serious enough to generate separate coverage yet.

In France and the wider European market, no distinct regional statistic was found beyond the general exposure every EU-based organization shares through using the same globally-distributed npm and PyPI ecosystems as the rest of the world.

In China, no distinct regional-specific reporting was identified in the sources reviewed for this piece.

Taken together, the honest picture is that this remains a global open-source ecosystem story with one clear regional exception — the UK's NHS-specific alert — rather than a trend that's been broken down market by market everywhere. That's consistent with how open-source registries actually work: npm and PyPI serve the same global package pool to every consumer regardless of jurisdiction, so exposure tracks with what a country's software industry happens to depend on rather than with any local regulatory boundary.

Building Real Defenses: SBOMs, Pinning, and Verification

No single control closes this risk entirely, but a layered set of practices meaningfully reduces both how likely a team is to install a compromised package and how long it stays installed if one slips through.

A Software Bill of Materials (SBOM) is a structured inventory of every component — direct and transitive — that makes up a piece of software. It's genuinely useful for one specific job: knowing, quickly, whether you're running an affected version once an advisory names one. It is not, on its own, a preventive control — an SBOM tells you what you have, not whether any of it is safe, and it does nothing to stop a compromised version from being installed in the first place. Treating SBOM generation as "solving" supply chain security is one of the more common and costly misreadings of what the practice actually does; it's an inventory system, not a security gate.

Dependency pinning and lockfiles address the automatic-update exposure directly: rather than allowing a build to silently pull the newest version of every dependency, a lockfile fixes exact versions until a human or an automated process deliberately reviews and approves an update. This is precisely the control that limits exposure to short-lived compromises like Axios's roughly three-hour poisoned window — a pinned build simply doesn't pull the malicious version at all, regardless of how briefly it was live, because nothing in the pipeline was configured to fetch "whatever's newest" automatically.

Vetting new dependencies before adoption means checking a package's maintenance activity, download trends, maintainer reputation, and known vulnerability history before adding it to a project — a habit that's easy to skip under deadline pressure but meaningfully reduces the odds of adopting a package that turns out to be poorly maintained, and therefore an easier target for account takeover, in the first place.

Continuous monitoring for anomalous publishes — a sudden new version from a package that hasn't been updated in months, an unexpected maintainer change, a release that adds network calls or obfuscated code with no corresponding changelog entry — is what catches a compromise fast rather than relying entirely on an external advisory to arrive first. This is exactly the kind of automated detection that caught a malicious jscrambler release within six minutes of publication in one of 2026's documented cases, which stands in sharp contrast to campaigns that ran for days or weeks before being noticed.

Publisher verification and package signing, where registries and ecosystems support it, raise the cost of maintainer account takeover specifically, by requiring a cryptographic signature tied to a verified identity rather than relying solely on a login session or a cached publish token that can be phished or stolen.

None of these controls is sufficient alone. An SBOM without pinning tells you what's affected but didn't stop the exposure. Pinning without vetting freezes a good decision but doesn't prevent a bad one. The realistic goal isn't eliminating supply chain risk — it's shrinking both the odds of installing something compromised and the exposure window if you do, using a layered set of habits rather than any single tool treated as a complete answer.

Building an Incident Response Playbook for the Next Advisory

Given how short some of 2026's exposure windows have actually been — a matter of minutes in the fastest documented detection cases, a few hours in others — the difference between an organization that handles the next advisory calmly and one that scrambles for a full day usually comes down to whether a response playbook already existed before the advisory arrived, rather than how skilled the team responding to it happens to be.

A playbook worth having answers a small number of questions in advance, in writing, rather than improvising them under pressure. Who gets paged the moment a critical dependency advisory drops, and through what channel — an alert that sits unread in a shared inbox for six hours defeats the purpose of even the fastest external detection. What's the fastest way to query "are we running the affected version, and where" across every service and environment, which is only answerable quickly if a dependency inventory already exists in a queryable form rather than needing to be reconstructed live. What's the rollback or pin-and-patch procedure once an affected version is confirmed, and who has the authority to trigger it without waiting for a change-approval cycle that assumes a planned update rather than an emergency one. And who owns external communication if the compromise reached a shipped build affecting customers, so that the technical fix and the customer-facing message move in parallel instead of the second one lagging the first by days.

None of this is exotic — it's the same incident response discipline organizations already apply to other categories of security incident, applied specifically to the supply chain scenario rather than assumed to generalize automatically from a generic incident response plan that was never actually rehearsed against this particular failure mode. The organizations that responded fastest to 2026's named incidents were, almost without exception, the ones that had already answered these four questions before they needed to, not the ones improvising a dependency audit for the first time while an advisory's exposure window was actively still open.

It's also worth rehearsing the playbook against a plausible worst case rather than only a mild one: not "a low-severity package we barely use," but "the equivalent of LiteLLM or Axios for us — something with enormous internal reach that would touch production within the hour if we didn't catch it." A playbook that only gets tested against low-stakes scenarios tends to reveal its gaps for the first time during the one incident where those gaps actually matter, which is precisely the wrong moment to discover that the dependency inventory query takes four hours to run or that nobody's actually sure who has rollback authority on a Saturday.

What This Means for How You Build

The practical shift this year's cadence of incidents forces is less about any single new tool and more about treating open-source dependency management as an ongoing operational discipline rather than a one-time setup decision made when a project starts. A dependency chosen carefully at project kickoff can still become a liability eighteen months later if its maintainer's account is compromised, its build pipeline is breached, or its ownership quietly changes hands — none of which the original vetting decision could have anticipated, and none of which gets caught without continuous monitoring running for the life of the project, not just at the start of it.

This is the same discipline we build into every custom software development engagement: dependency choices get reviewed as part of the architecture, lockfiles and pinned versions are the default rather than an afterthought, and monitoring for exactly the kind of anomalous package behavior described above gets wired into the pipeline rather than left to whoever happens to read the right advisory at the right time. The same underlying exposure applies just as much to web development projects built on JavaScript and npm tooling as it does to backend systems pulling from PyPI — the registry, the ecosystem, and the risk model differ in the details, but the discipline of pinning, vetting, and monitoring transfers directly across both. Our security page covers how we think about this kind of risk across client engagements more broadly, and it's a useful reference point precisely because supply chain exposure isn't a one-time audit finding to close out — it's a standing operational risk that has to be managed for as long as the software keeps running and its dependencies keep evolving underneath it, which for almost any real system means indefinitely.

What Security and Engineering Teams Are Actually Asking About Supply Chain Attacks

What is a software supply chain attack?

A software supply chain attack compromises a component your software depends on — an open-source package, a build tool, a CI/CD pipeline, or a maintainer's publishing credentials — rather than attacking your application or infrastructure directly. Because modern software is assembled from hundreds or thousands of transitive dependencies, compromising one sufficiently popular package can reach every downstream project that installs it, often silently, since most teams trust their dependency tree by default rather than re-verifying it on every install. The attack surface isn't your code; it's everything your code was built on top of, which is precisely why these attacks have become so effective — they exploit trust relationships that most development workflows were never designed to question.

How many software supply chain attacks happened in 2026?

2026 has produced an unrelenting, roughly monthly cadence of major, independently confirmed registry-poisoning campaigns between March and July alone, on top of a broader trend showing malicious open-source package identifications up more than 1,400% between 2024 and 2025. That combination — frequent, well-documented major campaigns layered on top of a steep rise in total detected malicious packages — reflects both a genuine increase in attacker activity and meaningfully improved detection tooling catching more of what's actually happening, though even accounting for better visibility, the sheer number of named, verified incidents through the year shows an accelerating trend rather than a stable baseline that's simply better lit than before.

Does an SBOM prevent supply chain attacks?

No, and treating it as if it does is one of the more common and costly misunderstandings in this space. A Software Bill of Materials is an inventory — a structured list of every component, direct and transitive, that makes up a piece of software. What it does well is let you answer, quickly, "am I running the affected version" the moment an advisory names one, which matters enormously for response speed. What it does not do is stop a compromised version from being installed in the first place, verify that any listed component is currently safe, or catch a brand-new compromise before an advisory exists. An SBOM is a necessary piece of supply chain hygiene, not a preventive control, and it works best paired with pinning, vetting, and active monitoring rather than treated as sufficient on its own.

Which package ecosystems were hit hardest by supply chain attacks in 2026?

npm and PyPI anchor nearly every major named incident in 2026's reporting, often simultaneously in the same coordinated campaign — the May 11 mass attack alone touched more than 170 npm packages and 2 PyPI packages across ecosystems as varied as TanStack, Mistral AI's SDK, UiPath, OpenSearch, and Guardrails AI. That's consistent with which ecosystems carry the largest, most widely-reused dependency trees in modern software: JavaScript's npm registry and Python's PyPI registry are both enormous, heavily interconnected, and used across an extraordinary range of application types, which makes them the highest-payoff targets for an attacker optimizing for downstream reach rather than a niche or less-used package ecosystem.

Which compromised Axios versions were affected and what should developers do immediately?

Malicious versions of Axios, the widely used HTTP client library, were published to npm and stayed live for roughly three hours before being pulled — a short window in human terms, but long enough for automated build pipelines pulling the newest version automatically to install and even ship it without any human reviewing the change. Developers using Axios should immediately check their lockfiles against the specific advisory naming the affected version range, pin to a known-good version rather than allowing automatic minor-version updates going forward, and audit recent build and deployment logs for the window the compromised version was live, to confirm whether a poisoned build actually reached production rather than assuming a short exposure window meant no impact.

What credentials were targeted by the TeamPCP supply chain attack on LiteLLM?

The March 26, 2026 compromise of LiteLLM — a PyPI package used heavily in AI/ML pipelines with roughly 3.4 million downloads a day — was attributed to a group tracked as TeamPCP. Attacks of this kind typically center on gaining valid publishing credentials for the target package, whether through a phished maintainer account, a stolen or leaked publish token, or a compromised build environment that already held legitimate release access, since holding real publish credentials lets an attacker release a malicious version through entirely normal-looking registry channels rather than needing to exploit a separate technical vulnerability. Given the package's enormous daily download volume, even a brief compromise window translated into an unusually large potential blast radius across the AI application stacks that depend on it.

How did the threat actor circumvent Axios's GitHub Actions CI/CD pipeline protections?

Modern CI/CD pipelines like GitHub Actions are designed to automate releases safely, but that automation depends on secrets and tokens held by the pipeline itself — and pipeline compromises typically work by finding a way to inject attacker-controlled code or commands into a workflow that already holds legitimate publish credentials, rather than by attacking the protections head-on. Common paths include a compromised build-time dependency executing code during the build step, a misconfigured workflow permission granting broader access than intended, or a leaked pipeline secret being reused outside its intended scope. Once an attacker can execute anything inside a pipeline that holds a real publish token, the pipeline's own legitimate protections work against detection rather than for it, because the resulting release looks, to the registry, exactly like any other authorized publish.

What makes the LiteLLM v1.82.8 .pth-file technique particularly dangerous?

Python's .pth files are a long-standing packaging mechanism: any file with a .pth extension placed in a Python environment's site-packages directory gets read automatically on interpreter startup, and if a line in it starts with import, that line executes as code — automatically, on every single Python process that loads using that environment, with no explicit action required from whoever's running the code. That makes a .pth-file-based technique dangerous specifically because it doesn't need the compromised package to be directly imported or actively used to execute — simply having it installed in an active environment is enough to trigger code execution the moment Python starts up, which is a meaningfully stealthier and broader-reaching mechanism than malicious code that only runs when a specific function is actually called.

Who is the TeamPCP threat group and what other attacks have they conducted?

TeamPCP is the threat group tracked as responsible for the March 26, 2026 compromise of the LiteLLM PyPI package. Attribution research on groups operating in this space in 2026 generally tracks them by the specific technical signatures and infrastructure they reuse across campaigns — patterns in how credentials are obtained, how malicious payloads are structured, and what infrastructure hosts command-and-control traffic — rather than by a single confirmed real-world identity, which is typical for supply chain threat actors operating at this level of sophistication. The broader lesson from tracking groups like TeamPCP is less about any one group's specific history and more about what it confirms: 2026's registry-poisoning wave includes organized, capable actors deliberately targeting high-download-volume packages rather than only opportunistic or low-skill attempts.

What happened in the May 11, 2026 mass supply chain attack on TanStack and Mistral AI packages?

On May 11, 2026, a single coordinated campaign compromised more than 170 npm packages and 2 PyPI packages simultaneously, spanning ecosystems including TanStack, Mistral AI's SDK, UiPath, OpenSearch, and Guardrails AI — making it one of the largest registry-poisoning events observed to date. What makes it particularly significant isn't only the package count but the breadth of what got hit in one coordinated operation: frontend framework tooling, an AI/ML SDK, enterprise automation software, search infrastructure, and even a library built specifically to add safety guardrails around AI systems. That spread across such different categories of software, compromised at effectively the same time, points to a level of coordination and reach well beyond a single-package or single-maintainer compromise.

How did incomplete credential rotation enable the 60+ package npm campaign in Feb-Mar 2026?

The February–March 2026 campaign that compromised more than 60 npm packages unfolded in multiple phases, and what let the later phases continue was that an earlier round of credential rotation — done after the initial compromise was identified — didn't cover every token or session the attacker had actually obtained. A rotation that resets some but not all exposed credentials leaves exactly the kind of residual foothold an attacker needs to resume publishing malicious versions once initial attention has died down. It's a concrete illustration of why incident response after a credential compromise needs to assume the exposure was broader than what's been confirmed, rather than declaring the incident closed once the first, most obvious credential has been rotated.

Why did malicious open-source package identifications rise over 1,400% between 2024 and 2025?

A rise of that magnitude reflects two forces compounding each other rather than one single cause. Detection and scanning tooling for open-source ecosystems has genuinely improved, meaning a meaningfully larger share of malicious packages that previously went unnoticed are now actually being caught and counted — some of the increase is visibility, not new activity. At the same time, the volume, frequency, and sophistication of the named 2026 campaigns covered throughout this piece indicate real growth in attacker activity, not just better measurement of a flat underlying rate. Taken together, the honest read is that open-source registries are being probed and attacked more often and more effectively than before, and the tooling built to catch that is only now starting to make the true scale visible.

What is the TrapDoor campaign and how did it plant malicious packages across npm, PyPI and Crates.io?

The TrapDoor campaign was documented planting malicious packages across multiple ecosystems simultaneously — npm, PyPI, and Crates.io (the Rust package registry) — spanning more than 34 packages and over 384 versions in total. Operating across three separate registries at once, rather than concentrating on one ecosystem, suggests a deliberate strategy to maximize reach across different developer communities and technology stacks rather than relying on compromising any single popular package. A campaign at that scale and cross-ecosystem breadth also illustrates why defenses scoped to just one registry or one language ecosystem are an incomplete answer — an organization using JavaScript, Python, and Rust dependencies together is exposed to a coordinated campaign like this from three directions simultaneously, not just one.

How were more than 700 versions of Laravel-Lang poisoned through rewritten Git tags?

The Laravel-Lang incident involved more than 700 versions being poisoned through rewritten Git tags — meaning the attacker altered what a previously published Git tag actually pointed to, so that a build process trusting "the tagged release" as a stable, unchanging reference instead pulled different, attacker-modified commit history than what the original maintainer had approved. This technique is particularly insidious because it doesn't require compromising the package registry directly — it exploits the common assumption that once a version tag is published, it reliably continues to point to the same code indefinitely, an assumption that Git's technical design doesn't actually guarantee unless a project takes specific steps to protect its tag history from being rewritten after the fact.

How did the Mastra campaign republish 140+ packages in about 88 minutes?

The Mastra campaign republished more than 140 packages in approximately 88 minutes, a pace that's only achievable through automation rather than manual, one-by-one publishing. That speed is itself a significant part of the threat: a defense strategy that relies on a human noticing something looks off, investigating, and then acting, has a response time measured in hours or days at best — nowhere close to fast enough to intercept a campaign that completes its entire malicious publishing run in under an hour and a half. Incidents like this are part of why automated, real-time anomaly detection on package registries has become a necessary defense rather than a nice-to-have, since by the time a manual review process would even begin, a campaign moving at this speed is already finished.

How did Socket detect a malicious jscrambler release just six minutes after publication?

Socket's detection of a malicious jscrambler release within six minutes of its publication is one of 2026's clearest examples of automated monitoring working as intended, catching a compromise in near real time rather than relying on an external advisory or a manual report arriving after the fact. Tools built for this purpose continuously scan newly published package versions for suspicious signals — unexpected new network calls, obfuscated code with no corresponding changelog explanation, sudden behavioral changes in a package that had been stable for a long time — and flag them automatically rather than waiting for a human researcher to happen to notice. The six-minute detection window stands in sharp contrast to campaigns like the Axios compromise that ran for roughly three hours, illustrating just how much the speed of detection tooling actually matters in limiting real-world exposure.

What is dependency confusion and how do attackers exploit it?

Dependency confusion exploits how package managers resolve a package name when both a private, internal registry and a public registry could plausibly contain a package with that same name. If an organization has an internal package it never got around to also registering publicly, an attacker can publish a malicious package under that identical name on the public registry — often with a deliberately higher version number — and depending on how the build system is configured, the resolver may prefer the public, higher-versioned, attacker-controlled package over the intended private one. The result is malicious code entering an internal build with no typo, no phishing, and no direct breach involved at all — just a naming collision the attacker deliberately created and the build tooling's default resolution behavior did the rest.

What is typosquatting in the context of npm/PyPI package names?

Typosquatting is publishing a malicious package under a name deliberately close to a popular, legitimate one — a transposed letter, a common misspelling, a hyphen swapped for an underscore — betting that developer error will do the actual work of installing it. It relies entirely on the same kind of mistake that causes typos anywhere else: mistyping a package name during a quick npm install or pip install, or copying a slightly incorrect name from an outdated tutorial, blog post, or AI-generated code suggestion without double-checking it against the registry first. Because registries generally allow anyone to publish under any unclaimed name, defending against typosquatting falls mostly on developer diligence and tooling that flags newly-registered, low-download packages with suspiciously similar names to popular ones, rather than on any control the registry enforces automatically.

Why did NHS England issue a specific cyber alert about the npm/PyPI supply chain attacks?

NHS England Digital issued cyber alert cc-4781 as a direct, sector-specific warning to UK healthcare organizations about the broader wave of npm and PyPI supply chain attacks running through 2026. Healthcare systems carry an unusually high concentration of sensitive patient data and safety-critical operational software, which makes a supply-chain-introduced compromise a materially higher-consequence event there than in many other sectors — a compromised dependency reaching into clinical or administrative systems isn't just a data exposure risk, it can touch systems that directly affect patient care. Issuing a specific, named alert rather than folding the warning into general guidance signals that NHS England treats this class of risk as serious and current enough to warrant direct, sector-targeted communication rather than passive reference material.

How can developers verify package integrity before installing npm or PyPI dependencies?

Practical verification starts with checking a package's basic health signals before installing it: recent maintenance activity, a download and version history that looks organic rather than suspiciously spiky, and no unexplained recent maintainer changes. Beyond that, using lockfiles to pin exact versions rather than accepting automatic updates, checking published package hashes or signatures against what the source repository actually contains where that tooling is available, and running dependency-scanning tools that flag known-compromised versions against public advisory databases all add meaningful layers of verification. None of these steps guarantees safety on their own — a genuinely sophisticated maintainer-account compromise can pass basic health checks — but together they catch a large share of the more common typosquatting, dependency-confusion, and known-compromised-version scenarios before they ever reach a build.

What role do AI coding assistants play in propagating supply chain risk (e.g., VS Code extensions, AI agents)?

AI coding assistants and agentic development tools increasingly suggest — and in some workflows directly install — dependencies as part of completing a coding task, often with less deliberate scrutiny than a developer manually deciding to run an install command after reading a package's documentation. An assistant recommending a package has no inherent way of knowing whether that specific package was quietly compromised days or weeks earlier, and a developer accustomed to trusting the assistant's suggestions may install faster than they'd otherwise pause to verify manually. VS Code extensions add a related but distinct surface, since extensions themselves are installable packages that can carry the same typosquatting and account-takeover risks as any other registry dependency, while also running with meaningful access to a developer's local environment. None of this means AI-assisted development is inherently unsafe — it means the same dependency-vetting discipline needs to extend to AI-suggested and extension-installed packages just as rigorously as to manually chosen ones.

How quickly should organizations react when a widely-used package is reported compromised?

As close to immediately as operationally possible — within hours, not days, because the exposure windows involved in 2026's documented incidents have ranged from a few minutes of detection lag up to a few hours of a poisoned release being live, and every hour of delay is an hour a compromised build could be deploying to production undetected. The practical first steps are checking lockfiles and dependency manifests against the specific affected version range named in the advisory, freezing or pausing automated deployments that could pull the compromised version while the check runs, and auditing recent build logs for the exposure window to confirm whether a poisoned version actually made it into a shipped build rather than assuming it didn't. Organizations that already maintain an accurate, continuously updated dependency inventory can answer "are we affected" in minutes; organizations without one can lose most of a day just figuring out what they're running before they can even start remediation.

What is the realistic exposure window before a malicious package version is pulled from a registry?

It varies enormously depending on how the compromise is detected, but 2026's documented incidents span from as little as six minutes — as in Socket's detection of a malicious jscrambler release — to roughly three hours, as with the poisoned Axios releases. Even the shorter end of that range is meaningfully long relative to how automated build and deployment pipelines actually operate: a system configured to pull the newest dependency version automatically can install and ship a compromised release well within a six-minute-to-three-hour window without any human ever consciously deciding to trust the new version. That's precisely why detection speed and dependency pinning both matter independently — faster detection shrinks the window a compromise is live at all, while pinning prevents an automated pipeline from being exposed to that window regardless of how long it lasts.

How do supply chain attacks on AI/ML libraries like LiteLLM and Mistral AI's SDK differ from attacks on general-purpose packages?

The underlying attack techniques — credential theft, CI/CD compromise, typosquatting — aren't fundamentally different when the target is an AI/ML library rather than a general-purpose one. What differs is the downstream reach and sensitivity of what a compromise can touch: AI/ML libraries like LiteLLM and Mistral AI's SDK sit inside the plumbing that routes prompts, retrieved context, and model outputs through an application, so a compromise reaching that layer has a plausible path to intercepting or manipulating exactly the data flows an AI system depends on, not just generic application logic. Combined with how new and fast-growing the AI application stack is — meaning less mature vetting practices around AI-specific dependencies compared to long-established general-purpose libraries — this makes AI/ML packages an increasingly attractive target precisely because the ecosystem around them hasn't yet caught up to the scrutiny applied to older, more established parts of the software supply chain.

What is the role of package maintainer account takeover in enabling these attacks?

Maintainer account takeover is one of the most direct paths into a supply chain attack because it skips the need for a separate technical exploit entirely — an attacker holding legitimate, authenticated publish credentials can push a malicious version through a package's completely normal release process, and the registry has no reason to flag it, because as far as the system can tell, the real, authorized maintainer just published an update. Credentials get taken over through phishing, credential-stuffing against reused passwords, stolen session tokens, or malware on a maintainer's personal device that captures a cached publish token. Because so much of the open-source ecosystem still runs on individual maintainers rather than dedicated security teams, account takeover remains one of the highest-leverage techniques available to an attacker, and it's a large part of why publisher verification and mandatory multi-factor authentication for registry accounts have become more actively pushed defenses in 2026.

How should enterprises pin, vet, and monitor third-party open-source dependencies?

Pinning means using lockfiles to fix exact dependency versions rather than allowing automatic updates to pull whatever's newest, so a build only changes what it depends on when a human or an automated process deliberately reviews and approves the change. Vetting means checking a new dependency's maintenance activity, download and version history, and known vulnerability record before adopting it, rather than adding it purely because it solves the immediate problem fastest. Monitoring means running continuous, automated scanning against public vulnerability and compromise advisories, so that if a dependency already in use gets flagged after the fact, the organization finds out from its own tooling within minutes or hours rather than from a customer, a headline, or an incident. None of the three substitutes for the others — pinning without vetting just freezes a risky choice in place, and vetting without monitoring only protects against risks that were already known at adoption time.

What is a Software Bill of Materials (SBOM) and what are its real limitations?

A Software Bill of Materials is a structured, machine-readable inventory of every component that makes up a piece of software, direct and transitive, typically including version numbers and, where available, license and provenance information. Its real value is speed of response: when an advisory names a compromised version, an organization with an accurate SBOM can check exposure in minutes instead of days spent manually reconstructing what's actually running. Its real limitation is that it's descriptive, not protective — an SBOM doesn't stop a compromised package from being installed, doesn't verify that anything currently listed is safe, and is only as accurate as the last time it was generated, which for a system that isn't continuously re-scanned can mean it's already stale by the time anyone needs it. It's a necessary piece of supply chain hygiene, not a stand-in for pinning, vetting, or monitoring.

How are registry operators (npm, PyPI) improving publisher verification after 2026's incidents?

The general direction registry operators have been pushing, consistent with the pattern behind most of 2026's named incidents, is tightening the controls around exactly what enabled those incidents in the first place: stronger requirements around multi-factor authentication for maintainer accounts with publish rights, more scrutiny on how automated CI/CD publishing tokens are scoped and how long they remain valid, and improved automated scanning of newly published versions for suspicious patterns before or shortly after they go live. Publisher and package signing, where adopted, adds a cryptographic layer that's harder to compromise than a login session or a cached token alone. None of these changes make a registry attack-proof — the incidents this year demonstrate attackers adapting to whatever the current controls are — but each one raises the cost and narrows the window for the specific techniques (account takeover, pipeline token theft) that anchored 2026's biggest campaigns.

What is the financial and reputational cost of a supply chain compromise for an affected vendor?

The costs compound across several categories rather than resolving into one clean number: direct incident response and remediation effort, the engineering time spent auditing every downstream system that might have pulled the compromised version, the trust cost of customers and downstream projects re-evaluating whether to keep depending on a package or vendor that got compromised, and in more severe cases, contractual or liability exposure if the compromise led to a breach at a customer relying on the affected software. For a widely-used package or vendor, the reputational cost can outlast the technical remediation considerably — being the named vendor in a major supply chain incident tends to stick in the industry's memory well after the specific vulnerability has been patched, which is part of why fast, transparent incident communication tends to matter as much for reputation recovery as the technical fix itself.