Package registries got materially harder to abuse in 2026, and the volume of malicious artifacts kept climbing. Both are true, and the relationship between them is the useful part. Every control added removed the cheapest path to execution, and the campaigns took the next one, which was sometimes a different registry and is increasingly the same registry reached by a different technique. That second response costs defenders more, because it invalidates the detection built around the path that was closed.
From September 11, 2026, the EU Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities, with an early warning inside 24 hours, a fuller notification inside 72, and a final report within 14 days of a corrective measure. Answering that in 24 hours means knowing where a compromised component came from and what else arrived with it.
The cheap answer is a different venue
PyPI and NuGet both pushed mandatory two-factor authentication and trusted publishing, which replaces long-lived API tokens with short-lived OpenID Connect credentials issued to a CI job. Observed malware on those registries fell by roughly 43% and 60% respectively.
Over the same period npm malware more than doubled, and npm now accounts for close to 90% of open source malware observed across registries. npm has been closing the same gaps, with staged publishing shipping on May 22, 2026 to put a second-factor checkpoint between a publish command and the moment a version becomes installable, and npm v12 blocking install scripts by default.
Read as separate registry stories these are three success reports, and read together they describe a single population of adversaries choosing the cheapest remaining route. Friction at one registry is a local win and an ecosystem-level redistribution, because nothing about the hardening reduced the number of people running these campaigns or the value of what they steal.
Relocation is only the cheaper of the two available answers, and it stops being cheap once every large registry has the same controls. The other answer is to stay put and change the technique.
Blocking a path teaches the technique that replaces it
Lifecycle scripts had been the standard route from download to code execution for years, so tooling, guidance, and eventually npm itself moved against them, with --ignore-scripts the long-standing advice and npm v12 making blocked scripts the default.
On June 3, 2026 a self-propagating worm reached 57 packages across several hundred malicious versions without using a lifecycle script at all. It shipped a weaponized binding.gyp, the manifest that tells npm a package contains native code. npm treats the presence of that file as a signal to run node-gyp rebuild automatically, so the execution was triggered by the build system rather than by any hook a defender had been told to watch. The same worm carried an equivalent trick into RubyGems through extconf.rb.
The control was correct, and the campaign responded by finding a different way to be executed on the registry it was already using. --ignore-scripts does block that implicit rebuild, contrary to how this circulated at the time. The technique’s value lay in evading the detection and guidance that had grown up around lifecycle hooks, which is a separate thing from evading the flag itself.
Persistence followed the same pattern: when install-time execution became the thing everyone watched, the campaigns that mattered moved to session hooks and editor task configuration, which run when a developer next opens the project rather than when a package is installed. That defeats install-time monitoring and it defeats removal, since taking the package back out leaves the hook behind.
The artifacts that arrived without a governance model
Package registries spent fifteen years learning about namespace squatting, account takeover, and provenance. Agent artifact marketplaces started from zero in about eighteen months, and they carry executable behavior on day one.
The registries hosting MCP servers and agent skills largely function as discovery catalogs. They index what exists so an agent can find it, without enforcing access control, tracking what a server does after installation, or verifying that the published artifact matches any reviewable source. Around 15% of servers listed in MCP registries ship no source code at all, which means the ordinary defense of reading before running is unavailable by default. In February 2026 a single agent marketplace was found hosting over a thousand malicious skills.
The payload here is frequently natural language rather than code. Repository configuration files that agents read as instructions, such as agent rules files checked into a project, are a delivery path no code scanner is built to inspect, because there is no code in them to find. A file of instructions that an agent obeys is executable in every way that matters and inert to every tool that looks for executable content, which makes it the end state of the same progression: a technique chosen because the defenses were built to read something else.
Per-registry defense produces per-registry vision
Each of the hardening measures above is correct and worth having. Each one is also scoped to a single registry, and so is the visibility it produces. A registry can tell you what happened on that registry. It has no view of the same publisher operating under a different name on a different platform, which is precisely the behavior the displacement data describes.
That leaves the defender holding a set of local answers to a question that is not local. The relevant unit is the operation: the set of artifacts that belong together because one source shipped them, spread across whichever registries were cheapest at the time. Nobody who runs one registry is positioned to see that, and the artifacts most likely to carry the next campaign are the ones sitting in catalogs with the least governance.
State-sponsored activity has followed the same logic, with public tracking recording more than 290 supply chain intrusions attributable to state-linked activity between early 2025 and mid-2026, including compromises of widely depended-upon npm packages. These groups are not choosing the supply chain because it is exotic. They choose it because one publishing account converts into access at every downstream consumer, and because the ecosystem’s defenses are organized per registry while their operations are not.
The clock that starts in September
The Cyber Resilience Act obligations arriving in September 2026 apply to manufacturers placing products with digital elements on the EU market, including products shipped years ago. The act also requires a maintained, machine-readable software bill of materials.
An SBOM tells you what is in the product without telling you whether the account that published one of those components also published four others you are shipping, which is the question that determines whether your 24-hour early warning describes an isolated component or the visible edge of a campaign. Teams that can answer only the first question will report accurately and narrowly, and will file again when the next artifact from the same source surfaces.
What the next pressure release looks like
Attested publishing is on track to become ordinary for major package registries. Trusted publishing, staged releases, and default-blocked install scripts remove most of the cheap paths that defined 2024 and 2025, and the pattern above says what follows. A change of venue gets less attractive as the large registries converge on the same controls, which leaves the same-venue answer, so expect more of what the June worm did: execution primitives found inside systems already considered handled, and payload formats chosen because the tooling reads something else.
The second response is the more expensive one to absorb, because a campaign that moves to another registry stays recognizable by the same detection while one that changes technique invalidates that detection outright. The newest cases in 2026 are consistently of the second kind.
The governance response will reach the agent surface too, because it always does. Signing, provenance attestation, and registry review are already being proposed for MCP servers. Hardening plainly works, and the interval between hardening one surface and attacks arriving on the next keeps shrinking, so a defense organized around individual artifacts on individual platforms will always be describing the previous move.
What survives both answers is the source: a change of venue and a change of technique both leave the publishing account and the set of artifacts it has shipped intact, because neither of them changes who is running the campaign.
Where Aephix fits
Tracking the source across surfaces is the problem Aephix works on. Aephix is threat intelligence for the AI agent supply chain. It is not a registry control and does not replace one, and everything above about trusted publishing and staged releases is worth adopting on its own merits.
Before you install a package or connect to a server, Aephix Vantage gives you a free, cross-ecosystem view of what is already known to be malicious, so an artifact with a hostile history is something you recognize before you connect. When you are looking at a malicious package, model, skill, MCP server, extension, or container, Aephix Sleuth links it to the wider operation behind it, with a confidence level and supporting evidence, so a 24-hour reporting window starts from what is already on file rather than from a blank page.
The registries will keep getting harder to abuse, and the operations will keep moving, which is the behavior that gives them away.