What Is a Zero-Day Vulnerability?

A zero-day vulnerability is a security flaw in software or hardware that’s unknown to the vendor — or known but not yet patched — at the moment someone starts exploiting it. The name comes from the vendor having had “zero days” to fix it before attackers found a way in. Once a patch ships and the flaw becomes public, it stops being a zero-day and just becomes a vulnerability with a fix available, even if plenty of unpatched systems remain exposed.

The zero-day lifecycle

A zero-day typically moves through a few stages:

1. Discovery. A researcher, a criminal group, or a state-sponsored team finds an exploitable flaw — often through fuzzing, manual code review, or reverse-engineering a patch for a related bug.
2. Weaponization. The finder builds a working exploit that reliably triggers the flaw to achieve something useful: code execution, privilege escalation, data exfiltration.
3. Use. The exploit gets deployed, either narrowly against specific high-value targets (common for state actors, who want to avoid burning the exploit) or broadly against many targets at once (common for criminal groups monetizing it quickly).
4. Discovery by defenders. Security researchers, the vendor, or an affected organization eventually notices the exploitation — through anomaly detection, an incident investigation, or the exploit surfacing in a criminal marketplace.
5. Disclosure and patch. The vendor issues a fix, usually alongside a public advisory and a CVE identifier so the flaw can be tracked and referenced consistently.

The gap between steps 1 and 5 is the window where a zero-day is most dangerous — no patch exists, and depending on how narrowly it’s being used, no detection signature exists either.

Zero-day vs n-day

The industry draws a line between a zero-day (unpatched, and either unknown to the vendor or known but with no fix yet available) and an n-day (a vulnerability with a patch already published). N-day exploits are arguably more common in real-world attacks than true zero-days, because a large fraction of systems don’t apply patches promptly — attackers can weaponize a disclosed CVE and hit unpatched targets for months or years afterward with far less research investment than finding a fresh zero-day requires. This is one reason patch management is treated as a core security control rather than a low-priority chore.

Who finds zero-days, and what they do with them

• Security researchers and bug bounty hunters report findings to vendors, often through coordinated disclosure programs, in exchange for recognition or a bounty payment.
• Vendor security teams and red teams find flaws in their own or partner products before external parties do — the practice covered in AI red teaming is the same underlying discipline applied to models and AI systems instead of traditional software.
• Exploit brokers buy and sell zero-days, sometimes to governments, sometimes to security vendors building defensive products.
• Criminal groups use or sell zero-days for financial gain — ransomware operators in particular have shown they’ll pay well for a reliable initial-access exploit.
• State-sponsored actors tend to hoard zero-days for espionage or, less often, disruptive attacks, and typically use them narrowly to avoid getting the flaw discovered and patched.

Coordinated disclosure

Most legitimate researchers follow coordinated disclosure (sometimes still called “responsible disclosure”): report the flaw privately to the vendor, give them a defined window — often around 90 days, though timelines vary by program — to build and ship a fix, and only publish technical details after the patch is out or the window lapses. This balances two competing interests: give defenders time to patch before attackers can reverse-engineer the report, but keep vendors from sitting on unfixed flaws indefinitely by attaching a deadline.

The alternative, full disclosure, publishes details immediately with no advance notice to the vendor. It’s rare and controversial, generally reserved for cases where a vendor has ignored a private report entirely.

Why zero-days are hard to defend against

Traditional signature-based detection — antivirus, intrusion detection systems keyed on known attack patterns — is built around recognizing threats that have already been seen and cataloged. A true zero-day, by definition, hasn’t been. That’s why zero-day defense leans on different techniques: behavioral monitoring that flags anomalous activity regardless of the specific exploit used, network segmentation and zero trust architectures that limit what a successful exploit can reach, and layered controls like a web application firewall that can block exploitation attempts based on suspicious request patterns even without a signature for the specific flaw.

Defense in depth matters more here than almost anywhere else in security: no single control reliably stops a zero-day, but overlapping controls narrow the blast radius and buy time for detection and patching.

Why patching fast still matters

Once a vendor ships a fix, attackers routinely reverse-engineer the patch to figure out exactly what changed and build a working exploit for unpatched systems — often within days. This turns yesterday’s zero-day into today’s actively exploited n-day almost immediately, which is why the interval between “patch available” and “patch applied” is one of the most consequential windows in an organization’s security posture, alongside the software supply chain risks covered in software supply chain security.

The takeaway

A zero-day vulnerability is dangerous specifically because no fix exists yet — defenders can’t patch around a problem they don’t know about. Coordinated disclosure programs try to shrink the exposure window by giving vendors time to fix flaws before details go public, while layered defenses like network segmentation, behavioral detection, and a WAF reduce what any single unpatched flaw can do in the meantime. Once a patch ships, the real risk shifts from the zero-day itself to how quickly it gets applied — attackers reverse-engineer patches fast, and a slow rollout turns a fixed vulnerability back into an open door.