Anatomy of a Zero Day: What Happens When Nobody Knows

The term "zero day" gets thrown around in headlines like confetti. Every major breach, every nation-state campaign, every piece of sophisticated malware seems to involve one. But what does it actually mean? What happens between the moment a vulnerability exists and the moment it gets patched?

This is the lifecycle of a zero day, from birth to disclosure.

Day Zero

A zero-day vulnerability is, by definition, a flaw in software that the vendor does not know about. The "zero" refers to the number of days the developer has had to fix it: zero. No patch exists. No workaround has been published. The vulnerability is live, exploitable, and invisible.

Every piece of software has bugs. Most bugs are harmless. Some bugs create security vulnerabilities. A small fraction of those vulnerabilities are severe enough to allow remote code execution, privilege escalation, or data exfiltration. An even smaller fraction of those are actually discovered by someone before the vendor finds and fixes them.

Those are zero days.

The numbers help illustrate the rarity. Google's Project Zero, one of the most well-resourced vulnerability research teams on the planet, typically tracks somewhere between 50 and 80 zero days exploited in the wild per year. That sounds like a lot until you consider the billions of devices running millions of different software products. Each of those zero days represents a needle that someone found in a haystack the size of the entire digital economy.

Discovery

Zero days are found through several channels. Security researchers hunting for bugs in popular software. Government agencies with dedicated vulnerability research teams. Criminal organizations investing in exploit development. And occasionally, someone just stumbles across one while doing something entirely unrelated.

The methods vary enormously. Fuzzing (throwing massive amounts of random or semi-random input at a program to see what crashes) is an industrial-scale approach. Static analysis tools can examine source code for patterns that commonly lead to vulnerabilities. Manual code review, slow and expensive, remains the most reliable method for finding subtle logic bugs that automated tools miss. Reverse engineering compiled binaries without access to source code is the hardest path, but it is the one most commonly traveled by vulnerability researchers targeting closed-source software.

The discoverer faces a choice that shapes everything that follows: report it to the vendor (responsible disclosure), sell it on the vulnerability market (gray or black market), weaponize it for their own use, or publish it immediately (full disclosure). This decision determines the trajectory of the vulnerability's entire lifecycle.

Responsible disclosure, sometimes called coordinated disclosure, means notifying the vendor privately and giving them a window (typically 90 days, as established by Google's Project Zero) to develop and ship a patch before the details become public. This is the path most legitimate security researchers take. It is also the path that pays the least.

The Exploit Market

A working zero-day exploit for a major platform (iOS, Android, Windows, Chrome) can be worth millions of dollars. Companies like Zerodium publicly advertise bounty prices: up to $2.5 million for a zero-click iOS chain. Nation states pay more through private channels, and they do not publish price lists.

The market has several tiers. At the top are the nation-state buyers: intelligence agencies and their contractors. They pay the most because they have the largest budgets and the strongest motivation to keep exploits secret. Below them are the "gray market" brokers who buy from researchers and sell to governments, taking a cut in the middle. Below that are the criminal markets on dark web forums, where exploit code is sold alongside stolen credit cards and ransomware-as-a-service subscriptions.

This market creates a perverse incentive structure. The most valuable zero days are the ones that stay secret the longest. Every day a zero day remains unpatched, it retains its value. Disclosure destroys that value instantly. A researcher who finds a critical vulnerability in iOS faces a genuine economic dilemma: Apple's bug bounty program might pay $200,000, while a broker will pay $2 million. The math is not complicated. The ethics are.

The existence of this market means that zero days are not just technical artifacts. They are economic instruments, strategic assets, and political tools. Nations stockpile them the way they once stockpiled nuclear warheads: as deterrents, as first-strike capabilities, and as insurance policies.

Weaponization

A raw vulnerability is not the same as a working exploit. Turning a bug into a reliable, deployable weapon requires significant engineering effort. The exploit must work across different versions, configurations, and environments. It must be stable enough not to crash the target (a crashed application or a blue screen of death tends to attract attention). It must be stealthy enough not to trigger endpoint detection, network monitoring, or behavioral analysis.

This engineering process can take weeks or months. A memory corruption vulnerability might require a heap spray to get reliable control of execution flow. A logic bug might need a specific sequence of actions to trigger. A privilege escalation flaw might only work on certain kernel versions with specific configurations. Each constraint narrows the exploit's reliability and increases the development cost.

Exploit chains compound this complexity enormously. A single zero day might only get you partway to your objective. Chaining multiple vulnerabilities together (a browser bug for initial access, a sandbox escape to break out of the browser's isolation, a kernel bug for privilege escalation, and a persistence mechanism to survive a reboot) creates a complete attack path from "user visits a webpage" to "attacker owns the device." These chains are the most valuable products in the exploit market because they provide full, reliable compromise with minimal interaction from the target.

The development of exploit chains has become industrialized. Companies like NSO Group (creators of the Pegasus spyware) maintain teams of exploit developers who build and maintain chains targeting iOS and Android. When one link in the chain gets patched, the team replaces it. The chain is a living product, constantly maintained and updated. This is vulnerability research as a business, with engineering processes, quality assurance, and release cycles.

Detection

Some zero days are never detected. They are used sparingly, against specific targets, with careful operational security, and they simply never appear on anyone's radar. The most sophisticated nation-state operations may use a zero day once or twice, against high-value targets, and then retire it regardless of whether it has been discovered. The logic is simple: every use of an exploit increases the chance of detection, and a burned zero day is worthless.

Others are caught in the wild by security researchers, antivirus companies, or incident response teams investigating a breach. Google's Threat Analysis Group and Mandiant regularly publish analyses of zero days they have discovered being exploited. These reports are forensic narratives, tracing the exploit's behavior, identifying its targets, and sometimes attributing it to a specific threat actor.

The detection of a zero day in the wild triggers a cascade of events. The vendor is notified. A patch is developed under emergency conditions. A CVE number is assigned. Security firms update their detection signatures. The clock starts.

Patch and Aftermath

Eventually, every zero day dies. Either the vendor discovers it independently, a security firm detects it in the wild, or a researcher reports it. A CVE number gets assigned. A patch gets developed, tested, and released. The race shifts from exploitation to remediation.

But patching is not instant, and this is where the real damage accumulates. Enterprise environments can take weeks or months to deploy updates because patches need to be tested against internal applications, approved by change management boards, and rolled out in stages. Legacy systems may never be patched because the software is no longer supported, the hardware cannot run newer versions, or the organization simply lacks the resources to update.

The window between disclosure and widespread patching is where most of the real-world damage occurs. Once a patch is released, the vulnerability is effectively public knowledge. Attackers who did not have the zero day before can now reverse-engineer the patch to understand the vulnerability and build their own exploits. This creates a perverse race: the patch that protects updated systems simultaneously creates a roadmap for attacking unpatched ones.

Some vulnerabilities have remarkably long afterlives. EternalBlue, the NSA-developed exploit for a Windows SMB vulnerability, was patched by Microsoft in March 2017. Two months later, it powered the WannaCry ransomware attack that crippled hospitals, factories, and government agencies across 150 countries. The patch existed. Most victims had not applied it.

The zero day is dead. Long live the zero day.