Vulnerability Intelligence

Zero-Day Vulnerabilities and Exploited CVEs: A Practical Guide

Understand zero-day vulnerabilities, exploited CVEs, CISA KEV, CERT-In monitoring, and evidence-led response without confusing active exploitation with a confirmed incident.

Abstract, text-free illustration of a protected network shield beside a glowing vulnerability pathway and security monitoring nodes.

Zero-day vulnerabilities are vulnerabilities exploited before defenders have had a meaningful chance to fix or patch them.** An exploited CVE, by contrast, is any CVE with observed exploitation and can include an older, already patched “n-day” vulnerability. Keeping those ideas separate helps security teams interpret alerts without turning every new identifier into a zero-day claim. The operational question is not only “Is this severe?” It is “What evidence shows exploitation, which assets are affected, what does the vendor recommend, and what should be checked before and after remediation?” This guide explains that process using the CISA Known Exploited Vulnerabilities (KEV) Catalog, CISA’s Citrix NetScaler alert, Google Threat Intelligence Group (GTIG) research, and CERT-In’s 2026 Vulnerability Notes. For a related view of the wider response cycle, see [ransomware attacks and recovery guidance](https://cyberoinfo.com/cybersecurity/ransomware-attacks-and-recovery-2026). This article is an evidence-led explainer, not a live incident notice. Catalogs and advisories change, so rolling updates should always show their review date. > **Key Takeaways > - A zero-day is generally exploited before a vendor fix or before defenders have had a meaningful opportunity to patch; an exploited CVE may be an older n-day. > - CISA describes its KEV Catalog as the authoritative source for vulnerabilities exploited in the wild and recommends using it in vulnerability-management prioritization. > - GTIG reported 141 distinct vulnerabilities disclosed and exploited in its January–August 2026 dataset, compared with 127 in all of 2025; its definitions and scope are specific to that research. > - CERT-In’s 2026 Vulnerability Notes are a useful India-first monitoring layer, but a listing alone does not prove exploitation or an Indian victim. > - When exploitation is confirmed, teams should verify affected versions, follow vendor guidance, check for compromise where recommended, preserve evidence when compromise is suspected, and apply relevant updates promptly.

What Are Zero-Day Vulnerabilities?

A **zero-day vulnerability** is best understood by its timing and defensive opportunity. Editorial guidance for this topic uses the term for a vulnerability exploited before a vendor fix or before defenders have had a meaningful opportunity to patch. The label describes the gap between exploitation and available protection; it does not automatically describe the severity, victim, campaign, or outcome.

A CVE identifier is a way to refer to a disclosed vulnerability, not proof that the vulnerability is being exploited. A zero-day can later receive a patch, enter a vulnerability catalog, and become an exploited n-day if exploitation continues after defenders have had time to update. That lifecycle is why a dated status and a named source matter more than a dramatic label.

For a practical zero-day risk assessment, separate four questions: Is exploitation confirmed by an authoritative source? Is the affected product present in the organisation? Is a fix or mitigation available? Is there evidence of compromise in the relevant environment? Keeping those questions distinct supports calm, defensible triage and avoids claiming an incident that the evidence does not establish.

The same discipline applies when communicating with non-specialists. Say “CISA reported active exploitation” when that is what the source says; say “CERT-In listed a vulnerability” when that is all the listing establishes. Do not convert a catalog entry into a claim about Indian compromise, ransomware, victims, or an exploit kit without supporting evidence.

How Are Exploited CVEs Different From Zero-Days?

Exploited CVEs are a broader category than zero-day vulnerabilities.** An exploited CVE is a vulnerability with observed exploitation, while a zero-day usually emphasizes exploitation before a fix or meaningful patching opportunity. An old vulnerability can therefore be actively exploited without being a zero-day, particularly when systems remain unpatched.

CISA’s KEV Catalog is central to this distinction. CISA describes the catalog as the authoritative source for vulnerabilities exploited in the wild and says organisations should use it as an input to vulnerability-management prioritization. The catalog showed 1,739 results when accessed on 2026-10-12, but that number is a time-stamped catalog observation, not a count of zero-days, incidents, or victims.

The practical result is a two-track workflow. Track newly exploited or zero-day items for urgent verification and containment, while also treating older KEV-listed vulnerabilities as active operational risk when affected assets remain exposed. A security patch management process should record the CVE, product and version, evidence source, vendor fix or mitigation, owner, review date, and patch-verification result.

A useful internal status vocabulary is “confirmed exploitation,” “KEV-listed,” “vendor-reported,” and “inference.” This makes an alert easier to audit and reduces the chance that a severity score, a news headline, or a vulnerability disclosure will be mistaken for proof of exploitation.

What Does Current Evidence Show About Exploited CVEs?

Google Threat Intelligence Group (GTIG) reported that vulnerabilities exploited in the wild increased from an average of 10.5 per month in 2025 to 18 per month from January through August 2026. In the same dataset, GTIG recorded 141 distinct vulnerabilities disclosed and exploited during January–August 2026, versus 127 in all of 2025. GTIG also estimated that 0.23% of all vulnerabilities disclosed in 2026 had been observed in active exploitation. These are GTIG measurements with defined coverage and definitions, not a universal count of every global exploit.

GTIG separately reported that zero-day exploitation increased from an average of 8 per month in 2025 to 11 per month in January–August 2026, with 22 zero-days in August 2026. It said zero-days represented 62% of all observed exploited vulnerabilities in its January–August 2026 dataset. Readers should preserve that scope when citing the figures: they describe GTIG’s observations, not every vulnerability disclosed worldwide.

CISA’s KEV observations provide a different kind of evidence: an operational catalog that changes as vulnerabilities are added. The research file notes current first-page entries including ProFTPD CVE-2015-3306, added on 2026-10-08, and Check Point CVE-2026-85102 and CVE-2026-93616, added on 2026-09-22. Their presence in KEV supports an exploited-in-the-wild status under CISA’s catalog, but does not make each one a zero-day.

For readers following broader security operations, [software supply-chain attacks and malicious packages](https://cyberoinfo.com/cybersecurity/software-supply-chain-attacks) show why the evidence question must stay specific. A report about a package, product, or campaign can establish a relevant risk without establishing that every related CVE was exploited or that every organisation using the technology was affected.

How Should Teams Use CISA KEV and CERT-In?

Use CISA KEV for exploited-in-the-wild prioritization and CERT-In for an India-first vulnerability-notice layer.** Neither source replaces asset inventory, vendor guidance, version checking, or compromise assessment. The safest workflow joins the sources to the organisation’s own affected-asset data rather than treating a list as an automatic incident declaration.

Start with the CISA entry or advisory and record the CVE, affected product, addition date, source wording, and recommended action. Then check the vendor’s security advisory for supported versions and mitigations. If the product is not present, document the validation rather than assuming exposure. If it is present, identify internet-facing, privileged, or business-critical instances first, while keeping the source date visible.

CERT-In’s official 2026 Vulnerability Notes index was marked “Last Updated On October 12, 2026.” Its latest listed notes included Cisco products, MikroTik RouterOS SSH pre-authentication rekey state bypass, Citrix NetScaler denial of service, Android, Google Chrome desktop, and Microsoft Outlook remote code execution. Those listings show current Indian government vulnerability-notice activity; they do not, by themselves, say that the entries were exploited or caused Indian incidents.

For browser-related maintenance and version checks, [browser security guidance](https://cyberoinfo.com/cybersecurity-tools/browser-security) can sit beside this workflow. Keep the India angle precise: CERT-In can help teams find relevant notices and remediation paths, but a CERT-In listing is not evidence of an Indian victim. Record the last-reviewed date because KEV and CERT-In listings change.

How Should Teams Respond to Zero-Day Vulnerabilities?

When an authoritative source confirms exploitation, the first action is to verify whether the organisation runs an affected product and version. CISA’s Citrix alert, revised on 2026-10-09, recommends reviewing Citrix guidance, checking for compromise before patching, preserving evidence where compromise is suspected, and applying relevant updates promptly. These steps should be adapted to the product guidance and the organisation’s incident-response process.

The same alert said threat intelligence and reports confirmed global active exploitation of Citrix NetScaler CVE-2026-88771 and CVE-2026-88772. CISA characterized both as critical zero-days that can independently enable remote code execution and said they were added to KEV on 2026-09-27. CISA also said CVE-2026-88779 was added to KEV on 2026-10-04; in some SAML configurations it can independently cause denial of service and, on unpatched deployments, may help accelerate execution of code previously injected through CVE-2026-88771.

The alert lists ten related CVEs in total, including CVE-2026-107406. That does not mean every related CVE has the same exploitability, effect, or status. Teams should read the specific vendor and CISA wording, preserve logs and other evidence when compromise is suspected, and avoid making claims about a victim, campaign, or Indian incident unless an authoritative source confirms it.

A simple incident response for zero-days can therefore be framed as: identify affected assets; restrict or isolate exposure when appropriate; follow the vendor’s mitigation or update path; check for compromise before patching when instructed; preserve evidence; verify the update; and continue monitoring for new guidance. If the situation expands into a wider business-continuity problem, [India cybersecurity and CERT-In reporting guidance](https://cyberoinfo.com/cybersecurity/india-cybersecurity) is the natural related topic, but current official procedures should always be checked before action.

Frequently Asked Questions

### Is every exploited CVE a zero-day?

No. An exploited CVE may be an older vulnerability that has already been patched or publicly documented. “Zero-day” generally refers to exploitation before a fix or before defenders have had a meaningful opportunity to patch, while “exploited CVE” focuses on observed exploitation.

### Does a CERT-In Vulnerability Note prove exploitation in India?

No. The research evidence says CERT-In’s 2026 index demonstrates current official vulnerability-notice activity. It does not, by itself, establish exploitation, an Indian victim, or an incident. Use the note to find the relevant advisory and then verify product exposure, source wording, and vendor remediation.

### What is the CISA KEV Catalog used for?

CISA describes KEV as the authoritative source for vulnerabilities exploited in the wild and recommends using it as an input to vulnerability-management prioritization. It should be combined with asset inventory, vendor advisories, version checks, and compromise assessment rather than treated as a complete incident report.

### Should teams patch before checking for compromise?

The answer depends on the affected product and authoritative guidance. In its Citrix NetScaler alert, CISA recommended checking for compromise before patching, preserving evidence where compromise is suspected, and applying relevant updates promptly. Follow the specific vendor and CISA instructions, with incident-response support when compromise may have occurred.

Limitations

  • Evidence and guidance can change; verify current advisories and organisational applicability before acting.

Evidence sources

  1. cisa.gov — CISA Known Exploited Vulnerabilities Catalog
  2. cisa.gov — CISA: Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway
  3. cloud.google.com — Google Threat Intelligence Group: Vulnerability Discovery and Exploitation Trends in the AI Era
  4. cert-in.org.in — CERT-In 2026 Vulnerability Notes
  5. support.google.com — Google Trends FAQ about Trends data