Zero-Day Vulnerability

A zero-day vulnerability, or 0-day, is a software flaw that attackers exploit before the vendor or maintainer has published a fix, so defenders have had zero days to patch it. A zero-day exploit is the code that abuses the flaw. In open source dependencies, the window also lasts until an advisory reaches the scanners that would flag it.

Zero-days are usually framed as a problem of rare, expensive bugs. In the open source supply chain they are routine. A malicious package is a zero-day by construction: it is dangerous from the minute it is published, no patch will ever exist, and the advisory that scanners depend on arrives after the damage. We think defending against that class means analyzing what a package does before it installs, because the vulnerability database is always behind.

A zero-day vulnerability is a flaw that is exploited before a patch exists. Google's Threat Intelligence Group (GTIG), which tracks exploitation in the wild, defines a zero-day as "a vulnerability that was maliciously exploited in the wild before a patch was made publicly available." The name counts from the defender's side: the day the vendor learns of the flaw is day zero, and an attack that comes first leaves no time to respond.

Every vulnerability moves through the same states: introduced in code, discovered, disclosed, patched, and fixed in deployed systems. A flaw is a zero-day while attackers know about it and defenders cannot yet fix it. After a patch ships it becomes an n-day, and the race moves to how fast users install the update.

That race has tightened. GTIG tracked 90 zero-days exploited in the wild in 2025, up from 78 in 2024 and below the record of 100 in 2023, and 48% of them hit enterprise software and appliances, an all-time high. Mandiant's time-to-exploit analysis found the average gap between disclosure and exploitation fell from 63 days in 2018 and 2019 to 5 days in 2023, and 97 of the 138 vulnerabilities it studied for 2023 were exploited as zero-days.

A zero-day exploit is the working technique or code that turns a zero-day vulnerability into an attack. The vulnerability is the flaw, the exploit is the means of using it, and the attack is the use. The distinction matters for defense. Patching removes the vulnerability; detection rules and network controls target the exploit; incident response deals with the attack.

Zero-day exploits for operating systems, browsers, and network appliances are scarce and expensive, and the groups that use them guard them. The open source supply chain has a cheaper equivalent. An attacker who publishes a malicious package, or takes over a maintainer's account and publishes a malicious version of a real one, needs no memory-corruption bug at all. Installation is the exploit.

Zero-days reach open source users in two ways: a flaw in a widely used library, and code that was malicious from the start. They fail defenders differently.

Log4Shell, tracked as CVE-2021-44228, was a remote code execution flaw in Apache Log4j 2, a Java logging library. Log4j evaluated lookup expressions inside logged strings, and one lookup type could fetch and load code from a remote server, so any attacker-controlled text that reached a log call could lead to remote code execution. Apache's security page rates it 10.0, the maximum CVSS score, and lists the affected versions as 2.0-beta9 up to the fixes in 2.3.1, 2.12.2, and 2.15.0.

The timeline shows a classic zero-day window. Chen Zhaojun of Alibaba Cloud Security Team reported the flaw to Apache privately on November 24, 2021. Cloudflare later found exploitation attempts in its logs from December 1, eight days before the flaw was disclosed publicly on December 9 at 14:25 UTC. The GitHub advisory, GHSA-jfh8-c2jp-5v3q, followed on December 10.

The harder problem came after the patch. Log4j was rarely a direct dependency. It sat several layers down as a transitive dependency, shaded into other JARs, or bundled inside vendor products. Teams spent the following weeks finding out whether they ran it at all. The zero-day window closed for Apache on the day it shipped a fix and stayed open for every organization that could not yet see where Log4j lived.

The axios compromise in March 2026 shows the other shape. Nothing in axios's code was flawed. An attacker first published a new package, plain-crypto-js, then released axios versions that depended on it. These are the registry's own timestamps, which we pulled with npm view on November 9, 2026:

$ npm view plain-crypto-js time --json | grep -E '"(4\.2\.[01]|0\.0\.1-security)"'
  "4.2.0": "2026-03-30T05:57:32.867Z",
  "4.2.1": "2026-03-30T23:59:12.278Z",
  "0.0.1-security": "2026-03-31T03:25:11.636Z",
$ npm view axios time --json | grep -E '"(1\.14\.1|0\.30\.4)"'
  "1.14.1": "2026-03-31T00:21:58.168Z",
  "0.30.4": "2026-03-31T01:00:57.285Z",

We flagged plain-crypto-js@4.2.1 at 00:05:41 UTC, six minutes after it was published and 16 minutes before the first poisoned axios release depended on it. npm replaced the package with a security holding version at 03:25:11 UTC.

The figure puts the two timelines side by side. For Log4Shell: reported privately to Apache on November 24, 2021; earliest exploitation seen on December 1; public disclosure on December 9 at 14:25 UTC; GitHub advisory and CVE-2021-44228 published on December 10, leaving at least eight days of exploitation before the public knew. For axios, all times UTC: plain-crypto-js@4.2.1 published on March 30 at 23:59:12; flagged by Socket on March 31 at 00:05:41; axios@1.14.1 published at 00:21:58 and axios@0.30.4 at 01:00:57, both pulling in the payload; npm replaced the payload package at 03:25:11; the GitHub advisory, published March 31, carries no CVE.

CVE scanners miss malicious packages because they match installed versions against advisories, and a malicious version has no advisory until after someone detects it. Most malicious packages never receive a CVE at all. The axios advisory, GHSA-fw8c-xr5c-95f9, is titled "Malware in axios" and lists no CVE ID or CVSS severity, which is what scanners that rank by score key on.

Some do get one. The xz backdoor received CVE-2024-3094, and the TanStack compromise on May 11, 2026 received CVE-2026-45321, classified as CWE-506, Embedded Malicious Code. Both identifiers arrived after detection. The advisory pipeline in the GitHub Advisory Database and the NVD is built to record what is already known, and an install that runs between publish and advisory is unprotected by design.

Install time is where most of these attacks execute. A malicious package with a preinstall hook or a Python .pth file runs the moment it lands, so a scan of the lockfile or the built image afterward reports the incident rather than preventing it. That is why we analyze what a package does when it is published and block it before install: the axios payload was flagged before the release that delivered it existed.

No single control covers both kinds of zero-day. The table compares the common ones:

Verdict: the two classes need opposite reflexes. For library zero-days, patch fast and use reachability analysis to decide what to patch first. For malicious versions, slow down: a dependency cooldown of a day would have skipped the axios payload, which npm replaced in under three and a half hours, and behavioral analysis catches what a delay does not. Run both, and resolve the conflict explicitly. Our coverage of pnpm 10.16's minimumReleaseAge calls zero-day patches the most contentious part of cooldowns. pnpm's minimumReleaseAgeExclude lets a team exempt specific packages, and npm added minimumReleaseAge in February 2026. The right policy is a default delay with a fast, reviewed exception path for security releases, not a delay so short it skips nothing.

The CVE system counts from disclosure, in days. Supply chain attacks count from publish, in minutes. A defense that waits for the first clock will always be late to the second.