Zero-Day and Exploited Vulnerabilities Guide

Attackers now exploit many vulnerabilities before a patch exists or within days of one, so a monthly patch cycle and a CVSS threshold no longer decide when you are exposed. This guide covers zero-days (flaws exploited before a fix is public) and n-days that are known to be exploited, and the decisions that matter in between: how to prioritise with CISA KEV, EPSS, SSVC and CVSS v4.0, how to run an emergency response, how to cut exposure when no patch exists, and why patching does not end the incident. It is for vulnerability management leads, security operations teams and infrastructure owners. Routine patch cadence and tooling are in the Patch Management Guide; this page starts where a vulnerability is already being used in attacks.

Key takeaways

• Exploitation status beats severity. A medium-scored flaw in the CISA Known Exploited Vulnerabilities (KEV) catalogue is more urgent than a critical one nobody is using.
• The window has collapsed. Google found an average time-to-exploit of five days in 2023, and 70% of the exploited flaws it studied were zero-days.
• Enterprise products are the main targets. Of 90 zero-days Google tracked in 2025, 48% hit enterprise technologies, about half of those security and networking products.
• Mitigate first, patch second, hunt always. When no fix exists, disable the vulnerable component or restrict who can reach it; when a fix ships, assume exploitation may already have happened and investigate in parallel.
• Patching closes the hole, not the intrusion. Stolen session tokens, machine keys, service account passwords and web shells survive the update, so rotation of the secrets the product held is part of every response.

Zero-day, n-day and known exploited: the terms that set your clock

Google Threat Intelligence Group (GTIG) defines a zero-day as "a vulnerability that was maliciously exploited in the wild before a patch was made publicly available." An n-day is exploited after the fix is out. Each term changes what you can do.

CISA defines active exploitation as "reliable evidence that execution of malicious code was performed by an actor on a system without permission". A public PoC is not required for a KEV listing, so the absence of exploit code is no comfort.

What the data says about speed and targets

Use primary research to set policy, not headlines. Four findings are worth building into your standards:

• Volume stays high: GTIG tracked 90 zero-days exploited in the wild in 2025, against 78 in 2024 and a record 100 in 2023. Enterprise technologies reached an all-time high of 43 (48%), and 14 affected edge devices, a figure GTIG says "likely underrepresents the true scale of activity due to inhibited detection capabilities."
• Exploitation is faster: in Google's time-to-exploit (TTE) study of 138 vulnerabilities disclosed in 2023, average TTE fell to five days, from 32 days in 2021 to 2022 (excluding 15 outliers; with them it is 47 days). Of the n-days, 29% were exploited within a week and 56% within a month.
• The most exploited flaws started as zero-days: the joint advisory from CISA, the NCSC and partners on 2023's top routinely exploited vulnerabilities found that the majority of the top 15 were first exploited as zero-days, against fewer than half in 2022. The NCSC's CTO, Ollie Whitehouse, called this "the new normal". The list includes Citrix NetScaler (CVE-2023-3519, CVE-2023-4966), Cisco IOS XE (CVE-2023-20198), FortiOS SSL-VPN (CVE-2023-27997), MOVEit Transfer (CVE-2023-34362) and Log4Shell (CVE-2021-44228).
• Old flaws stay useful: the same advisory says actors "continue to have the most success exploiting vulnerabilities within two years after public disclosure", so the n-day backlog is a live risk, not housekeeping.

Google also found that 72% of 2023 vulnerabilities with a public PoC were not known to be exploited, concluding that "exploit release and media attention are not predictive of exploitation timelines." For the first time, GTIG attributed more 2025 zero-day exploitation to commercial surveillance vendors (sellers of spyware and exploitation capability) than to state espionage groups, and financially motivated groups used nine, as in the Oracle E-Business Suite exploitation by Cl0p.

Prioritising with KEV, EPSS, SSVC and CVSS v4.0

No single score is enough. Combine an exploitation signal, a likelihood signal and your own exposure and impact.

