Safeguard
Vulnerability Analysis

What is a Zero-Day Vulnerability

A zero-day vulnerability is exploited before a patch exists. See real cases like Log4Shell and MOVEit, and how to cut response time.

Yukti Singhal
Security Analyst
Updated 7 min read

On July 9, 2021, Kaseya disclosed CVE-2021-30116, a zero-day authentication bypass in its VSA remote-monitoring software. Attackers linked to the REvil ransomware group exploited it before a patch existed, pushing malicious updates through roughly 60 managed service providers to hit an estimated 1,500 downstream businesses over a single Fourth of July weekend. That is what a zero-day vulnerability is in practice: a flaw that attackers can weaponize before the vendor has shipped a fix, leaving defenders with zero days of advance warning. The term covers the vulnerability itself, the exploit code written against it, and the window of exposure between first malicious use and patch availability. That window can last hours, as with some browser zero-days, or stretch for years — Stuxnet reportedly used a Windows zero-day (CVE-2010-2568) that had gone unpatched for roughly a year before public discovery in 2010. Knowing how to handle a zero-day vulnerability — before, during, and after that exposure window — is what separates organizations that contain an incident from ones that become the next case study.

What Makes a Vulnerability a "Zero-Day"?

A vulnerability earns the zero-day label the moment it is exploited in the wild before a vendor patch is publicly available, regardless of how the flaw was discovered. This distinguishes it from an N-day vulnerability, which has a known patch that organizations simply haven't applied yet — the far more common cause of real-world breaches. The lifecycle runs through four stages: introduction (the bug ships in code), discovery (a researcher or attacker finds it), exploitation (someone weaponizes it), and disclosure (the vendor and public learn about it). If exploitation happens before disclosure and before a patch exists, it's a zero-day. Once a CVE is published and a fix is available, the same flaw becomes an N-day, even if the underlying code defect never changes. Google's Threat Analysis Group and Project Zero jointly tracked 97 zero-days exploited in the wild in 2023, and Mandiant's M-Trends research has repeatedly found zero-day exploitation concentrated in a small number of widely deployed products — VPNs, browsers, and email servers chief among them.

How Do Attackers Find and Use Zero-Days?

Attackers find zero-days through the same techniques defenders use — fuzzing, manual code review, and reverse-engineering patches — then monetize or weaponize them before anyone else knows they exist. Nation-state groups often use custom fuzzing infrastructure against high-value targets like VPN appliances and hypervisors; commercial exploit brokers such as those supplying spyware vendors have reportedly paid over $2 million for a single zero-click iOS exploit chain, according to leaked price lists analyzed by researchers including Zerodium's public bounty tables. Once found, a zero-day is used in one of three ways: sold on gray-market broker platforms, stockpiled by intelligence agencies for targeted operations, or deployed directly by criminal groups for mass exploitation. The 2023 MOVEit Transfer zero-day (CVE-2023-34362), a SQL injection flaw exploited by the Cl0p ransomware group, illustrates the mass-exploitation path: Cl0p compromised over 2,700 organizations and more than 93 million individuals' records within weeks of first exploiting the flaw in late May 2023, according to breach-tracking firm Emsisoft.

What Are Some Well-Known Zero-Day Exploits?

Log4Shell (CVE-2021-44228), disclosed on December 9, 2021, is the most consequential recent zero-day because it affected Apache Log4j, a logging library embedded in an estimated hundreds of thousands of Java applications across enterprise software, cloud services, and consumer products. Within four days of disclosure, security researchers at Check Point recorded over 800,000 exploitation attempts against the flaw, which allowed unauthenticated remote code execution through a single crafted string in a log message. Other notable examples include EternalBlue (CVE-2017-0144), an NSA-developed Windows SMB exploit leaked by the Shadow Brokers in April 2017 and subsequently used in both WannaCry (over 200,000 systems in 150 countries in May 2017) and NotPetya (an estimated $10 billion in global damages per White House assessments); the 2020 SolarWinds Orion supply chain attack, which combined a compromised build pipeline with zero-day techniques to reach roughly 18,000 customers; and the MOVEit and Kaseya cases described above. Each of these shows a different attack surface — a logging library, an OS network protocol, a build pipeline, a file-transfer appliance — underscoring that zero-days aren't confined to any one layer of the stack.

How Are Zero-Days Different From Regular Vulnerabilities?

The difference is timing relative to patch availability, not severity or technical complexity. A regular, disclosed CVE with a patch is defensible through standard patch management — Verizon's 2024 Data Breach Investigations Report found vulnerability exploitation as an initial access vector nearly tripled year-over-year to 14% of breaches, and the large majority of those exploited flaws had patches available for months before the breach. A zero-day offers no such option during its exploitation window: there is no patch to apply, so defenses have to rely on compensating controls — network segmentation, web application firewalls, endpoint detection, and reducing what's actually reachable and exposed. This is why zero-day response and CVE/N-day remediation require different operational playbooks even though both eventually get a CVE identifier and a patch. Once a zero-day is patched, it is tracked, scored, and triaged exactly like any other CVE — the zero-day label describes a historical fact about how the flaw was first exploited, not a permanent property of the vulnerability record.

How Can Organizations Reduce Zero-Day Risk (and How Do You Handle One in the Moment)?

Organizations reduce zero-day risk primarily by shrinking attack surface and exposure time rather than by trying to predict which unknown flaw will be exploited next. In practice, how to handle a zero-day vulnerability once it's disclosed comes down to running containment and remediation in parallel rather than sequentially: isolate or compensate for the exposed service immediately, while a patch or upstream fix is tracked down and tested. Concrete measures include maintaining an accurate, continuously updated software inventory (an SBOM) so a newly disclosed zero-day can be matched against deployed components in minutes instead of days; segmenting networks so a single exploited service — like the MOVEit appliance in 2023 — can't reach 2,700 downstream environments; enforcing least-privilege access so successful exploitation doesn't automatically grant lateral movement; and monitoring for the anomalous behavior that follows exploitation (unexpected outbound connections, new scheduled tasks, unfamiliar child processes) since signature-based detection is structurally blind to a flaw nobody has documented yet. CISA's Known Exploited Vulnerabilities (KEV) catalog, which had grown to over 1,200 entries by mid-2024, exists precisely because rapid, prioritized patching after disclosure closes the highest-risk gap fastest — most damage from a given zero-day accrues in the weeks immediately following public disclosure, when exploit code proliferates faster than patching does.

How Safeguard Helps

Safeguard shortens the zero-day response window by telling teams, within minutes of a new CVE landing, exactly which of their running services actually call the vulnerable code path — Safeguard's reachability analysis cuts through inventory noise to separate "technically present" from "actually exploitable" so responders aren't triaging thousands of theoretically affected components. Because Safeguard continuously generates and ingests SBOMs across your build and runtime environments, that reachability check runs against a live, accurate map of what's deployed rather than a stale spreadsheet. Griffin AI, Safeguard's AI security analyst, correlates the new advisory against your codebase and dependency graph to draft a remediation plan in natural language, flagging which services need immediate isolation versus which can wait for the next patch cycle. For fixable cases, Safeguard opens auto-fix pull requests that bump the affected dependency to a patched version with the diff, changelog, and test impact already assembled, cutting the gap between disclosure and shipped fix from days to hours.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.