Zero-day vulnerability

What is a zero-day vulnerability?

A zero-day is a vulnerability exploited before a fix exists. Google Threat Intelligence Group (GTIG), which publishes the most-cited annual count, defines it as a vulnerability maliciously exploited in the wild before a patch was made publicly available. The name counts from the defender's side: on the day the flaw becomes known to them, they have had zero days to prepare.

Three related terms get blurred:

• Zero-day vulnerability: the flaw itself, while no patch exists.
• Zero-day exploit: the code or technique that uses it.
• Zero-day attack: the exploitation of it against a real target.

A freshly published CVE with a patch available is not a zero-day, even on the day it is announced. Vendors and headlines often use the word loosely; GTIG's definition requires both exploitation and no patch.

Zero-day vs n-day vs zero-click

Zero-click describes how an exploit is delivered, not when. Project Zero's analysis of FORCEDENTRY (CVE-2021-30860), an iMessage exploit chain, is the canonical example: the target receives a message and nothing else has to happen. An unpatched phone can be hit by a zero-click n-day as well.

The n-day distinction matters because it changes what defenders can do: for an n-day the fix exists, and the risk is the gap until it is applied. Every zero-day becomes an n-day the moment the fix ships, and the patch can make things worse for slow patchers, because comparing patched and unpatched code shows other attackers where the flaw is.

What does the data show?

Only figures from the primary reports:

• Count. GTIG tracked 90 zero-days exploited in the wild in 2025, compared with 78 in 2024 and 100 in 2023.
• Targets. 43 of the 2025 zero-days (48 percent) affected enterprise technology, an all-time high for both the number and the share. 21 were in security and networking products, and 14 affected edge devices.
• Speed. Mandiant's analysis of 138 vulnerabilities disclosed in 2023 and exploited in the wild found 97 (70 percent) were first exploited as zero-days. The average time-to-exploit fell to 5 days, from 63 days in 2018 to 2019. For the n-days, 12 percent were exploited within a day of the patch and 56 percent within a month.
• Trend. M-Trends 2026 estimates the mean time to exploit dropped to -7 days, meaning exploitation routinely begins before a patch is released, and reports that exploits were the most common initial infection vector for the sixth year running, at 32 percent of intrusions.

A real zero-day timeline: Citrix Bleed

CVE-2023-4966 in NetScaler ADC and Gateway shows how the phases fit together:

1. Late August 2023: Mandiant later identified zero-day exploitation starting here. Attackers stole session data from vulnerable appliances.
2. September 14, 2023: Citrix, acting as its own CVE Numbering Authority, reserved the CVE ID.
3. October 10, 2023: Citrix published its bulletin and the CVE record. The flaw became an n-day.
4. October 18, 2023: CISA added it to the KEV catalog.

Roughly six weeks as a zero-day, then continued exploitation as an n-day; the KEV entry records known use in ransomware campaigns. The detail that matters for response: Mandiant warned that hijacked sessions could persist after the update, so patching without terminating active sessions left stolen access working. A zero-day that was exploited before you patched is an incident, not only a patch ticket.

How do disclosure timelines work?

Coordinated disclosure gives a vendor time to fix before details go public. Google Project Zero's policy is a widely cited reference point:

• 90+30: the vendor has 90 days from notification to ship a patch, and technical details are published 30 days after the patch, giving users time to install it.
• Grace period: a vendor that will patch within 104 days can request a 14-day extension.
• In-the-wild bugs: when Project Zero finds evidence of active exploitation, the 90-day deadline becomes 7 days, with a 3-day grace period.
• Reporting transparency: since July 29, 2025, as a trial, Project Zero publicly lists the vendor, product, report date and deadline about a week after reporting, with no technical details or proof-of-concept code before the deadline.

Other researchers and coordinators use different clocks. For a defender, the practical point is that a disclosure date is when the public learns of a flaw, not when attackers did.

How do defenders reduce zero-day exposure?

You cannot patch a zero-day, so the work is shrinking what one can reach, noticing when one is used, and moving fast when the fix arrives. GTIG's 2025 review recommends much of this list.

1. Cut exposed attack surface. Take management interfaces, VPN admin portals and unused services off the internet, and segment DMZ, firewall and VPN appliances away from critical systems. About half of 2025's enterprise zero-days were in security and networking products. Knowing your attack surface is the prerequisite.
2. Keep an inventory that answers "do we run this?" in minutes. An asset inventory plus a software bill of materials turns an advisory into a list of affected hosts.
3. Have an emergency patch path. A process that bypasses the normal change window for KEV-listed and actively exploited flaws, with owners named in advance.
4. Apply the vendor's mitigation before the patch. Advisories for exploited zero-days often include a configuration workaround. Apply it, then verify it took effect.
5. Assume compromise if you were exposed during the zero-day window. Hunt for the published indicators, rotate credentials and invalidate sessions, as Citrix Bleed showed.
6. Detect behavior, not signatures. An unknown exploit has no signature, but its after-effects do: new processes on an appliance, unusual outbound connections, lateral movement. Canary tokens and kernel-level alerting catch activity that patch status cannot.

Public exploit code and exploitation scores help with the n-day phase: a proof-of-concept exploit appearing, or a jump in the EPSS forecast, is a signal to move a patch up the queue.

Written by Parameter · Last reviewed September 27, 2026