A zero-day vulnerability is a security weakness that the software or hardware maker does not yet know how to fix when attackers can use it. The “zero” refers to the time available to ship a patch—not to the age of the bug. A flaw may sit unnoticed for years and become a zero-day only when someone discovers or exploits it before a fix is ready.
Source check: reviewed October 23, 2026 against the NIST Computer Security Resource Center glossary, CISA’s Known Exploited Vulnerabilities guidance, NIST’s enterprise patching guide and Google Project Zero’s in-the-wild research archive.
That distinction matters when an urgent browser, phone or operating-system update appears. “Zero-day,” “actively exploited” and “critical” describe different things, and the safest response depends on which one the vendor has actually confirmed.
Vulnerability, exploit and patch are not the same thing
A vulnerability is a weakness. NIST defines a software vulnerability as a flaw or weakness in code that an attacker could exploit. An exploit is the technique or code that turns that weakness into an effect, such as reading data, running commands or gaining more privileges. A patch changes the affected software or its settings to repair or reduce the problem.
NIST’s glossary defines a zero-day attack as an attack that exploits a previously unknown hardware, firmware or software vulnerability. In everyday security reporting, “zero-day vulnerability” is also used for the underlying flaw before a vendor fix is available.
| Term | What it tells you |
|---|---|
| Vulnerability | A weakness exists |
| Exploit | Someone has a way to use the weakness |
| Zero-day | The weakness was unknown or unpatched when exploitation became possible |
| Exploited in the wild | Defenders have evidence that real attackers used it |
| Proof of concept | Demonstration code exists; it does not by itself prove real attacks |
| Patch | The maker has released a change intended to fix or mitigate the weakness |
| CVE | A public identifier for a specific disclosed vulnerability |
A high severity score does not prove exploitation. Conversely, a flaw used in a narrow targeted attack can be urgent even before its full technical impact is public.
The zero-day timeline
The clock is easier to understand as a sequence.
- The bug is introduced. A coding error, unsafe design choice or unexpected interaction creates a weakness.
- Someone discovers it. The finder may be a vendor, independent researcher, government team or attacker.
- The vendor investigates. A coordinated report can give the maker time to reproduce the problem and prepare a fix before technical details are public.
- Exploitation may begin. If attackers use the flaw before a patch exists, defenders face a true zero-day window.
- A fix or mitigation ships. The vendor may release an update, disable a feature, recommend a configuration change or provide another temporary control.
- Disclosure follows. An advisory usually identifies affected versions, the CVE, available fixes and any evidence of exploitation.
Disclosure ends the “unknown” part, but not the danger. Attackers can study a published patch, compare old and new code and build exploits for systems that remain unpatched. The risky period therefore continues until vulnerable devices are updated, isolated or replaced.
What “exploited in the wild” means
Security researchers use the phrase when they have evidence that an exploit was used against real targets, not only demonstrated in a lab. Google Project Zero maintains a root-cause analysis archive for publicly known zero-days detected in the wild. Its work shows why the count is always incomplete: defenders only learn about attacks they detect, investigate and disclose.
“In the wild” also says nothing about how broadly the exploit was used. A campaign may target a handful of people, or it may scan the internet. Check the vendor advisory for scope, affected versions and attack prerequisites instead of reading the label as a measure of prevalence.
Why a CVE may appear after the attack
CVE identifiers give defenders a common name for a publicly known vulnerability. NIST describes CVE as a dictionary of names, while the National Vulnerability Database adds standardized information used by security tools.
An attacker does not need a CVE to exploit a flaw. The identifier can be assigned during the response or disclosed with the patch. That is why the order may look backwards: exploitation first, CVE and detailed advisory later.
A CVE record is also not a complete instruction sheet. The vendor’s advisory remains the primary place to check:
- affected products and versions;
- whether exploitation has been observed;
- the fixed version or required configuration;
- temporary mitigations;
- whether a restart or other action is required.
How defenders decide what to patch first
A zero-day label raises urgency, but prioritization is still a risk decision. CISA says organizations should use its Known Exploited Vulnerabilities Catalog as an input to vulnerability-management priorities. The catalog is evidence-led: entries have known exploitation, a CVE and clear remediation guidance.
Start with four questions:
- Is the product exposed? An internet-facing gateway is easier to reach than an internal system behind several controls.
- Is exploitation confirmed? A vendor statement or KEV entry matters more than speculation on social media.
- What can the attacker gain? Remote code execution, authentication bypass and privilege escalation create different paths.
- What will the change disrupt? Test where practical, but do not let a routine maintenance cycle delay an emergency fix without compensating controls.
NIST’s enterprise patching practice guide treats isolation and other mitigations as possible emergency alternatives when a patch cannot be applied immediately. A mitigation buys time; it is not automatically equivalent to the vendor’s permanent fix.
What you should do when a zero-day is announced
For a personal device, the useful response is short:
- install the vendor’s update from the device or application’s built-in updater;
- restart if the advisory requires it;
- remove software you no longer use if it cannot be updated;
- avoid unofficial patches and links from messages claiming to provide a fix;
- check that automatic updates are still enabled.
For an organization, first identify every affected version rather than updating only the machine that triggered an alert. Preserve logs, follow the vendor’s indicators and mitigation steps, and look for evidence of compromise when the advisory recommends it. A patch can close the door without removing an attacker who entered earlier.
Controls such as least privilege, application isolation and phishing-resistant sign-in can limit what an exploit achieves. They do not make vulnerable software safe. Our guide to hardware security keys explains one strong sign-in control, while the report on macOS Full Disk Access changes shows how operating-system permissions can restrict a compromised application.
Why updates can still take time
Emergency updates compete with availability. A hospital, factory or payment system cannot always restart immediately, and a hurried patch may break a critical dependency. That operational reality is why mature programs keep an asset inventory, test representative systems and plan isolation routes before a crisis.
The trade-off is not “patch or do nothing.” It is patch now, apply the vendor’s mitigation while testing, isolate the system, disable the affected feature, or stop using the product. The acceptable option depends on exposure and business impact.
