Zero-day response · evidence note
How many zero-days are there?
No source can count the zero-days that remain unknown or privately held. Defenders can count only detected and disclosed cases under a stated definition—and should never use “zero-day,” “CVE,” and “known exploited” as synonyms.
The distinctions
Three labels answer three different questions.
Zero-day
A vulnerability exploited or available for exploitation before the affected party or defenders have an effective fix or practical prior warning. The label describes timing and knowledge, not severity.
CVE Record
A public identifier and record for a disclosed vulnerability. A CVE can be a zero-day, an older unexploited flaw, or a record published long after discovery.
CISA KEV
A vulnerability for which CISA has evidence of exploitation in the wild. An item can enter KEV long after a patch existed; KEV does not mean every entry was a zero-day.
Why a global count is unknowable
Detection and disclosure shape every public zero-day statistic.
Private use is invisible
An exploit can be used without detection. No public catalog can measure what has not been observed.
Definitions vary
Researchers differ on whether the clock starts at vendor knowledge, public disclosure, patch availability, or active exploitation.
Chains are clustered
One intrusion can reveal multiple vulnerabilities used together. Counting vulnerabilities, exploit chains, and campaigns produces different totals.
Records change
Exploitation status, affected products, dates, and root-cause analysis can be corrected after disclosure.
Google Project Zero’s tracker is useful because it explicitly tracks publicly known, detected in-the-wild zero-day exploitation and explains its inclusion limits. It is a research sample—not a global denominator.
Response order
What to do when the label is uncertain but the exposure may be real.
Establish authority
Name who owns the decision, affected scope, evidence sources, emergency change path, communications path, and stop conditions.
Bound exposure
Join software inventory, version, reachability, identity, privilege, data, dependencies, attack prerequisites, and observed indicators.
Reduce risk
Prefer a vendor fix. When none exists, evaluate isolation, feature restriction, access-control change, ASR or application-control policy, EDR detection, and monitoring.
Prove closure
Re-scan, validate the running artifact and configuration, test the exploit condition when authorized, monitor for regression, and retire temporary controls.
KEV in the priority model
Known exploitation is a strong signal, not a complete risk decision.
Use KEV as an accelerator
CISA describes KEV as the authoritative catalog of vulnerabilities known to be exploited in the wild and recommends it as an input to vulnerability-management prioritization.
Confirm the asset
Do not create an incident merely because a CVE appears in KEV. Confirm an affected product and version, the vulnerable component, the attack path, and compensating controls.
Hunt for evidence
Use vendor indicators, identity and process telemetry, network evidence, persistence checks, EDR investigation, and known-good comparison. Absence of an alert is not proof of absence.
MITRE ATT&CK use
Map behaviors and evidence without implying endorsement.
ATT&CK techniques, detection strategies, analytics, and data components can help a team ask whether its telemetry observes the behaviors relevant to an exploit chain. A mapping is a hypothesis to test—not proof that a control detects every implementation of a technique. Kythos AI references MITRE ATT&CK for defensive research and coverage analysis only. MITRE does not endorse Kythos AI, its services, or any product named on this site.