What is a zero-day vulnerability? Definition, examples, and defenses

The term “zero day” appears in cybersecurity news constantly, but the concept is often misunderstood. A zero-day vulnerability isn’t necessarily the most dangerous vulnerability in your environment. It’s a specific category of vulnerability that creates a particular kind of risk, and understanding what makes it different from other vulnerabilities is essential for managing it appropriately.

Most security teams overweight zero-day risk and underweight the far more common risk of unpatched known vulnerabilities. The defenses that close the zero-day window are largely the same ones that reduce exposure to the broader vulnerability landscape. Understanding the distinction is what allows IT teams and MSPs to allocate security effort accurately rather than reactively. Read the 2026 Kaseya State of the MSP Report — 69% of MSPs offer patch and update management as a service, because the window between vulnerability disclosure and patching is one of the most consequential intervals in IT security.

What is a zero-day vulnerability?

A zero-day vulnerability is a security flaw in software, hardware, or firmware that is unknown to the vendor responsible for fixing it, and therefore has no patch available at the time it is known to or exploited by attackers.

The term refers to the number of days the vendor has had to address the issue: zero. When a vulnerability is discovered by a researcher and disclosed responsibly to the vendor, the vendor has time to develop and release a patch before the vulnerability is widely known and exploited. A zero day, by contrast, is either exploited before any disclosure happens, or disclosed publicly without the vendor being notified first, leaving a window where systems are vulnerable and no fix exists.

The term is also written as 0-day, and zero-day can refer to the vulnerability itself, the exploit that takes advantage of it, or the attack that uses the exploit. Each has a distinct meaning, which is why the terminology gets confusing.

Once a patch is released, the vulnerability is no longer technically a zero day. It becomes a known vulnerability. But that transition doesn’t eliminate the risk. The practical exposure window is the period between when an attacker knows about a vulnerability and when an organization applies the patch for it, and for most organizations, that window can stretch to weeks or months even after a patch is available.

Zero-day vulnerability, exploit, and attack: the three terms defined

These three terms are often used interchangeably but describe different things.

A zero-day vulnerability is the underlying flaw in the software or firmware, the security gap that exists but has no patch. It’s a condition, not an action.

A zero-day exploit is the code, tool, or technique that takes advantage of that vulnerability. Security researchers use exploits to demonstrate that a vulnerability is real and exploitable. Attackers use them as weapons. When the broader security community talks about a zero day “being exploited in the wild,” they mean an exploit targeting the vulnerability has been deployed against real targets.

A zero-day attack is the operation that deploys the exploit against a target. A vulnerability can exist without being exploited. An exploit can be written without being used in an attack. The attack is the point at which a vulnerability creates measurable damage.

The distinction matters for incident response. An organization that identifies exploitation behavior on a system may be experiencing a zero-day attack, but the same behavior could also indicate exploitation of a known vulnerability that hasn’t been patched. Distinguishing between the two requires detection capability that goes beyond signature matching.

How zero-day vulnerabilities are discovered

Zero days are found through several distinct routes, and the route matters because it determines how quickly a patch arrives.

Security researchers who find vulnerabilities typically follow responsible disclosure processes, notifying the vendor privately and giving them a defined window (often 90 days, as in Google Project Zero’s standard) to develop a patch before public disclosure. In these cases, a patch may exist on the day the vulnerability becomes public knowledge, shortening the true zero-day window significantly.

Nation-state groups and sophisticated criminal organizations invest substantial resources in vulnerability research specifically to find exploitable flaws before vendors do. Zero days found this way are typically weaponized immediately and kept secret for months or years to preserve their value as attack tools. These are the most dangerous category because they exist and are being actively exploited before anyone outside the attacking group knows the vulnerability exists.

The zero-day market is a real and substantial economy. Brokers buy and sell zero-day exploits, with government intelligence agencies and criminal organizations both operating as buyers. A zero day in widely deployed software can command significant sums on this market, creating financial incentive for finding and hoarding vulnerabilities rather than disclosing them responsibly.

The practical implication for defenders is that you often cannot know whether a zero day in software you use exists and is being actively traded or exploited, because the defining characteristic of a true zero day is that it’s unknown to the vendor and the public. Defense has to be based on reducing the impact of a successful exploit rather than preventing the existence of the vulnerability.

Zero-day vs known vulnerabilities: which is more dangerous?

For most organizations, unpatched known vulnerabilities represent a greater operational risk than zero days.

Zero days get significant attention because they’re novel and because patches don’t exist. But they’re also relatively rare in the broader vulnerability landscape. The volume of publicly documented, patchable vulnerabilities in commonly used software at any given time is enormous. The vast majority of successful exploits in the wild use known vulnerabilities, often vulnerabilities with patches that have been available for months or years.

The data behind this isn’t ambiguous. Most significant breaches that get investigated and publicly attributed turn out to involve exploited known vulnerabilities rather than true zero days. The attackers go after the path of least resistance. An unpatched Exchange server with a CVE from 18 months ago is more accessible than a fresh zero day that took a nation-state’s research team months to discover.

The practical implication is that the best defense against the full vulnerability landscape, zero-day and known, is largely the same: rapid, automated patch management that minimizes the window between a patch becoming available and it being applied, combined with behavioral detection capability that can identify exploitation activity regardless of whether the specific vulnerability is known.

Zero days require two additional capabilities that known vulnerabilities don’t demand. Behavioral detection that identifies exploitation patterns without relying on known signatures. And compensating controls that limit the damage when a vulnerability can’t be patched because no patch exists yet.

High-profile zero-day examples

Log4Shell (2021)

