- Wiz says a malicious npm update can reach build systems before any CVE is published, so scanners that rely on flaw databases may see it late.
- Wiz reports notable supply chain attacks were 1 in 4 significant incidents in H1 2026, up from about 10% in H2 2025. These are its own figures.
- Ask your team how fast it learns a package version is bad, whether builds pull the latest versions unreviewed, and who can trace past installs.
A vulnerability database records what is already known
Most companies check new software packages against lists of known flaws. If a package matches an entry, the build can be blocked. That works when the flaw has been found and written down.
A fresh compromise is not on any list yet. Wiz makes this point in an October 19 blog post about its npm detection work. Popular packages are trusted, it says, so build pipelines are often set up to fetch their newest versions automatically. A malicious update can then spread through an environment before a CVE is published.
Wiz also says developers and AI coding agents can add new dependencies and versions at speed. That raises the number of automatic decisions nobody reviews.
Wiz's research team reports that notable supply chain attacks were about 10% of significant incidents in the second half of 2025. In the first half of 2026, it says, the share was 25%, or 1 in 4. These are Wiz's own figures. The post does not explain how it defines "significant" or how many incidents it counted.
The Axios case: removed in hours, still widely exposed
Wiz describes an attack on Axios, a widely used npm package. An unknown actor took over the npm account of an Axios maintainer. The actor then published two malicious versions, v1.14.1 and v0.30.4. Each release pulled in a second package, plain-crypto-js, which had only just been created and was itself malicious.
The malicious versions were taken down within hours. Wiz says that did not end the matter. At the time, its researchers observed Axios in about 80% of cloud and code environments. They put weekly downloads at around 100 million.
Wiz observed the malicious code actually run in 3% of affected environments. A fast takedown helps, but any system that installed a bad version during that window still has to be found and checked.
How the detection pipeline works
Wiz says it built a pipeline that examines each new npm package version as it is published. In plain terms, it works in five steps.
First, it downloads the new version and earlier versions to compare them. Second, static analysis (reading the files without running them) flags suspicious ones. An AI classifier gives an initial verdict.
Third, suspicious versions go to a sandbox, an isolated test environment. There the pipeline installs the package, imports its modules and runs it from the command line where possible. Fourth, the Wiz Sensor watches what the code does while it runs. Fifth, the classifier issues a final verdict.
If a version is confirmed malicious, the pipeline publishes indicators of compromise, such as bad domains, to the Wiz reputation service. Wiz says customers are then alerted through its threat intelligence center, its code and cloud scanning, and Wiz Defend detection rules.
Why running the code matters: the keyv example
Wiz points to an attack on the keyv and cacheable family of npm packages, which followed the compromise of a GitHub maintainer account. The malware kept the addresses of its command-and-control servers out of its source code. Wiz says it fetched them while running, by asking an Ethereum smart contract (a program stored on a blockchain) for them.
That design defeats a simple code scan. The malicious domains never appear in the files, so static analysis alone could not identify them, Wiz says.
Wiz says its pipeline saw the network connection to the malicious domain and flagged it without human intervention. It reports high confidence in the verdict. It also says customers could detect the compromised keyv versions before a formal CVE was published.
The lesson: the trusted name is the route in
In both cases, the attacker did not need a new flaw. They took over an account that people already trusted. Think of a mailroom that screens parcels against a list of known bad senders. A hijacked account from a trusted colleague passes every check.
This shows why the gap between publication and a CVE matters. A CVE is the industry's record of what it has learned. It tells you little about what your build system installed this morning.
What the post does not tell you
This is a vendor describing its own product. Wiz gives no figures for how quickly the pipeline flags a bad version, how often it is wrong, or how many malicious packages it has caught. It says it keeps false positives to a minimum but gives no rate.
The pipeline described covers npm. The post does not say how it handles other package ecosystems. Its examples also come from Wiz's own research team.
Questions to put to your team
Ask how long it takes your tools to learn that a package version is bad after it is published. Ask whether any build pulls the latest version of a dependency without review.
Ask whether your tools can tell you which systems already installed a version that was later removed. Ask who owns that search.
If you assess a vendor in this area, ask for detection times, false-positive rates and the ecosystems covered. A CVE tells you what the world has learned. Your pipeline also needs to know what it has installed.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wiz.
