Zero Day Vulnerability: What Defenders Do First

A zero day vulnerability is not a magic category that suspends normal operations. It is a time gap in which defenders may lack a patch, complete indicators, or even a reliable affected product list.

Panic wastes that gap. Teams forward a dramatic headline, scan for a CVE that may not exist yet, and order every owner to patch when no fix is available. Meanwhile, nobody can answer the useful questions: Which product is involved? Which instances are reachable? What behavior would show exploitation? Which reversible control buys time?

The right response is disciplined uncertainty. Verify the source, narrow the asset set, reduce attacker reach, hunt for effects, and keep the case open until new evidence proves the fix. Fast. Specific. Reviewable.

What is a zero day vulnerability?

A zero day vulnerability is a product weakness that can be exploited before a public patch is available. Some definitions focus on whether the vendor knew about the flaw. Others focus on whether exploitation occurred before the fix. The label is most useful when the reporting source states its rule.

The NIST zero day attack definition describes an attack that exploits a previously unknown hardware, firmware, or software vulnerability. Google Threat Intelligence Group uses a narrower research rule: malicious exploitation in the wild before a patch was publicly available. This article uses that rule for statistics and keeps the broader operational question separate.

A vulnerability is the weakness. The exploit is code or a technique that uses it. The attack is the observed use against a target. Public disclosure can happen before or after any of those events. A CVE ID can arrive later. Do not make one field stand in for the whole timeline.

How common are zero day vulnerabilities?

Google tracked 90 vulnerabilities disclosed in 2025 that were exploited as zero days. Its March 2026 review of zero day exploitation places the annual total in a range of 60 to 100 during the prior five years. The researchers warn that the dataset reflects detected and disclosed activity, not every successful exploit.

The target mix matters more than the headline count. Forty three of the 90 cases affected enterprise software and appliances, a record 48 percent share. Twenty one involved security and networking products. Operating systems accounted for 39 cases, or 44 percent of the total. Memory safety issues represented roughly 35 percent of the tracked vulnerabilities.

Those numbers reject the old mental model of zero days as mainly browser exploits used against a few executives. Edge devices, enterprise applications, virtualization, security appliances, desktop systems, and mobile platforms all appear in the data. Coverage plans should follow deployed technology and attacker access value, not the last famous incident.

What changed about zero day risk in 2026?

On May 11, 2026, Google reported the first case in which its analysts had high confidence that a cybercrime actor used an AI model to support discovery and weaponization of a zero day. The Python exploit bypassed two factor authentication in a popular open source administration tool. Google coordinated disclosure with the vendor and did not name the product or claim that the campaign caused damage.

The Google AI threat tracker report matters because it moves AI assisted exploit development from prediction to an observed criminal workflow. It does not prove that every attacker can discover reliable flaws on demand. It does shorten the useful life of a response process that waits for complete public analysis before scoping assets.

Leaders should fund faster evidence retrieval, not another source of dramatic alerts. If the team needs two days to identify exposed product instances, an attacker with faster exploit development is only exposing an existing inventory and ownership problem.

What should happen in the first hour?

Open one incident record with a named lead. Capture the original advisory, publication time, affected products and versions, reported exploitation status, patch state, available mitigations, known indicators, confidence, and next review time. Save copies or hashes of volatile source material. Rumor and confirmed fact need separate fields.

Then ask asset owners for evidence, not reassurance. Query software inventory, package versions, appliance models, listening services, internet exposure, identity privileges, network position, and business role. A product name match is the beginning of scope. It is not the final affected set.

Establish two workstreams. The exposure stream finds and reduces reachable instances. The investigation stream searches for attack effects. Patching belongs to the exposure stream once a fix exists. Incident containment belongs to the investigation stream when evidence suggests compromise. Mixing both into one ticket causes owners to close the security incident when they deploy the update.

How do you scope a zero day without a complete signature?

Begin with the broadest defensible product set, then subtract with evidence. If an advisory names a family of edge appliances, inventory every model and software train in that family. Confirm management and data plane exposure. Check whether an affected feature is enabled. Record unreachable, disabled, fixed, and unknown states instead of forcing a yes or no answer.

A four state board works: affected, not affected, mitigated pending fix, and unknown. Every row needs an owner and evidence time. Unknown is an active queue, not a parking lot. Assign the next query, console check, vendor question, or physical inspection required to resolve it.

Link public facts to the local record through the National Vulnerability Database operating guide and the CVE record reading model. When the public record changes, update only that layer and recalculate the affected set. Do not overwrite the earlier evidence.

What can you do when no patch exists?