The critical vulnerability in Apache Log4j, a widely used Java logging library, was publicly disclosed in December 2021. Within hours of disclosure, active exploitation began at scale. The combination of Log4j’s near-universal presence in enterprise Java applications and the severity of the vulnerability (remote code execution with minimal authentication required) made this one of the most significant zero-day events in the last decade. Organizations with automated patch management and asset inventory that showed their Log4j exposure were able to prioritize and respond. Those without either spent days discovering their actual exposure while exploitation was already underway.

ProxyLogon (Microsoft Exchange, 2021)

A Chinese state-sponsored group exploited ProxyLogon, a set of vulnerabilities in Microsoft Exchange Server, before Microsoft’s patch was available. The vulnerabilities allowed remote code execution on unpatched Exchange servers. By the time Microsoft released patches, thousands of Exchange servers globally had already been compromised through web shells that persisted after initial exploitation.

Chrome zero days (ongoing)

Google Chrome receives emergency patches for actively exploited zero days on a regular cadence, because browsers are complex software directly exposed to untrusted content. The pattern is consistent: a zero day is identified being exploited in the wild, Google releases an emergency patch, and organizations that haven’t automated browser patching remain exposed until the patch is manually deployed.

Stuxnet (2010) and EternalBlue (2017)

Stuxnet remains the defining example of a nation-state zero-day weapon. Discovered in 2010, it exploited four separate Windows zero days simultaneously to deliver a payload that caused physical damage to industrial centrifuges in Iran’s nuclear program. It remains notable for demonstrating that zero-day exploitation can cause real-world physical consequences, not just data loss.

EternalBlue, a zero-day exploit originally developed by the NSA and leaked in 2017, targeted the Windows SMBv1 protocol. It became the delivery mechanism for WannaCry and NotPetya, two of the most economically destructive cyberattacks in history. The underlying vulnerability had a Microsoft patch available by the time WannaCry launched, but millions of unpatched systems remained exposed, which is why an exploit for a disclosed vulnerability was still effective at catastrophic scale.

The consistent pattern across zero-day incidents is this: organizations that applied patches rapidly after they became available, or that had behavioral detection capable of identifying exploitation attempts, contained damage significantly better than those that didn’t.

Defending against zero-day threats

The defense strategy for zero days is the same as for the broader vulnerability landscape, with two additions.

Minimize the attack surface

The less software running in the environment, the fewer potential zero-day targets exist. Removing software that isn’t actively used, keeping browser extensions to the minimum necessary, and reducing internet-exposed services limits the exploitation opportunities. A zero day in software you don’t run cannot harm you.

Rapid automated patch management

Patching doesn’t help during the true zero-day window, but it drastically reduces exposure once a patch is released. The transition from zero day to known vulnerability to patched vulnerability should happen as quickly as possible, measured in days, not weeks. Kaseya VSA 10 and Datto RMM automate patch deployment across all managed endpoints on the day of release, with configurable ring-based approval workflows for changes that require testing before production deployment.

Behavioral EDR detection

EDR platforms that detect exploitation behavior, process injection, privilege escalation, unexpected child processes, unusual network connections from trusted processes, can identify zero-day exploitation even without a known signature for the specific vulnerability. Datto EDR provides behavioral detection that catches attack patterns rather than only known malware, which is what makes it relevant during the pre-patch zero-day window when no signature exists.

Network segmentation

Limiting what a compromised system can reach on the network reduces the blast radius when a zero day is successfully exploited. An attacker who exploits a zero day in a workstation shouldn’t automatically have a path to a domain controller, a file server, or a backup system. Segmentation doesn’t prevent exploitation, but it converts a catastrophic compromise into a contained one.

Vulnerability management

Continuous scanning that identifies unpatched software across the environment and prioritizes remediation based on exploit availability and asset criticality provides visibility into the most urgent exposure points. When a new zero day is announced, vulnerability management data shows immediately which assets are affected and how quickly response is needed.

Threat intelligence

Feeds that track active zero-day exploitation campaigns provide early warning, often days before a patch exists, that a specific vulnerability is being actively exploited. This enables compensating controls (rule changes, temporary feature disabling, network access restrictions) to be applied while a patch is developed.

Zero-day defense for MSPs: the patch window problem

For MSPs, the zero-day defense challenge isn’t conceptual. It’s operational. The period between a zero-day patch becoming available and that patch being deployed across dozens of client environments is the real exposure window, and without automation, it stretches.

Consider what manual patch coordination looks like at scale. A critical browser zero day drops on a Tuesday. The MSP team identifies the exposure, assesses which clients are affected, coordinates maintenance windows with each client, schedules the deployment, verifies success client by client. Best case, that process completes in three to four days across 30 clients. In environments where attackers start targeting newly disclosed high-severity vulnerabilities within 24 to 48 hours of disclosure, that window matters.

With Kaseya VSA 10 or Datto RMM, the same deployment goes out the same day under an automated patch policy, with ring-based staging that tests against a validation group before full production deployment. The maintenance window coordination is pre-configured. The verification happens automatically. The MSP’s exposure window compresses from days to hours for the clients running under that policy.

This is why 69% of MSPs offering patch management as a service isn’t just a business line, it’s the operational capability that makes the zero-day window defensible. The service is the system. Explore Kaseya VSA 10’s automated patch management for the operational model that makes rapid response to zero-day disclosures scalable across a multi-client environment.

Zero days get the headlines. Known unpatched vulnerabilities do most of the actual damage. The defense strategy that handles both is the same: reduce the attack surface, automate patching, deploy behavioral detection, segment the network. The organizations and MSPs that get the most out of these practices are the ones that run them continuously rather than pulling them out in response to the next high-profile disclosure. By then, the window is already open.