Zero-Day Vulnerabilities: Defending Against Flaws Nobody Has Patched

A zero-day is a vulnerability the vendor has had zero days to fix — it's being exploited before a patch exists, sometimes before the vendor even knows. It's the scenario that makes "just keep everything patched" insufficient, because there's nothing to patch. Zero-days are rarer than headlines suggest and more consequential than most other vulnerabilities, and defending against them is really about limiting what an exploit can do once it works.

Definitions that get confused

• A zero-day vulnerability is a flaw unknown to the vendor (or known but unpatched) with no fix available.
• A zero-day exploit is working code that takes advantage of it.
• A zero-day attack is that exploit used in the wild.
• An n-day is a vulnerability that has been patched — but is being exploited against systems that haven't applied the patch. Most real-world intrusions are n-days, not zero-days, because patching lags.

Once a patch ships, the clock starts: attackers reverse-engineer it to build exploits, often within days, and race the defenders' patch cycles.

Who finds them and what they're worth

Zero-days are discovered by security researchers (who report them through bug-bounty and disclosure programmes), by vendors' own teams, by government agencies, and by commercial exploit developers who sell to governments. The market is real and priced: brokers publicly advertise millions of dollars for a reliable zero-click exploit chain against a current phone. Nation-state operations and mercenary spyware vendors are the primary users of premium zero-days; criminal groups tend to use them opportunistically once they leak or once cheaper n-days become available.

The counts are tracked. Google's threat-intelligence teams have recorded roughly 75–100 zero-days exploited in the wild per year in recent years, with a notable shift toward enterprise edge devices — VPN appliances, firewalls, file-transfer and remote-management tools — because a single exploit against those yields access to many organisations at once, and they're often poorly monitored.

The disclosure process

Coordinated vulnerability disclosure is the norm: the finder reports privately, the vendor develops a fix, and details are published after the patch is available — commonly with a 90-day deadline (Google Project Zero's policy set the standard) to prevent vendors sitting on flaws indefinitely. Vulnerabilities get a CVE identifier, a severity score, and — crucially — listing in the US CISA's Known Exploited Vulnerabilities catalogue if exploitation is confirmed. That catalogue, updated continuously, is the single most useful patch-prioritisation feed available: it tells you what attackers are actually using, rather than what's theoretically severe.

Defending when there's no patch

You can't patch a zero-day. You can make the exploit fail, contain it, or notice it quickly.

• Reduce attack surface. Every internet-facing service is a potential zero-day target. Put management interfaces behind VPN or zero-trust access; retire what isn't needed; don't expose what doesn't need exposing. An exploit for a service you don't run is irrelevant.
• Harden the platform. Modern exploit mitigations — memory-safe languages, control-flow integrity, sandboxing, hardware features like pointer authentication and memory tagging — make many vulnerabilities unexploitable or much harder. Keep systems on current OS versions where these are enabled. Apple's Lockdown Mode and browser site isolation are examples of shrinking surface for high-risk users.
• Least privilege and segmentation. An exploited web server that can't reach the database and runs as an unprivileged user is an incident; one with domain-admin rights on a flat network is a catastrophe. Design so that any single compromise is contained.
• Behavioural detection. Endpoint detection and response tools watch for what exploits do — spawn shells from a browser, dump credentials, disable security tools — rather than matching known signatures. This catches novel exploits by their post-exploitation behaviour.
• Virtual patching. Web application firewalls, intrusion-prevention rules and vendor-published mitigations can block a known exploit pattern before the fix ships.
• Threat intelligence. Vendor advisories, CISA alerts and sector information-sharing groups often flag active exploitation days before a patch. Have someone reading them.

When the patch arrives

Speed matters most for internet-facing systems and anything on the KEV list; CISA gives US agencies deadlines of days for those, and that's a reasonable benchmark for anyone. Have a process for emergency out-of-band patching that doesn't wait for the monthly window. Test, but don't let testing become the reason a known-exploited flaw stays open for a month. And after patching an appliance that was exposed during the exploitation window, assume it may already be compromised: check logs, look for webshells and new accounts, and rotate credentials that passed through it — several major incidents involved attackers who persisted through the patch.

The longer game

The industry response is to eliminate whole vulnerability classes rather than chase individual bugs: adopting memory-safe languages (Rust, Swift, Go) for new systems code, which removes the majority of exploitable flaws in the components attackers target most; secure-by-design commitments from vendors, pushed by government procurement; and regulation — the EU Cyber Resilience Act — that makes vendors legally responsible for reporting and fixing actively exploited vulnerabilities within tight deadlines. Zero-days will never reach zero. The goal is to make them expensive to find, hard to exploit and limited in what they achieve.