What Is a Zero-Day Exploit?

A zero-day exploit is an attack technique that targets a software vulnerability for which no patch is publicly available. The name refers to the number of days the vendor has had to fix the flaw: zero. Google's Threat Intelligence Group uses the same threshold in its annual tracking, counting a vulnerability as a zero-day when it was maliciously exploited in the wild before a patch was public.

The term is used loosely in practice, and the looseness causes real confusion in incident calls.

Zero-Day Vulnerability, Exploit, and Attack

A vulnerability can exist for years without an exploit. An exploit can exist in a private toolkit without ever being used. The three terms mark three separate stages, and treating them as synonyms obscures which stage a given piece of intelligence describes.

Once a patch becomes public, continued exploitation is generally described as n-day exploitation. The vulnerability may still be referred to historically as a zero-day because attackers used it before a fix was available, but the immediate defensive problem has shifted toward asset discovery, mitigation, and patch deployment.

How Often Zero-Days Are Exploited

Google's Threat Intelligence Group tracked 90 zero-day vulnerabilities exploited in the wild during 2025, against 78 in 2024 and a record 100 in 2023. Counts have stayed within a band of roughly 60 to 100 for several years.

The target mix has shifted. Enterprise technologies accounted for 43 of the 2025 total, or 48%, up from 36 and 46% in 2024 and the highest share recorded. Security and networking products made up about half of that enterprise figure, drawing sustained attention from state-linked operators. Browser exploitation fell over the same period to under 10% of the annual total.

These figures count detected and disclosed exploitation, so they set a floor rather than a total. Exploitation that was never found is not in the data.

Why Signature-Based Defenses Miss Them

Most detection is built on knowledge of past attacks. A vulnerability scanner matches installed versions against a database of published advisories. An intrusion detection system matches traffic against signatures written from observed attacks. Both approaches need the flaw to be documented first.

A zero-day has no published CVE record at the time of exploitation, no advisory, no signature, and no patch to apply or verify. Every control that asks "is this a known bad thing" returns no. The same gap applies to CVE-less threats more generally, where the absence of an identifier does not indicate the absence of risk.

What remains available is behavior. An exploit still has to make the application do something it does not normally do: spawn a shell, deserialize attacker-controlled data, load a remote class, write to a path outside its working directory. Those actions are observable at runtime whether or not the underlying flaw has a name.

Log4Shell as a Worked Example

CVE-2021-44228 in Apache Log4j 2 is the widely studied case. Chen Zhaojun of the Alibaba Cloud Security Team reported it to Apache on 24 November 2021, and version 2.15.0 shipped on 9 December. When CISA announced that release the following day, its advisory described the vulnerability as already under exploitation.

The mechanism was simple. A crafted string, written into a log by ordinary application code, triggered a JNDI lookup that fetched and executed a remote class. Three properties made it severe: the vulnerable component was a logging library sitting deep in the dependency trees of thousands of unrelated products, the trigger was user-supplied input that applications were designed to log, and exploitation required no authentication.

The patching sequence is the part most retellings omit. The fix in 2.15.0 turned out to be incomplete in certain non-default configurations, which produced CVE-2021-45046 and a second release, followed by two further advisories and releases through late December. Teams that patched once in the first week were not finished.

Organizations that could enumerate where Log4j ran recovered faster than those that could not. Guidance on identifying and remediating affected deployments is covered in this walkthrough of how to patch the Log4j vulnerability.

What Reduces Zero-Day Exposure

No control prevents a zero-day, because prevention would require knowing about the flaw first. Exposure is reduced by limiting what a successful exploit can reach and by detecting the behavior rather than the signature. GTIG, which reports vulnerability exploitation as the leading initial access vector in Mandiant incident response investigations, ahead of both stolen credentials and phishing, publishes its own guidance along these lines.

1. Constrain privilege and reachability. Segment DMZs, firewalls, and VPNs from core networks and domain controllers so a compromised external component does not enable lateral movement. Do not expose device network ports to the internet unless strictly required.
2. Monitor execution flow inside applications. GTIG's recommendation is specific: monitor execution flow within applications to block unauthorized database queries and shell commands. An exploit still has to make the application act, and that action is observable without prior knowledge of the flaw.
3. Maintain a software bill of materials. GTIG names Log4j as the example of why: an SBOM is what lets a team locate affected libraries across an environment once a zero-day is disclosed.
4. Prepare to bypass change management. Establish in advance a process for patching outside the normal cycle, and stop-gap isolation measures for cases where no patch exists yet.
5. Shorten the ordinary patch cycle. Exploit code proliferates after disclosure, and GTIG observes a shrinking gap between public disclosure and widespread exploitation by multiple groups. Time-to-patch governs the n-day risk that follows every zero-day.

Layered together these shrink the window and the blast radius. None of them closes the window.

Raven Runtime Prevention works from execution rather than from signatures, stopping malicious behavior inside the running application whether or not the underlying vulnerability has been disclosed.

‍