What is a zero-day vulnerability?
Simply put, a zero-day vulnerability, also known as a "zero day" or even just "0-day," is a weakness, or flaw, in the security of a device, software, or service for which the developer does not have a fix or workaround to prevent it from being abused. An attacker such as a criminal hacker can make use of (or exploit) the flaw in order to gain access to a system, or even get control of it.
In the case of a hardware device, a zero-day vulnerability could be something like a hard-coded credential that allows access to the device, or a configuration error that allows the device to be accessed by anyone without permission to do so and make changes to it.
In the case of software, a zero-day vulnerability could be used to grant the attacker privileges they otherwise would not have on the computer, gain access to secret or confidential information, or even run other programs on the computer--even code they have provided.
In the case of an online service, it could be that the zero-day vulnerability grants access to privileges within the online service that they otherwise would not normally have, the ability to access non-public information from the service such as customer data, or even the ability to run programs on the computer(s) hosting the online service, whether they are local to the computer or from somewhere else on the internet.
Note that the above are just some common examples of the types of zero-day vulnerabilities out there; they are not meant to be a complete or exhaustive list, but rather to illustrate how wide the range of zero-day vulnerabilities is.
How do zero-days happen?
Just as there are many different kinds of zero-day vulnerabilities, there are multiple reasons they can occur. Coding errors made when writing the affected program can be a common reason. While these are sometimes caught during security testing and validation, they may be complex enough or interconnected with coding errors in other programs that they are not found.
Conversely, the security testing and validation may have been insufficient to detect the coding error that leads to the vulnerability in the first place.
Exploiting a zero-day vulnerability
Now, for a zero-day vulnerability to be useful to the attacker, they must be able to trigger it. Depending upon the vulnerability, this could be as simple as typing a short command into something, or as complex as running something called the exploit code.
That could be a script, an entire program, or even a combination of these, and can include exploitation by otherwise benign software, such as utility programs included in the operating system or available as an optional download, legitimate-but-older versions of device drivers with vulnerabilities in them, and so forth.
The zero-day vulnerability’s exploit code may also not be targeted directly at a program or service, but targeted at or embedded in programs such as an extension or plugin that are used by the vulnerable program.
What qualifies as a zero-day vulnerability
Regardless of the type of zero-day vulnerability, in order for it to be classified as one, there have to be two qualifying conditions:
- First, the zero-day vulnerability has to be used "in the wild" to perform attacks on programs or services. This means it must be used against the vulnerable program or service by an attacker. If a researcher found a vulnerability, reported it to the developer and the developer fixed it, there would be no zero-day vulnerability since people using the software were never at risk from it before a patch or fix was available.
- Second, the zero-day vulnerability must not have any kind of fix, patch or workaround to prevent it. A zero-day vulnerability ceases to be a zero-day vulnerability once the developer of the affected code has provided instructions to mitigate it. Keep in mind, it still may be an unpatched vulnerability that is actively being exploited, but it is no longer a zero day.
A zero-day vulnerability may or may not always work reliably 100% of the time. Sometimes it may be very difficult for an attacker to successfully exploit a vulnerability. The exploit for a zero-day vulnerability may only work when certain conditions are met inside the vulnerable application, device, or service. Or the attacker’s exploit may be poorly-written.
But just because a zero-day vulnerability is not consistently reproducible does not make it less dangerous: Even if a zero-day vulnerability has a one-in-a-million chance of being exploited, an attacker may be able to easily perform millions of attacks in order for their exploit code to work. In the case of an attack by one program against another in memory, this might only take a matter of seconds to accomplish.
Scale and impact of attacks
If the attack were done over a network connection, it could be done using a botnet using hundreds, thousands, tens of thousands or even more computers. That could still take minutes, hours, days or even weeks to accomplish. For a determined-enough attacker, this would be quite an acceptable amount of time and effort, and pose little deterrent if they wanted access to the target.
Although there is a lot of value to having any kind of working exploit against a zero-day vulnerability, even one that takes hundreds or thousands of attempts to succeed, the more reliable an exploit is against a zero-day vulnerability, the greater the value to an attacker, as the attack is less “noisy” and less likely to be seen through audits, logs, and system monitoring.
However, any exploit is extremely valuable to an attacker, simply because there is no protection against it. Consider the number of computers out there running Microsoft Windows, the world’s most prevalent operating system. An attack exploiting an unknown zero-day vulnerability in that operating system could impact multiple millions of computers at once.
Once the attack was discovered, the source identified, and initial prescriptive advice given, it would be a race between the attackers and whatever mitigations and patches were put into place. And that’s not counting copy-cat attacks by opportunists who learn of the exploit and make use of it.
Discovery and disclosure
While a zero-day vulnerability may be discovered by a criminal hacker and then immediately used for attacks, it could be sold to the highest bidder, to a vulnerability broker, an offensive hacking company or even (reportedly) to a government.
Not all zero-day vulnerabilities are discovered by criminals, though. In some cases, they may be discovered by legitimate security researchers and are responsibly reported to the affected developers, who then fix them. Some companies may offer bug bounties—rewards—for reporting these. While this may not be as lucrative as using it yourself or selling it to the highest bidder, it can open doors, career-wise.
The financial value of a zero-day
Just how valuable is a zero-day exploit? A study by Vlad Tsyrklevich in 2015, titled Hacking Team: a zero-day market case study, found that in the market for zero-day exploits, prices began for a few tens of thousands of dollars up to $1-2 million for a working Apple iPhone exploit.
Ten years later in 2025, the price of a working “no-click” attack on a smartphone operating system like Android OS or iOS has risen to $9 million dollars, according to vulnerability broker Crowdfense.
Given the extreme payouts one can get for finding a widely-usable zero-day vulnerability on a popular platform, it is no wonder that zero-day vulnerabilities remain highly sought after by criminals.
In the case of Microsoft Windows, there are other considerations as well: A vulnerability may impact multiple versions of Windows, including obsolete versions which have reached their end-of-life (EOL) and are no longer supported by Microsoft.
But older versions of the Windows operating system can still be widely in use, ranging from hobbyists who see no reason to upgrade to enterprises running legacy—albeit critical—applications that do not work under modern, supported versions of Windows.
The case of the ETERNALBLUE
One such notable example is ETERNALBLUE, an exploit for a vulnerability in Microsoft Windows that allowed attackers to run programs remotely on computers. Originally discovered by the United States’ National Security Agency, it was apparently detected and repurposed by the Chinese Ministry of State Security, who began using it no later than March 2016, according to Symantec researchers.
While used sporadically for at least a year before its existence was made public on April 14, 2017 by a hacking group called the Shadow Brokers. On May 12, 2017, less than four weeks later, the ETERNALBLUE exploit was used combined with a fast-spreading worm named WannaCryptor (also known as WannaCry) that acted as ransomware. As a wormable, or self-spreading, exploit, the ransomware rapidly compromised computers in over 100 countries.
The threat from ETERNALBLUE was so extraordinary that Microsoft even released patches to fix the vulnerability in operating systems they had ended support for, such as Windows XP and Windows Server 2003 R2.
In the case of ETERNALBLUE, we have the zero-day vulnerability being exploited at a small scale for an indeterminate amount of time—but generally accepted to be at least a year—before it was publicly identified and patches released in April 2017. Even then, actual attacks became widespread in just a little under four weeks later in May 2017.
These days, widespread attacks can occur a few days or perhaps even a few hours later after knowledge of the vulnerability becomes known. It is possible this could be accelerated even further with some kind of help from AI technology to aid in weaponizatione or deploy itment.
While it is common today for developers to have processes in place to report security issues like zero-day vulnerabilities, not all zero-day vulnerabilities are always be fixable by the developer. In some cases, the developer may have gone out of business, or the vulnerability may be in an old and no longer supported device or code version.
It may be possible that third-party security software or firmware can block the zero-day vulnerability from being exploited. There may also be fixes from third-parties or community-sourced fixes that are available, too.
The case of the Zeroday Emergency Response Team
As an example of the latter, in 2006 vulnerabilities being exploited in Microsoft’s web browser and email client caused third-party security practitioners to band together as the Zeroday Emergency Response Team (ZERT) to release community-derived fixes for vulnerabilities in Microsoft Windows operating systems that were either not being patched promptly or at all, in the case of obsolete versions of Windows that were no longer supported. ZERT released two patches for Microsoft Windows in 2006.
Microsoft’s response to security vulnerabilities in its products has evolved in the intervening two decades since the Zeroday Emergency Response Team assembled, and the need for such rapidly-developed community patches for Windows has lessened.
Proactive steps to defend against zero-day threats
While it may not be possible to completely avoid zero-day vulnerabilities in all devices, software and services that you use, here are some steps that can at least prevent some of them, as well as reduce their impact:
- Keep all devices, software and services up-to-date. This may be as simple as testing and applying patches as soon as they become available, to purchasing support and maintenance contracts for them, to using a comprehensive vulnerability management system to monitor for outdated software and devices and patch them.
In some instances, vendors may sell extended security updates after mainstream updates have ended. - Do not use devices, software and/or services that are out-of-date and no longer maintained by their creators. This may not always be possible due to budget or technology issues, in which case care should be taken to limit their access to other parts of your network so that in the event of an exploit the amount of damage the attacker can do is minimized.
In the event the creator is no longer in business, you may also wish to see if support is available from a reputable third-party or community that may be able to provide patches or updates. - Protect endpoints with security software such as antivirus, EDR, MDR, or XDR and perimeters using firewalls from trusted, established and reputable vendors. While this may seem like a contrary recommendation, many endpoint and firewall security programs are capable of detecting not just specific zero-day exploits for vulnerabilities, but also the attempts from attackers to breach internal networks to exploit zero-day vulnerabilities through behavioral analysis, heuristics, AI/ML methods and advanced intrusion detection systems (IDS) and host-based intrusion protection systems (HIPS).
- Use tools from reputable security vendors or projects that can check for known vulnerabilities, and report them to you for mitigation. Examples of this include tools to scan computers for old, unpatched versions of software that contain vulnerabilities, or tools that scan a network for old devices that are insecure.
- Subscribe to security-related mailing lists, RSS feeds, or other announcements and bulletins from the creators of the devices, software, and services you use so that in the even a zero-day vulnerability is discovered, you will be able to take action.
- Build security obsolescence into your budget and plan to replace devices, software and/or services before they go out of support.
Given the scope of things which can be affected by them, there is no single way to prevent zero-day vulnerabilities, but by engaging in good security practices, you may be able to protect against many of them before they become a threat.
