What is a zero-day vulnerability?
A zero-day vulnerability is a security flaw in software, hardware, or firmware that is unknown to the party responsible for fixing it. This means the vendor has had zero days to develop and release a patch, leaving every user of the affected system exposed to potential exploitation with no available fix.
The term "zero-day" originates from software release culture, where "day zero" referred to the moment a new piece of software became available. Applied to security, it describes the window of time a defender has to respond: zero. Unlike known vulnerabilities that carry a CVE (Common Vulnerabilities and Exposures) identifier and a published patch, a zero-day sits in a blind spot. You cannot scan for what no one has defined yet.
This is not a rare or theoretical problem. Google's Threat Intelligence Group tracked 75 zero-day vulnerabilities exploited in the wild in 2024, and that number climbed to 90 in 2025, remaining within the 60 to 100 range established over the previous four years. The trend is clear: zero-day exploitation is a sustained, growing reality that affects organizations of every size.
Because the term "zero-day" is used loosely across the industry, it is worth clarifying the key distinctions between the vulnerability itself, the exploit, and the attack.
Get a Free 1-on-1 Vulnerability Assessment
Learn what makes Wiz the platform to enable your cloud security operation
Zero-day vulnerability vs. zero-day exploit vs. zero-day attack
These three terms are often used interchangeably in media coverage, but they describe different stages of the same problem. Confusing them during an incident creates coordination delays when precision matters most.
| Term | Definition | Example |
|---|---|---|
| Zero-day vulnerability | The flaw itself, unknown to the vendor | A buffer overflow in a web server that nobody has discovered yet |
| Zero-day exploit | Code or technique that takes advantage of the vulnerability | A proof-of-concept script that triggers the buffer overflow to gain shell access |
| Zero-day attack | The real-world use of the exploit against a target | A threat actor deploying the exploit against a production system to steal data |
The distinction matters because your response changes at each stage. When a vulnerability is disclosed, you patch and mitigate. When an active exploit appears in the wild, you shift to detection and containment. When a confirmed attack hits your environment, you investigate and remediate. Getting the terminology right means your SOC, engineering, and leadership teams are all working from the same playbook.
Introducing zeroday.cloud: First-of-its-kind cloud and AI hacking competition
En savoir plus
How do zero-day attacks work?
A zero-day attack typically follows five stages, from initial discovery of the flaw through to the attacker's ultimate objective.
Discovery → Weaponization → Delivery → Exploitation → Post-exploitation
Discovery: A researcher, threat actor, or automated fuzzer finds a previously unknown flaw in software or firmware. At this point, no one else knows the vulnerability exists.
Weaponization: The discoverer, or a buyer who purchases the finding, develops a working exploit. Threat intelligence reporting shows that attackers often move from public disclosure to active exploitation within days, not weeks. Security teams should assume that a newly disclosed critical flaw may be targeted almost immediately.
Delivery: The exploit reaches targets through phishing emails, compromised websites (watering holes), supply chain compromises, or direct network access to exposed services.
Exploitation: The exploit triggers the vulnerability on the target system, giving the attacker initial access, typically through code execution or privilege escalation. In cloud environments, this might mean gaining a foothold on a container, a VM, or a managed service.
Post-exploitation: The attacker moves laterally, escalates privileges, exfiltrates data, or establishes persistence. Here is the critical insight for defenders: even when the initial exploit is entirely novel, the post-exploitation behavior usually follows well-documented tactics, techniques, and procedures (TTPs) mapped in the MITRE ATT&CK framework. The entry point may be unknown, but what happens next usually is not.
That last point is what makes behavioral detection so powerful against zero-day attacks. You do not need a signature for the initial exploit if you can catch the attacker stealing credentials from a metadata service, enumerating IAM permissions, or attempting a container escape. Correlating identity, network, workload, and data context is what turns those isolated signals into a coherent attack narrative that analysts can prioritize and act on quickly.
Who exploits zero-day vulnerabilities?
Not every threat actor has the resources to discover or purchase zero-day exploits. The actors who use them tend to fall into distinct categories:
Nation-state actors and APT groups: The primary consumers of zero-days for espionage and sabotage. Cyber-espionage threat actors, including government-backed groups and commercial surveillance vendors' customers, were responsible for more than half of attributable zero-day attacks in 2024.
Cybercriminal organizations: Financially motivated groups now regularly deploy zero-days in ransomware campaigns and large-scale data theft, as seen in the MOVEit and Kaseya attacks.
Commercial surveillance vendors: Companies like NSO Group develop and sell zero-day exploit chains to government clients, often targeting mobile devices for surveillance.
Hacktivists: Occasionally leverage zero-days for ideological campaigns, though this remains uncommon due to the cost of acquiring them.
The buyer of a zero-day exploit often differs from the developer, which fuels a thriving market.
The zero-day exploit market
Zero-day exploits are traded across three distinct market tiers:
White market: Bug bounty programs run by vendors and platforms like HackerOne, where researchers report vulnerabilities for payment through responsible disclosure. Google's Vulnerability Reward Programs have paid tens of millions in bounties over their lifetime.
Gray market: Government contractors and exploit brokers such as Zerodium purchase exploits for intelligence agencies. Payouts for high-value targets like mobile zero-click chains can reach millions of dollars, far exceeding typical bug bounty rewards.
Black market: Criminal forums where exploits are bought and sold for use in cybercrime campaigns, with no disclosure to the affected vendor.
This market exists because of a fundamental misalignment: vendors often patch too slowly, governments want offensive capabilities, and the price gap between bug bounties and gray or black market payouts creates a strong financial pull.
Zero-day vulnerability vs. N-day vulnerability
An N-day vulnerability is a known vulnerability for which a vendor patch or mitigation already exists, but the affected organization has not applied it yet. The "N" represents the number of days since disclosure or patch release.
Zero-day: No patch available. Defense relies on detection, behavioral monitoring, and compensating controls.
N-day: Patch available but not yet deployed. The fix is straightforward, but rolling it out across hundreds or thousands of workloads takes time.
CISA maintains the authoritative catalog of vulnerabilities exploited in the wild, and organizations should use it as an input to their vulnerability management prioritization framework. The CISA KEV catalog tracks both zero-days and N-days.
Notable zero-day vulnerability examples
These four incidents illustrate how zero-day attacks vary in method, motivation, and scale.
Stuxnet, discovered around 2010, was a nation-state cyberweapon targeting Iranian nuclear centrifuges. It exploited four separate zero-day vulnerabilities in Windows and demonstrated that software flaws could cause physical destruction of critical infrastructure. It fundamentally changed how the world thought about cyber-physical risk.
Log4Shell (CVE-2021-44228) hit in December 2021 as a critical remote code execution flaw in Apache Log4j, a ubiquitous Java logging library. CISA's advisory confirmed it affected hundreds of millions of devices across virtually every industry. When Log4Shell dropped, Bridgewater Associates' CTO described it as "digital COVID" because discovery of exposure was the critical first step, and the time to attack was wildly asymmetric to the time it took to protect.
The MOVEit Transfer zero-day (CVE-2023-34362) was a SQL injection flaw in Progress Software's file transfer tool. Exploited by the Cl0p ransomware group, it led to data theft from thousands of organizations including government agencies, banks, and healthcare providers. It showed how a zero-day in one enterprise tool creates cascading third-party risk.
SolarWinds/SUNBURST, discovered in December 2020, was a software supply chain attack in which threat actors compromised SolarWinds' Orion build process and distributed trojanized updates to approximately 18,000 customers. The attackers paired that build-system compromise with exceptional operational security, which helped the campaign evade detection for months.
How to protect against zero-day vulnerabilities
You cannot prevent zero-day vulnerabilities from existing. With exploits driving 33% of investigated intrusions according to Mandiant's M-Trends 2025 report, the goal is to reduce your exploitability, detect exploitation quickly, and minimize the blast radius when it happens.
Reduce the attack surface before a zero-day arrives
Enforce least-privilege permissions so that a compromised workload cannot pivot to sensitive data or critical services. Minimize the internet exposure of workloads and APIs through network segmentation. Maintain up-to-date software inventories, ideally backed by a software bill of materials (SBOM), so you can trace a vulnerable package from a base image to a running workload within minutes.
Pair that inventory with CVSS scoring, exploit intelligence, and software supply chain security controls in CI/CD so your team can separate urgent exposure from routine patching.
Detect exploitation without relying on signatures
Traditional antivirus and signature-based tools cannot catch zero-day exploitation because no signature exists yet. Behavioral analytics that baseline normal activity and flag deviations, such as anomalous API calls, unusual identity behavior, or unexpected outbound connections, give you detection coverage for novel threats.
Validate actual exploitability through runtime context
Not every instance of a vulnerable component needs emergency remediation. If a vulnerable library sits on disk but is never loaded into memory, the practical risk drops significantly. Runtime validation can dramatically reduce the scope of remediation during a zero-day event because it confirms which vulnerable libraries are actually loaded in memory.
Prepare for rapid response
Maintain a cloud-focused incident response plan that accounts for ephemeral resources like containers and serverless functions. Ensure automated forensic capture is in place so evidence is preserved the moment a threat fires, before the resource terminates. Map your detection coverage against frameworks like MITRE ATT&CK for Cloud to find gaps before a zero-day exposes them.
What to do when a zero-day vulnerability is disclosed
When a new zero-day drops, every security team asks two questions: "Are we exposed?" and "How bad could it get?" Here is a practical playbook:
Determine your exposure immediately: Inventory every instance of the affected component across all cloud accounts, workloads, and container images. Agentless scanning can map this across multi-cloud environments within minutes.
Prioritize by exploitability, not just presence: Rank instances by whether the vulnerable code is loaded in memory, whether the workload is internet-reachable, what identity permissions it holds, and what data it can access. This multi-factor prioritization connects vulnerability presence to real-world exploitability, which is what helped Maple improve MTTD and MTTR by 10x.
Apply compensating controls where patching is not instant: Restrict network access to affected workloads, tighten IAM permissions, and block known indicators of compromise (IOCs). These measures buy time.
Monitor for exploitation indicators: Enable or verify detection rules covering the specific CVE and related post-exploitation behavior. Check the CISA KEV catalog for active exploitation confirmation.
Patch the highest-risk instances first: Deploy fixes to workloads where the vulnerability is confirmed exploitable before rolling out broadly.
Conduct a post-incident review: Trace the vulnerable component back through your CI/CD pipeline to understand how it entered the environment and prevent recurrence through policy changes or pre-deployment scanning.
Wiz's approach to zero-day vulnerability response
Zero-day response isn't just about detection, it's about closing the gap between "we might be affected" and "we know exactly where, and we've contained it." Wiz covers that full arc, from code to cloud to runtime.
It starts before production: Wiz Code scans repositories and CI/CD pipelines to catch vulnerable components before they ship. When a zero-day is disclosed, an agentless SBOM identifies every affected asset across your environment in minutes, not days. Wiz Defend and the Runtime Sensor then take over at the sharp end — using eBPF monitoring and AI/ML-powered anomaly detection to spot active exploitation and contain it in real time. And the Dynamic Scanner validates what's actually reachable from the outside, so remediation focuses on the paths attackers would take.
The through-line is the Wiz Security Graph: a single model that connects code-level findings, cloud context, and runtime signals so every decision is grounded in real exposure, not assumptions.
Get a demo to see how Wiz helps your team move from disclosure to containment with full cloud context.
Detect active cloud threats
Learn how Wiz Defend detects active threats using runtime signals and cloud context—so you can respond faster and with precision.