A workable decision rule for most organisations:

1. Exploited and reachable: KEV-listed, vendor-confirmed or national CERT-confirmed exploitation on an internet-facing or widely reachable asset goes straight to the emergency process below.
2. Exploited but internal: exploited flaws on assets not reachable from the internet get a short deadline (CISA's BOD 22-01 default is two weeks for CVE IDs assigned in 2021 or later) and compensating controls in the meantime.
3. Likely to be exploited: high EPSS or SSVC Attend on exposed assets moves ahead of high CVSS on internal assets.
4. Everything else: normal patch cadence, with a documented owner for exceptions. The NCSC calls the decision not to update "a senior-level risk decision."

Emergency response when exploitation is confirmed

The NCSC treats a critical vulnerability confirmed on an exposed system you own, with in-the-wild exploitation, as an incident, not a patching task. Its guidance on responding to active exploitation sets these timescales for business-critical systems listed in KEV:

Write the runbook in advance, with named owners and pre-approved change authority:

1. Scope within hours: query the asset inventory, external attack surface data and software bills of materials (SBOMs) for every instance, including lab and disaster recovery copies. Embedded libraries such as Log4j are where inventories fail.
2. Read the advisory for compromise checks: the NCSC's first step is to read the vendor advisory and assess compromise with any published checks. Collect logs and support bundles before rebooting or upgrading. Do not run public exploit code to confirm exposure; the NCSC warns it may itself be malicious.
3. Isolate or restrict: block access at an upstream firewall, disable the vulnerable component or restrict access to your organisation's IP ranges, as the NCSC lists. See the Firewall Management Guide.
4. Investigate in parallel with fixing: check outbound connections, traffic against baseline and configuration changes since exploitation began while IT applies the update. If that is not possible, the NCSC says the system should be "erased/destroyed and rebuilt as new."
5. Update in shortened rings: non-critical instances first, then critical ones, hours apart. Keep the previous configuration backup and version to roll back to if the update breaks authentication.
6. Rotate and revoke: reset credentials, keys and sessions the product could read (see the compromise assessment section).
7. Report and hunt: report confirmed compromise to the relevant authority (in the UK, via gov.uk/report-cyber) and keep hunting after re-enabling. See the Incident Response Guide.

Hotpatching

Hotpatching removes the restart that makes emergency patches wait for a window. Microsoft's Windows Server hotpatch "patches the in-memory code of running processes without the need to restart the process", for Windows Server 2025 via Azure Arc and specific Azure Edition images. A quarterly baseline cumulative update (restart required) is followed by two hotpatch months, and Microsoft may issue an unplanned baseline for a zero-day fix. Drivers, firmware and .NET still need a restart, and there is no automatic rollback: you reinstall the last baseline. Linux kernel live patching serves the same purpose. Neither helps appliances, where most edge zero-days land.

Reducing exposure when no patch exists

GTIG's guidance for the period before a fix is direct: "If a patch is unavailable, isolate systems and components with stop-gap measures such as disabling specific services or blocking specific ports at the perimeter." Options, from strongest to weakest:

• Take the service offline: for an internet-facing file transfer, VPN or management interface under mass exploitation, an outage is cheaper than an intrusion. Pre-agree the fallback access path. See the ZTNA Guide.
• Remove exposure: GTIG advises: "Do not expose network ports of devices to the internet when not strictly required." Management interfaces belong on a management network, not the internet.
• Apply the vendor mitigation: configuration changes, mitigation files or signatures. Recheck the advisory daily, because vendors revise mitigations that turn out not to work.
• Restrict by source: allowlist known IP ranges or front the service with an authenticating proxy.
• Segment and contain: Google's TTE study recommends segmented architectures and access control "to limit the extent of impacted systems and data when exploitation does occur." Separate DMZ, VPN and firewall management planes from identity systems and data stores. See the Network Segmentation Guide.
• Virtual patching and exploit protection: WAF rules, IPS signatures and exploit protection (ATT&CK mitigation M1050) are bypassable bridges with an expiry date, never remediation.
• Raise detection: place canary tokens and baseline normal processes on affected hosts, as GTIG recommends.

For zero-click and browser exploitation of user devices, GTIG's advice is to apply updates as soon as they are available and enable Lockdown Mode or Advanced Protection for high-risk staff.

Compromise assessment: why patching is not enough

If exploitation started before your fix, the update closes the door with the attacker possibly still inside, which is why the NCSC advises checking for indicators of compromise before updating. Look for:

• Web shells and implants: new files in web roots followed by the web server spawning shells or interpreters (ATT&CK T1505.003). Compare hashes against a known-good build.
• New or changed accounts: local admin accounts on appliances, new directory accounts, new OAuth applications or API keys created around the exploitation window.
• Stolen secrets in use: authentication from appliance or server IP addresses with credentials the product stored, and sessions that began before the patch.
• Configuration drift and outbound traffic: forwarding rules, disabled logging, changed authentication settings and new outbound destinations since the first exploitation date.

Preserve evidence before you rebuild. See the Digital Forensics (DFIR) Guide.

Where identity fits

Many exploited products are identity brokers: VPNs, gateways, file transfer servers and collaboration platforms hold service account passwords, LDAP bind credentials, API keys, signing and machine keys, and live user sessions. Memory disclosure bugs leak these directly, as Heartbleed (CVE-2014-0160) did with TLS private keys, and as the CitrixBleed and CitrixBleed 2 flaws did with session tokens that bypassed MFA. In the ToolShell SharePoint exploitation, stolen ASP.NET machine keys kept attackers inside after patching until the keys were rotated. Build the rotation list per product in advance:

• Sessions: terminate all active and persistent sessions after patching. See the Token and Session Security Guide.
• Service accounts and bind credentials: reset directory accounts the product used, and review what they accessed. See the Service Account Security Guide.
• Keys and certificates: reissue TLS certificates, machine keys and signing keys on hosts where memory or files could have been read.
• Stored API keys and integration secrets: rotate them and check their use since the exploitation date. See the Leaked Credential Response Playbook.

Vulnerability disclosure and working with vendors

Coordinated vulnerability disclosure (CVD) gets flaws fixed before attackers find them. CISA's CVD programme runs in five steps: collection, analysis, mitigation coordination, application of mitigation and disclosure. If a vendor does not respond, "CISA may disclose vulnerabilities as early as 45 days after the initial attempt to contact the vendor is made." The joint advisory on 2023's most exploited flaws asks vendors to "Establish a vulnerability disclosure program" and to publish CVEs with the correct CWE root cause.

• If you build software: follow ISO/IEC 29147:2018 (Vulnerability disclosure), which covers receiving reports and publishing remediation information, and ISO/IEC 30111, which covers the handling process between receipt and disclosure. Publish a security.txt file (RFC 9116) so researchers can find you.
• If you buy software: ask vendors for their disclosure policy, advisory feed, SBOM and exploitation notification process. Programmes that pay researchers for coordinated disclosure, such as vendor bug bounties and vendor-agnostic programmes like the Zero Day Initiative, feed this pipeline; exploit brokers selling to offensive buyers do not.
• If you find exploitation: report it to the vendor and your national CERT; your evidence may get the flaw into KEV.

Subscribe the owning team, not a shared mailbox, to vendor PSIRT feeds, the KEV feed and national CERT alerts. See the Threat Intelligence Guide.

Decision guidance by organisation size

• Small organisations: update automatically wherever possible (the NCSC's first principle is to update by default), list your internet-facing products, subscribe to KEV and those vendors, and prefer managed services over self-hosted edge products you cannot patch within 24 hours.
• Mid-sized organisations: automate KEV and EPSS enrichment, give the emergency tier authority to take services offline, and contract incident response support in advance.
• Large organisations: run SSVC with your own mission prevalence data, where "Automatable" and "Technical impact" separate a 24-hour response from a two-week one; require CVSS-BTE for critical systems and maintain SBOMs to answer "are we affected" in minutes.
• Replace or retain: the NCSC suggests considering whether to remove or replace high-risk systems such as VPN, file transfer and remote access products. A product with repeated exploited flaws and slow fixes is a strategic risk, not a patching problem.

Detection and measurement

Log what answers "were we hit before we patched?": appliance and web server logs exported off-box, server process creation, service account authentication and outbound connections. Retain them long enough to look back past the first exploitation date that advisories report, not just to the disclosure date. Metrics that show the programme works:

• KEV exposure time: median hours from KEV listing to mitigation or remediation on internet-facing assets, against the 24, 48 and 72 hour targets.
• Time to scope: hours from advisory to a complete list of affected instances.
• Open KEV count: KEV entries open past their internal due date, split by internet-facing and internal.
• Compromise assessment rate: percentage of emergency events where a documented compromise check was completed, not just a patch.
• Secrets rotated: percentage of credentials, keys and sessions on the product's rotation list actually rotated after an exploited flaw.

Framework mapping

In MITRE ATT&CK, the relevant techniques are T1190 Exploit Public-Facing Application, T1133 External Remote Services, T1068 Exploitation for Privilege Escalation (mitigations include M1050 Exploit Protection and M1051 Update Software) and T1505.003 Web Shell, the persistence that survives patching.

Common failure patterns

• Patching without hunting: in the Ivanti Connect Secure exploitation, two VPN zero-days exposed credentials, service accounts and sessions. An update does not take those back; integrity checks, rotation and hunting do.
• Prioritising by CVSS alone: a backlog sorted by base score buries exploited medium-severity flaws and the n-days that stay useful for two years.
• Waiting for public exploit code: 72% of 2023 flaws with a public PoC were not known to be exploited, and many exploited ones had none. Exploitation evidence, not PoC availability, is the trigger.
• Underestimating mass exploitation and forgotten instances: once a flaw is public, scanners reach every exposed instance, as with Gravity SMTP CVE-2026-4020, where an open REST endpoint handed email API keys to mass scanners. A test server or an acquired subsidiary's appliance missed during scoping is found by those scanners first.
• Treating developer and AI tooling as low risk: build servers and AI orchestration tools hold high-value secrets; see the TeamCity CVE-2023-42793 exploitation and Langflow CVE-2025-3248 exploitation.
• No authority to switch off: the team that sees the KEV entry cannot take the service offline, so the system stays exposed for a change board meeting.

Practitioner checklist

• Define an emergency tier in policy triggered by KEV, vendor or CERT confirmation of exploitation, with 24, 48 and 72 hour targets.
• Subscribe owning teams to the KEV feed, vendor PSIRT advisories and national CERT alerts, and match them automatically against inventory.
• Enrich scanner output with KEV status and EPSS, and request CVSS-BT or CVSS-BTE for critical systems.
• Pre-approve disabling components, source IP restriction and taking services offline, with a fallback access path.
• Keep SBOMs and an external attack surface inventory so scoping takes hours, not days.
• For each internet-facing product, list the secrets, keys, service accounts and sessions to rotate after an exploited flaw.
• Run a compromise assessment for every exploited flaw on an exposed system, and export appliance logs off-box.
• Publish a vulnerability disclosure policy and security.txt if you ship software or services.
• Rehearse the runbook against a historical KEV entry.

Standards and references

• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
• NCSC: Vulnerability management, Responding to active exploitation of vulnerabilities
• FIRST: The EPSS Model
• FIRST: CVSS v4.0 Specification Document
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• Google Threat Intelligence Group: Look What You Made Us Patch, 2025 Zero-Days in Review
• CISA, NCSC and partners: 2023 Top Routinely Exploited Vulnerabilities

Related NHI Mgmt Group resources: Patch Management Guide · Incident Response Guide · Threat Intelligence Guide · Secrets Management Guide · Service Account Security Guide