Choose the smallest control that breaks the reported path and can be reversed. Disable the affected feature. Restrict an administration interface to a trusted network. Remove direct internet access. Block a documented request pattern. Reduce account privilege. Rotate exposed credentials. Shut down a nonessential service. The responsible vendor or coordinator should be the source for product specific mitigation.

Every temporary control needs an owner, implementation evidence, test, expiration condition, and rollback plan. A firewall rule that nobody tests is a hope. A service shutdown without a restoration trigger becomes permanent operational debt.

Be careful with generic advice. A web application firewall rule can help with a request driven exploit, but it will not stop a local privilege escalation. Network isolation can reduce reach, but it does not remove persistence from a host already compromised. Match the control to the stated exploit path and known unknowns.

How do you detect a zero day attack?

You may not detect the exploit instruction itself. Look for what the attacker must do before and after it: unusual access to an exposed service, a new child process, unexpected account creation, changed startup state, credential access, outbound connections, lateral movement, or data staging. Build hypotheses from the product role and reported impact.

Preserve logs before rebooting or upgrading. Capture process, network, account, file, and configuration evidence with times. If telemetry is absent on an edge device, use surrounding identity, DNS, proxy, firewall, flow, and downstream host data. Google found 14 zero days affecting edge devices in 2025 and noted that limited host detection may cause undercounting. Your investigation plan should expect the same blind spot.

How should teams prioritize the affected set?

Use reach and consequence before asset count. Imagine 2,400 systems carry a named product. Eight percent are reachable from an untrusted network, which leaves 192. Twelve of those have privileged access to a sensitive service. Start with the 12, then the remaining reachable systems, then internal instances. Do not send 2,400 identical urgent tickets.

Two responders checking 18 systems per hour can review 36 systems per hour. The 192 reachable systems take about 5.3 hours before exceptions. That math tells a leader whether to add staff, automate evidence collection, or reduce scope through a network control. It is more useful than arguing over whether the headline says critical.

Cross check active exploitation through the CISA KEV workflow and current vendor reporting. KEV inclusion confirms known exploitation under CISA criteria. It does not prove that the issue began as a zero day or that your asset is compromised.

How can you check the official CISA KEV feed?

This verified command retrieves the live catalog and selects the Oracle E Business Suite case that Google reported as exploited before a patch was available. It prints the dates, required action, and ransomware field.

curl -fsSL \
  'https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json' \
  | jq '.vulnerabilities[]
      | select(.cveID == "CVE-2025-61882")
      | {cveID, dateAdded, dueDate, requiredAction, knownRansomwareCampaignUse}'

The official CISA KEV catalog contained 1,682 entries in version 2026.08.26 when checked. The date is part of the claim. Store the catalog release time and the selected record rather than copying the current result into an undated ticket.

When is a zero day response actually complete?

Completion needs two proofs. First, current asset state shows the fixed version, removed product, or tested mitigation on every in scope instance. Second, the investigation has resolved the attack hypotheses or moved confirmed evidence into incident response. A dashboard count reaching zero is not enough if stale assets or uncollected logs fell out of view.

Deep endpoint context with AI driven analysis can help reconcile versions, controls, and missing evidence. That is how Artemes approaches review. The source and observation must stay visible, and practitioners must decide whether the evidence closes exposure or opens an incident.

Hold a short review after closure. Record which inventory fields were missing, which ownership handoffs stalled, which control reduced reach, and which verification query proved the fix. The next zero day should begin with a better evidence path than the last one.

Frequently asked questions about zero day vulnerabilities

Does zero day mean there is no CVE?

No. A vulnerability may receive a CVE before, during, or after public disclosure. Zero day describes the timing of knowledge, exploitation, and patch availability, not whether an identifier exists.

Does installing the patch prove there was no compromise?

Installing a patch can remove the vulnerability without removing an attacker who already gained access. Review the exploitation window and investigate relevant behavior before closing the incident question.

Can security tools block an unknown vulnerability?

Controls can block prerequisites or effects without knowing the exact flaw. Least privilege, segmentation, application controls, behavior monitoring, and restricted administration paths can reduce impact. None is a universal guarantee.

When does a zero day stop being a zero day?

Research definitions vary. Under the Google rule used for this article, classification depends on whether exploitation happened before a public patch. Later patching does not change that historical result.

The executive takeaway

Test the response path before the next headline. Pick one internet facing product and prove that the team can find every instance, name an owner, apply a reversible control, preserve investigation data, and verify fresh state within four hours. If it cannot, the zero day problem is already inside your operating model.