Zero-Day Exploits Are Breaking Vulnerability Management

A zero-day exploit does not wait for a monthly scan, a change advisory board meeting, or a convenient maintenance window. By the time a vulnerability receives a CVE identifier, a complete vendor advisory, a reliable scanner signature, and a public proof of concept, the first attacks may already have happened.

That is the operational problem behind one of the most widely repeated vulnerability statistics of 2026. VulnCheck examined 495 vulnerabilities that entered its Known Exploited Vulnerabilities dataset during the first half of the year. Of those vulnerabilities, 23.43% had evidence of exploitation on or before the date their CVE records were published. The median time from CVE publication to confirmed KEV status also fell from 120 days in 2025 to 80 days during the first half of 2026. (VulnCheck)

The headline interpretation is tempting: hackers are exploiting one in four vulnerabilities before disclosure.

That interpretation is wrong.

The 23.43% figure does not use all newly published CVEs as its denominator. It describes the timing of exploitation among vulnerabilities that were already confirmed to have been exploited. VulnCheck separately found that the ratio between newly added KEVs and CVEs published during the same period was approximately 1.4%, although that recent cohort remains incomplete because exploitation evidence can emerge months or years after disclosure. (VulnCheck)

The corrected conclusion is still serious:

Nearly one quarter of the vulnerabilities confirmed as exploited during the first half of 2026 showed evidence of exploitation on or before their CVE publication date.

For security engineers, the difference in wording matters. Exaggerated statistics produce poor risk decisions, but accurate statistics reveal an equally important problem: vulnerability management programs that begin only after CVE publication are starting too late for a meaningful subset of real attacks.

Was ist eine Zero-Day-Sicherheitslücke?

NIST defines a zero-day attack as an attack that exploits a previously unknown hardware, firmware, or software vulnerability. Under this strict definition, the defining characteristic is not simply the absence of a patch. The vulnerability is not yet known to the relevant defenders or maintainers in a way that allows normal remediation to begin. (NIST-Ressourcenzentrum für Computersicherheit)

In industry reporting, however, the term is often used more loosely. A vulnerability may be called a zero-day when it is actively exploited before a patch is available, before a public advisory is released, or before most customers are aware that they are affected. These situations overlap, but they are not identical.

A useful vulnerability timeline looks like this:

Bühne	What has happened	What defenders may know
Unbekannte Schwachstelle	A flaw exists in a deployed product	Nothing
Attacker discovery	An attacker or broker identifies the flaw	Usually nothing
Private exploitation	Selected targets are attacked	Possibly isolated anomalies
Vendor awareness	A researcher, customer or internal team informs the vendor	Limited private information
CVE reservation	A CVE identifier may be reserved	Usually not public
Advisory publication	Technical details and affected versions are disclosed	Public awareness begins
Patch publication	A fixed version or mitigation becomes available	Remediation can begin
Public PoC	Reproduction code becomes public	Exploitation becomes easier to scale
KEV confirmation	Credible sources confirm exploitation in the wild	Prioritization becomes clearer
Mass exploitation	Botnets and criminal groups automate scanning and compromise	Exposure becomes urgent

A true zero-day exploit generally operates in the earlier portion of this timeline. Same-day exploitation occurs when attacks are observed on the CVE publication date. An n-day exploit targets a vulnerability that is already publicly known, usually after a patch or mitigation exists.

There is also a fourth category that is easy to overlook: retrospectively confirmed exploitation. In this case, researchers may determine weeks later that attacks began before the public disclosure date. The date on which a vulnerability enters a KEV database is therefore not necessarily the date attackers first used it.

This distinction helps explain why different research reports produce very different exploitation timelines.

VulnCheck reported a median of 80 days between CVE publication and KEV status in the first half of 2026. Rapid7, using newly disclosed high- and critical-severity vulnerabilities and CISA KEV inclusion as part of a different methodology, reported that the median time to CISA KEV inclusion fell from 8.5 days to five days during 2025. These measurements use different vulnerability sets, intelligence sources and confirmation processes, so they should not be treated as contradictory or directly interchangeable. (VulnCheck)

The important engineering lesson is not whether the correct number is five days, 80 days or zero days. The lesson is that the observable timeline depends heavily on what an organization can see.

What the 23.43% Statistic Actually Tells Us

VulnCheck identified 495 vulnerabilities that became known exploited vulnerabilities during the first half of 2026. Approximately 116 of them showed evidence of exploitation on or before their CVE publication dates.

This is a study of confirmed exploited vulnerabilities. It is not a study claiming that approximately 116 of every 495 newly published CVEs are immediately exploited.

The distinction can be represented as two separate questions:

Question one: Among vulnerabilities that attackers are known to have exploited, how many were attacked before or at disclosure?

The answer in VulnCheck’s first-half 2026 dataset was 23.43%.

Question two: Among all newly published vulnerabilities, how many have already been confirmed as exploited?

The available first-half ratio was approximately 1.4%, but that number is not mature because newer vulnerabilities have had less time to be attacked, detected, investigated and added to a KEV dataset. (VulnCheck)

This creates a form of survivorship and observation bias. Security researchers can only classify exploitation that leaves observable evidence and reaches an intelligence source. Quiet espionage, targeted compromises and attacks against poorly monitored environments may remain invisible. On the other hand, internet-wide scanning against CMS plugins and edge devices is more likely to be detected by honeypots, canaries and shared telemetry.

The 23.43% result should therefore be interpreted as a warning about the timing of observed real-world exploitation, not as a universal probability assigned to every new CVE.

That warning is strong enough on its own.

Vulnerability Disclosure Is No Longer the Beginning of the Attack Cycle

Traditional vulnerability management assumes that defenders receive a meaningful head start. A vendor publishes an advisory, security teams identify affected systems, scanner vendors release checks, administrators test a patch, and attackers gradually develop reliable exploitation.

That sequence still occurs for many vulnerabilities, but it should no longer be treated as the default for high-value internet-facing products.

Attackers may acquire vulnerability information through original research, stolen vendor data, private exploit markets, compromised support channels, patch diffing, security advisory analysis or access to a customer already experiencing attacks. Once a patch is published, researchers can compare vulnerable and fixed code to identify the changed security boundary. For open-source projects, the relevant commit may be visible before downstream packages and hosted installations have been updated.

Automation compresses the remaining steps. Internet scanning services, botnets, cloud infrastructure and reusable exploit frameworks allow attackers to move from a technical clue to widespread probing without manually selecting every target.

Rapid7 reported that confirmed exploitation of newly disclosed CVSS 7–10 vulnerabilities increased from 71 in 2024 to 146 in 2025, a 105% year-over-year increase. Its research also found that the median time from publication to CISA KEV inclusion fell to five days. Rapid7 described the result as a collapse of the predictive window available to defenders. (Schnell7)

VulnCheck’s cohort analysis adds an important qualification. Approximately 200 vulnerabilities reached KEV status within 31 days of publication during the first half of 2026, close to 196 in 2024 and 194 in 2025. Early exploitation volume was therefore relatively steady rather than exploding at the same rate as overall CVE issuance. (VulnCheck)

Both observations can be true.

The number of newly published CVEs is increasing rapidly. The absolute volume of early exploitation remains substantial. Meanwhile, selected high-impact vulnerabilities are being operationalized quickly enough to break vulnerability programs designed around weekly or monthly queues.

The problem is not that every new vulnerability is immediately weaponized. The problem is that defenders cannot reliably identify the dangerous minority by looking at severity alone.

Why Traditional Vulnerability Management Is Failing

CVSS severity is being mistaken for organizational risk

CVSS remains valuable because it describes technical properties of a vulnerability in a standardized form. It helps analysts understand attack conditions, privileges, user interaction and potential impact.

A CVSS Base score, however, does not know whether an affected asset belongs to your organization. It does not know whether that asset is reachable from the internet, whether a compensating control blocks the vulnerable path, whether the application contains sensitive data, or whether attackers are currently exploiting the flaw.

The official CVSS v4.0 guidance explicitly states that the Base score measures severity rather than risk. It recommends supplementing the Base metrics with threat and environmental information that reflects conditions in the user’s environment. (FIRST)

Consider two vulnerabilities:

Schwachstelle	Base severity	Umwelt	Practical priority
Local privilege escalation on an isolated test workstation	9.8	No internet access, no sensitive data, frequently rebuilt	Potentially manageable
Authentication bypass on an exposed VPN gateway	8.1	Internet-facing, privileged access, active exploitation	Immediate incident-level response

A queue sorted only by the numerical score could place the first vulnerability above the second. An attacker would probably make the opposite choice.

Periodic scanning creates blind intervals

A weekly scanner tells the organization what it could identify at the moment the scan ran. It does not continuously answer whether:

• a new cloud instance became publicly reachable after the scan;
• an old staging environment was restored from a vulnerable image;
• a plugin was installed without entering the software inventory;
• a vendor changed the affected-version range;
• exploitation evidence emerged after triage;
• a previously private proof of concept became public;
• a vulnerability was added to KEV;
• an exposed system had already been compromised.

The faster the attack cycle becomes, the more dangerous these intervals become.

Scanning remains necessary, but the result must be continuously correlated with attack-surface changes and live threat intelligence. A vulnerability record is not static. Its risk can change even when the software version remains the same.

The asset inventory is usually less complete than the vulnerability database

Security teams often know more about the CVE than they know about the affected asset.

They may have a detailed CVSS vector, CWE classification, vendor advisory and remediation instructions but still be unable to answer basic environmental questions:

• Where is the product deployed?
• Which instances are internet-facing?
• Which business owner is responsible?
• Does a reverse proxy expose the vulnerable endpoint?
• Is the vulnerable component enabled?
• Is the asset an abandoned test system?
• Does the system store credentials or API keys?
• Can compromise provide access to other environments?
• Are sufficient logs available for historical investigation?

This gap is especially damaging during zero-day exploit response. A three-day remediation target is meaningless if the organization needs five days to discover that the asset exists.

Patching is being confused with incident response

Patching changes the system’s future behavior. It does not prove that the system was safe before the patch.

When exploitation began before the disclosure or patch date, an exposed vulnerable system may have spent days or weeks within an unknown compromise window. Attackers could have installed a webshell, created accounts, extracted credentials, modified authentication settings, stolen tokens or established access through another system.

A successful scanner retest answers:

Does the vulnerable condition still reproduce?

It does not answer:

Did an attacker exploit the system before it was fixed?

For vulnerabilities that provide remote code execution, authentication bypass or total administrative control, patching and forensic triage should often run as parallel workstreams.

A single KEV catalog cannot represent the entire exploitation landscape

CISA’s Known Exploited Vulnerabilities Catalog is one of the strongest public prioritization signals available. Inclusion requires evidence of active exploitation, an assigned CVE and clear remediation guidance. CISA recommends that organizations use the catalog as an input to their vulnerability management prioritization. (CISA)

But no KEV catalog can observe every attack immediately.

During the first half of 2026, VulnCheck reported observing exploitation against 61 known exploited vulnerabilities through its own canaries. Only 12 of those vulnerabilities had been added to CISA KEV at the time of its analysis. VulnCheck also identified 79 different sources that were first to report exploitation evidence, including Patchstack, CrowdSec, Shadowserver, Wordfence, CISA and VulnCheck itself. (VulnCheck)

This does not make CISA KEV unreliable. It demonstrates why mature teams consume multiple intelligence sources.

A reasonable hierarchy is:

1. Confirmed exploitation from a trusted government, vendor or intelligence source.
2. Consistent exploitation observations from honeypots, canaries or network telemetry.
3. Credible public reporting tied to technical evidence.
4. Reliable exploit code or reproducible attack research.
5. High exploitation probability based on EPSS and similar models.
6. Theoretical severity without evidence of practical exploitation.

The lower categories remain useful, but they should not override stronger evidence.

CVSS, EPSS, KEV and Asset Context Answer Different Questions

No single metric can replace vulnerability analysis because the available systems answer different questions.

Signal	Primary question	Stärke	Begrenzung
CVSS	How technically severe could exploitation be?	Standardized technical description	Base score is not organizational risk
EPSS	How likely is a published CVE to be exploited in the next 30 days?	Data-driven probability updated daily	A prediction is not confirmation of compromise
KAG KEV	Has credible exploitation been confirmed?	High-confidence public prioritization	Inclusion may follow initial exploitation
Beratung des Verkäufers	What products and versions are affected?	Best source for product-specific remediation	Vendor visibility and wording vary
Internet exposure	Can an external attacker reach the vulnerable surface?	Directly reflects attack opportunity	Requires accurate asset discovery
Kritikalität der Vermögenswerte	What business or control-plane impact would compromise cause?	Reflects organizational consequences	Often poorly maintained
Ausgleichende Kontrollen	Can the exploit path be blocked or detected?	May reduce immediate exposure	Controls can be misconfigured or bypassed
Validation evidence	Does the issue reproduce on this specific asset?	Highest environment-specific confidence	Must be performed safely and legally

FIRST describes EPSS as a machine-learning model that estimates the probability that a published CVE will be exploited in the wild during the next 30 days. It publishes a probability between zero and one, together with a percentile ranking, and updates the data daily. (FIRST)

EPSS should not be interpreted as a replacement for KEV. If a vulnerability is already confirmed as actively exploited, a prediction about future exploitation is no longer the most important signal. Similarly, a high EPSS score does not prove that your specific system is vulnerable or compromised.

A practical prioritization process combines all four layers:

Technical severity + exploitation likelihood or evidence + environmental exposure + business impact.

The New Risk Model Behind CISA BOD 26-04

In June 2026, CISA issued Binding Operational Directive 26-04, replacing earlier federal directives with a more explicitly risk-based vulnerability remediation model.

The directive focuses on four decision variables:

• whether the asset is publicly exposed;
• whether the vulnerability is in CISA KEV;
• whether exploitation is automatable;
• whether the technical impact provides partial or total control.

The highest-risk combinations can require remediation within three calendar days, and some scenarios require forensic triage in addition to patching. Lower-risk combinations receive longer timelines or may be deferred until the next normal system upgrade. (CISA)

The directive applies directly to relevant US federal civilian agencies, but its decision logic is valuable beyond government.

Most vulnerability programs already possess some of this information. They have CVSS scores, scanner findings and perhaps a KEV feed. What they often lack is a reliable way to combine those signals with live asset exposure.

CISA’s model also highlights an uncomfortable truth: the most important variable may be the one the organization must supply itself.

Threat intelligence can tell you that a vulnerability is exploited. A vendor can tell you which version is affected. An SSVC record may describe automatability and technical impact.

None of those sources can reliably tell you whether an undocumented server in your cloud account is currently exposed through a forgotten load balancer.

A Practical Risk-Based Vulnerability Management Model

Organizations do not need to copy a government directive exactly. They should, however, use the same principle: prioritize vulnerabilities according to the attack opportunity and organizational consequence, not only the theoretical severity.

A practical model can evaluate seven dimensions.

1. Exploitation evidence

Use the strongest available evidence:

• exploitation observed on your own system;
• exploitation observed by a trusted incident-response or intelligence provider;
• inclusion in a reputable KEV catalog;
• multiple consistent honeypot or canary reports;
• a credible public exploit associated with active scanning;
• a functional proof of concept without observed attacks;
• theoretical exploitability only.

Direct evidence should dominate predictive scores.

2. External exposure

Determine whether the vulnerable path is reachable from an untrusted network.

An asset should not be marked “internal” merely because its private IP address belongs to an internal subnet. Public reverse proxies, API gateways, VPN paths, cloud tunnels, partner integrations and misconfigured access-control lists may expose the service indirectly.

Exposure should be assessed at the vulnerable endpoint, not only at the host.

3. Exploit automation

Ask whether attackers can automate the complete path from discovery to impact.

Unauthenticated HTTP vulnerabilities with predictable requests are often highly automatable. A local race condition requiring precise timing and an existing account may be more difficult to scale. A user-interaction vulnerability can still be automated if phishing or malicious document delivery is already industrialized.

Automation matters because it determines how quickly an attack can move from isolated research to internet-wide exploitation.

4. Technical impact

Distinguish limited behavior from total control.

Examples of total-control outcomes include unauthenticated remote code execution, administrative authentication bypass, arbitrary firmware modification and access to an orchestration platform capable of controlling many downstream systems.

Partial impact may still be urgent when the affected data or function is valuable. A vulnerability exposing customer authentication tokens could cause severe harm without providing operating-system control.

5. Asset criticality

Assess the role of the affected system.

A content site, identity provider, VPN gateway, CI/CD controller, secrets manager, endpoint-management server and security analytics platform should not receive the same business-impact rating.

Criticality must include both the data held by the asset and the authority it exercises over other assets.

6. Control radius

Control radius describes how far an attacker can move after compromise.

A web server in a segmented zone may have a relatively narrow control radius. An endpoint management platform may be able to push software to thousands of devices. A CI/CD service may contain source-code access, signing keys, cloud credentials and deployment permissions.

Security tools and administrative platforms therefore deserve special treatment even when their CVSS scores are not the highest in the queue.

7. Compensating controls

A compensating control should reduce priority only when the organization can verify that it blocks the relevant attack path.

Beispiele hierfür sind:

• removal of the affected endpoint from public access;
• a tested WAF rule that blocks the exact request pattern;
• network isolation;
• disabling the vulnerable feature;
• application allowlisting;
• strong authentication that is genuinely required before exploitation;
• an IPS signature validated against the affected protocol;
• service shutdown.

Theoretical controls, unverified policies and incomplete segmentation should not be treated as effective mitigation.

An Example Priority Matrix

The following model is not an official standard. It is a practical starting point for organizations building an emergency vulnerability queue.

Ebene	Typical conditions	Target action
Emergency	Active exploitation or strong evidence; exposed asset; RCE, auth bypass or total control	Contain immediately, triage for compromise, remediate within hours to three days
Kritisch	Reliable exploit available; exposed or high-value asset; automatable path	Remediate within three to seven days
Hoch	High EPSS or credible PoC; limited exposure; substantial impact	Remediate within 14 days
Standard	No exploitation evidence; internal asset; moderate impact	Normal patch cycle
Deferred	Not affected in current configuration, unreachable component or strong verified mitigation	Track and fix during upgrade
Incident	Evidence of exploitation on the organization’s asset	Activate incident response regardless of patch status

The most important row is the final one.

Once there is evidence that your asset has been attacked, the record is no longer merely a vulnerability-management ticket. It is an incident.

A Defensive Prioritization Script

The following Python example demonstrates how an organization could rank vulnerability records using environmental and threat signals. It does not test or exploit systems. It processes an existing CSV inventory and produces a prioritized remediation queue.

Expected CSV columns:

cve,asset,internet_exposed,kev,active_attack,automatable,total_control,
asset_criticality,epss,compensating_control

Example values use wahr oder falsch, an asset criticality score from 1 to 5, and an EPSS probability from 0 to 1.

#!/usr/bin/env python3

from __future__ import annotations

import csv
import sys
from dataclasses import dataclass
from pathlib import Path


@dataclass
class VulnerabilityRecord:
    cve: str
    asset: str
    internet_exposed: bool
    kev: bool
    active_attack: bool
    automatable: bool
    total_control: bool
    asset_criticality: int
    epss: float
    compensating_control: bool

    def priority_score(self) -> float:
        """
        Example organizational scoring model.

        This is intentionally environment-focused rather than a replacement
        for CVSS, EPSS, KEV, SSVC, or analyst judgment.
        """
        score = 0.0

        if self.active_attack:
            score += 50

        if self.kev:
            score += 25

        if self.internet_exposed:
            score += 20

        if self.automatable:
            score += 15

        if self.total_control:
            score += 20

        score += self.asset_criticality * 5
        score += self.epss * 20

        if self.compensating_control:
            score -= 15

        return max(score, 0.0)

    def response_tier(self) -> str:
        score = self.priority_score()

        if self.active_attack:
            return "INCIDENT"

        if (
            self.kev
            and self.internet_exposed
            and self.total_control
        ):
            return "EMERGENCY"

        if score >= 80:
            return "EMERGENCY"

        if score >= 55:
            return "CRITICAL"

        if score >= 30:
            return "HIGH"

        return "STANDARD"


def parse_bool(value: str) -> bool:
    normalized = value.strip().lower()

    if normalized in {"true", "1", "yes", "y"}:
        return True

    if normalized in {"false", "0", "no", "n"}:
        return False

    raise ValueError(f"Invalid Boolean value: {value!r}")


def load_records(path: Path) -> list[VulnerabilityRecord]:
    records: list[VulnerabilityRecord] = []

    with path.open("r", encoding="utf-8", newline="") as file:
        reader = csv.DictReader(file)

        required = {
            "cve",
            "asset",
            "internet_exposed",
            "kev",
            "active_attack",
            "automatable",
            "total_control",
            "asset_criticality",
            "epss",
            "compensating_control",
        }

        missing = required.difference(reader.fieldnames or [])

        if missing:
            raise ValueError(
                f"CSV is missing required columns: {sorted(missing)}"
            )

        for row_number, row in enumerate(reader, start=2):
            try:
                criticality = int(row["asset_criticality"])
                epss = float(row["epss"])

                if criticality not in range(1, 6):
                    raise ValueError(
                        "asset_criticality must be between 1 and 5"
                    )

                if not 0.0 <= epss <= 1.0:
                    raise ValueError("epss must be between 0 and 1")

                records.append(
                    VulnerabilityRecord(
                        cve=row["cve"].strip(),
                        asset=row["asset"].strip(),
                        internet_exposed=parse_bool(
                            row["internet_exposed"]
                        ),
                        kev=parse_bool(row["kev"]),
                        active_attack=parse_bool(row["active_attack"]),
                        automatable=parse_bool(row["automatable"]),
                        total_control=parse_bool(row["total_control"]),
                        asset_criticality=criticality,
                        epss=epss,
                        compensating_control=parse_bool(
                            row["compensating_control"]
                        ),
                    )
                )

            except (TypeError, ValueError) as exc:
                raise ValueError(
                    f"Invalid value on CSV row {row_number}: {exc}"
                ) from exc

    return records


def main() -> int:
    if len(sys.argv) != 2:
        print(
            f"Usage: {Path(sys.argv[0]).name} vulnerabilities.csv",
            file=sys.stderr,
        )
        return 2

    csv_path = Path(sys.argv[1])

    if not csv_path.is_file():
        print(f"File not found: {csv_path}", file=sys.stderr)
        return 2

    try:
        records = load_records(csv_path)
    except (OSError, ValueError) as exc:
        print(f"Error: {exc}", file=sys.stderr)
        return 1

    ranked = sorted(
        records,
        key=lambda record: record.priority_score(),
        reverse=True,
    )

    print(
        "tier,score,cve,asset,internet_exposed,"
        "kev,active_attack,total_control"
    )

    for record in ranked:
        print(
            f"{record.response_tier()},"
            f"{record.priority_score():.1f},"
            f"{record.cve},"
            f"{record.asset},"
            f"{record.internet_exposed},"
            f"{record.kev},"
            f"{record.active_attack},"
            f"{record.total_control}"
        )

    return 0


if __name__ == "__main__":
    raise SystemExit(main())

The exact weights should be adapted to the organization. A hospital, payment processor, SaaS company and industrial operator will assign different consequences to the same technical condition.

The architectural principle is more important than the numbers: threat intelligence and asset context must converge in the same decision.

Why CMS Platforms Dominate Exploitation Data

Content management systems accounted for approximately one-third of the KEVs added to VulnCheck’s dataset during the first half of 2026. WordPress plugins contributed much of the volume, although exploitation also affected other platforms, including Drupal, Ghost and Kentico Xperience. (VulnCheck)

The Australian Signals Directorate’s Australian Cyber Security Centre issued a critical alert on July 9, 2026, describing a large-scale global campaign targeting CMS software and plugins. The observed vulnerabilities included unauthenticated file upload, remote code execution, server-side request forgery and unsafe deserialization. Attackers were scanning websites and deploying webshells that could be used to steal credentials, modify sites, distribute malware or establish a route into broader networks. (Cyber.gov.au)

CMS ecosystems are attractive for several structural reasons.

First, they are directly accessible from the internet. Attackers do not need to compromise a workstation or obtain VPN access before reaching the vulnerable component.

Second, plugin ecosystems create enormous version diversity. A single site may depend on dozens of extensions maintained by different teams with different release practices.

Third, small businesses frequently outsource website operations without maintaining an accurate software inventory. The hosting provider, web agency and business owner may each assume that another party is responsible for patching.

Fourth, successful exploitation often produces an immediate and reusable foothold. A writable web directory or remotely executable plugin path may allow the attacker to install a persistent webshell.

Fifth, abandoned sites remain useful. Even when a compromised website does not contain sensitive business data, attackers can use its reputation and infrastructure for malware distribution, phishing, redirect campaigns, search-engine poisoning or command-and-control activity.

For CMS security, patch management must be combined with file integrity monitoring, plugin governance, least-privilege file permissions and detection of unexpected processes started by the web-server account.

CMS and Webshell Detection

A webshell investigation should begin with evidence preservation. Security teams should avoid deleting suspicious files before recording timestamps, hashes, ownership, access logs and related process activity.

On Linux-based web servers, the following defensive checks can help identify recently modified executable files. Paths must be adapted to the local application.

# Review recently modified server-side files.
find /var/www \
  -type f \
  \( -name "*.php" -o -name "*.jsp" -o -name "*.aspx" -o -name "*.cgi" \) \
  -mtime -7 \
  -printf "%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %p\n" \
  | sort

# Look for executable files in common upload locations.
find /var/www \
  -type f \
  \( -path "*/uploads/*" -o -path "*/cache/*" -o -path "*/tmp/*" \) \
  -perm /111 \
  -ls

# Record hashes before moving or deleting suspicious files.
find /var/www -type f -mtime -7 -print0 \
  | xargs -0 sha256sum \
  > /secure-evidence/recent-webroot-files.sha256

A useful endpoint detection rule should also watch for web-server processes spawning command interpreters or administrative tools.

The following Microsoft Sentinel KQL example is deliberately generic:

DeviceProcessEvents
| where InitiatingProcessFileName in~ (
    "w3wp.exe",
    "httpd.exe",
    "apache2.exe",
    "nginx.exe",
    "php-cgi.exe",
    "php-fpm.exe",
    "tomcat.exe",
    "java.exe"
)
| where FileName in~ (
    "cmd.exe",
    "powershell.exe",
    "pwsh.exe",
    "sh",
    "bash",
    "dash",
    "zsh",
    "curl.exe",
    "wget.exe",
    "certutil.exe",
    "bitsadmin.exe"
)
| project
    Timestamp,
    DeviceName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine,
    AccountName,
    SHA256
| order by Timestamp desc

Not every match is malicious. A Java application may legitimately start shell scripts, and a deployment system may use locken.. The detection is valuable because it identifies behavior that requires context and investigation.

Other useful CMS compromise signals include:

• new administrator accounts;
• modified plugin or theme files;
• unexpected scheduled tasks;
• outbound connections from the web-server process;
• encoded or heavily obfuscated server-side scripts;
• requests to newly created files with unusual names;
• modifications to rewrite rules;
• changed database credentials;
• unusual access to cloud metadata endpoints;
• authentication tokens used from new locations.

These indicators should be correlated with the vulnerability’s suspected exploitation period.

Edge Devices Are a Different Kind of Zero-Day Risk

Network edge devices remain among the most valuable zero-day exploit targets because they sit at the boundary between trusted and untrusted networks.

VPN appliances, routers, firewalls, secure gateways, email appliances and device-management systems often combine four dangerous properties:

1. They are reachable from the internet.
2. They process unauthenticated traffic.
3. They hold privileged configuration or credentials.
4. Traditional endpoint agents cannot be installed on them.

VulnCheck’s 2026 analysis of exploited network edge devices found that 42.5% of the studied vulnerabilities affected devices that were end-of-life or likely end-of-life. For vulnerabilities associated with botnet exploitation, 65% affected devices in those unsupported categories. VulnCheck also reported that only 23.7% of the exploited edge-device vulnerabilities in its dataset appeared in CISA KEV. In 18 cases, VulnCheck assigned CVEs after observing exploitation through honeypots or canary systems. (VulnCheck)

The last finding is especially important.

It demonstrates a sequence in which exploitation evidence exists before defenders have a CVE identifier around which to organize their workflows.

A scanner that operates only on CVE signatures may not identify the issue. An asset owner may not receive a vendor-specific alert. A ticket cannot be automatically generated against an identifier that does not yet exist.

For edge devices, security teams require behavioral and exposure-based monitoring in addition to vulnerability scanning.

Relevant telemetry includes:

• changes to administrative accounts;
• unexpected configuration exports;
• modified authentication providers;
• new VPN profiles;
• unusual management-interface access;
• unrecognized firmware changes;
• outbound connections from the appliance;
• changes to logging destinations;
• disabled security policies;
• unknown certificates or keys;
• successful authentication after repeated exploitation-like requests.

When an affected edge device cannot provide trustworthy forensic data, organizations may need to collect evidence from upstream firewalls, identity providers, VPN logs, network flow data, DNS telemetry and adjacent systems.

Replacing or rebuilding an appliance may be safer than attempting to clean it in place, particularly when exploitation could have provided full administrative or firmware-level control.

Security Tools and Management Platforms Have an Expansive Control Radius

VulnCheck observed that security products, developer tools, device-management platforms and desktop applications appeared to reach exploited status more quickly than several other technology categories during the first half of 2026. The affected categories included products used for security monitoring, endpoint administration and enterprise software management. VulnCheck suggested that broad deployment and privileged enterprise access may help explain their attractiveness. (VulnCheck)

The security industry sometimes underestimates the risk of compromising a defensive platform.

A central security tool may have permission to:

• collect data from every endpoint;
• execute remote response actions;
• distribute software or scripts;
• access cloud and identity APIs;
• quarantine or release files;
• disable security controls;
• read sensitive logs;
• store administrative credentials;
• connect across network segments.

An attacker who compromises that control plane may not need a long lateral-movement campaign. The management platform already contains the paths required to reach the rest of the environment.

This is why asset criticality should include delegated authority. The value of a system is not limited to the information stored in its local database.

AI-Discovered Vulnerabilities Are Not Automatically More Exploitable

AI has become part of both vulnerability discovery and offensive security research. That does not mean every AI-discovered vulnerability will become a zero-day exploit.

VulnCheck combined two datasets containing 1,061 vulnerabilities attributed to AI-assisted discovery. Fourteen, or approximately 1.3%, had been confirmed as exploited in the wild. VulnCheck concluded that the observed rate was broadly similar to the exploitation rate across vulnerabilities in its first-half dataset and did not support the claim that AI-discovered flaws are inherently more likely to be exploited. (VulnCheck)

A separate VulnCheck exploit-intelligence report found that more than 14,000 exploits were associated with over 10,000 CVE-2025 vulnerabilities. The company also warned that growth in AI-generated proof-of-concept code included non-functional or fabricated examples. Despite the availability of public exploit material, only approximately 1% of 2025 CVEs had confirmed in-the-wild exploitation by the end of that year. (VulnCheck)

The operational interpretation should be balanced.

AI can increase vulnerability-discovery volume. It can help researchers understand patches, write harnesses, generate test inputs and translate technical findings into exploit hypotheses. It can also produce convincing but invalid code, misidentify affected conditions or overstate impact.

Security teams should therefore distinguish four artifacts:

Artifact	What it proves
AI-generated explanation	A plausible vulnerability hypothesis
Scanner or template match	A response matched expected characteristics
Reproduced behavior	The suspected condition can be triggered
Confirmed security impact	A real security boundary is violated

Only the final stages justify reporting a confirmed vulnerability.

AI Products Are Becoming an Attack Surface

The role of AI is not limited to discovering vulnerabilities in traditional software. AI infrastructure is becoming a valuable target.

VulnCheck reported known exploitation affecting products used for model development, workload scaling, AI gateways, agent frameworks and workflow automation. Its canaries observed exploitation against 10 of 28 KEVs associated with AI systems. In attacks involving LangFlow vulnerabilities, VulnCheck observed credential harvesting, cryptominer deployment and lateral-movement attempts. (VulnCheck)

AI systems frequently connect to sensitive resources:

• model-provider API keys;
• cloud credentials;
• vector databases;
• internal document repositories;
• source-code systems;
• message queues;
• workflow engines;
• browser automation;
• shell or code-execution tools;
• customer data;
• administrative APIs.

An AI workflow platform may therefore operate as an orchestration control plane. Remote code execution in such a system can expose far more than the local container.

Security teams should inventory AI products in the same way they inventory traditional internet-facing applications. “Experimental” does not mean “low impact” when the experiment has access to production credentials.

The Emergency Zero-Day Exploit Workflow

A mature zero-day response should be designed before the next high-profile disclosure.

The workflow should contain the following stages.

Stage 1: Validate the intelligence

Determine what is actually known.

Record:

• vulnerability or campaign identifier;
• affected products and versions;
• earliest credible exploitation date;
• available patches or mitigations;
• exploitation prerequisites;
• potential impact;
• available detection guidance;
• confidence level;
• sources and timestamps.

Do not treat a social-media screenshot or an unverified proof of concept as equivalent to a vendor advisory or observed exploitation.

At the same time, do not wait for perfect certainty when an exposed high-value system may be at risk. Uncertainty should influence the containment strategy, not create paralysis.

Stage 2: Identify potentially affected assets

Search multiple inventories:

• vulnerability scanners;
• external attack-surface data;
• cloud accounts;
• configuration management databases;
• software bills of materials;
• endpoint software inventories;
• DNS records;
• load balancer configurations;
• reverse proxies;
• container registries;
• package-lock and dependency files;
• procurement and license records;
• previous penetration-test reports.

Version detection should not be the only method. Banners may be hidden or inaccurate. Confirm the application identity through multiple signals.

Stage 3: Determine actual exposure

For each asset, ask:

• Is the vulnerable service reachable?
• Is the affected feature enabled?
• Is authentication required before reaching the vulnerable path?
• Does a gateway or WAF block the request?
• Is access restricted by IP address?
• Can a partner, customer or compromised internal user reach it?
• Does the asset have outbound internet access?
• Can compromise lead to adjacent systems?

The result should be recorded with evidence, not a checkbox based on an old inventory field.

Stage 4: Apply immediate containment

Containment options may include:

• removing public access;
• disabling the vulnerable feature;
• stopping the service;
• applying a vendor-provided mitigation;
• restricting management interfaces;
• adding a tested WAF or IPS rule;
• blocking known attack infrastructure;
• isolating the asset;
• revoking exposed credentials;
• increasing logging;
• deploying temporary detections.

Containment should be reversible where possible and should not destroy evidence.

Stage 5: Preserve evidence

Before rebooting, rebuilding or deleting suspicious files, collect what the incident-response team may need:

• system time and timezone;
• process list;
• network connections;
• memory where feasible;
• authentication logs;
• web access and error logs;
• application logs;
• configuration state;
• file metadata and hashes;
• scheduled tasks;
• user and group changes;
• security-control status;
• cloud audit events;
• relevant network telemetry.

A patch window can become an evidence-destruction event when teams move too quickly without coordination.

Stage 6: Remediate

Apply the vendor’s fixed version or recommended mitigation. Validate that the update applies to the actual deployed edition, branch and configuration.

For clustered systems, verify every node. For containers, ensure the running workload has been recreated from the corrected image. Updating a base image without replacing active containers does not remediate the live service.

For plugins and dependencies, confirm that duplicate or abandoned copies are not still accessible.

Stage 7: Hunt for compromise

The hunt should cover the earliest credible exploitation date, not merely the public disclosure date.

Search for:

• exploit request patterns;
• anomalous child processes;
• new executable files;
• suspicious administrator activity;
• credential access;
• unusual outbound traffic;
• modified startup mechanisms;
• new scheduled tasks;
• log deletion;
• security-tool interference;
• lateral movement;
• data-access anomalies.

If exploitation may have exposed secrets, rotate them after containment. Rotation performed too early can alert an attacker or interfere with evidence collection, so sequencing should be coordinated with incident response.

Stage 8: Verify the fix safely

A scanner rescan is useful but may be insufficient.

Safe verification should confirm:

• the service is running the corrected build;
• the vulnerable path no longer behaves as before;
• mitigations remain effective;
• no alternative exposed instance exists;
• authentication and authorization controls still work;
• the patch did not create an availability problem;
• the same controlled test no longer reproduces;
• the evidence is recorded for audit and engineering review.

Stage 9: Continue monitoring

After remediation, monitor the asset for delayed signs of compromise.

An attacker may have established persistence elsewhere. The patched system could stop producing the original exploit signal while stolen credentials continue to be used against cloud services, source-code repositories or identity systems.

Safe Validation Is Not the Same as Exploitation

When a zero-day exploit or newly weaponized CVE affects a production system, defenders need evidence. They do not need unnecessary damage.

Authorized validation should use the minimum action required to prove or disprove the affected condition.

Good validation asks:

• Is the product present?
• Is the affected version or configuration present?
• Is the vulnerable endpoint reachable?
• Does a harmless probe reproduce the security-relevant behavior?
• Can the result be confirmed without retrieving sensitive data?
• Can the test run in staging instead of production?
• Is explicit approval required before a state-changing action?
• Can the fix be tested with the same controlled input?

Poor validation immediately attempts to obtain a shell, extract real customer data, create persistent accounts or run destructive payloads when a lower-impact proof would have answered the question.

This distinction becomes particularly important when AI is involved. AI-generated output can make a weak signal sound like a confirmed exploit. A mature workflow must treat findings as untrusted until they are independently reproduced and tied to concrete impact.

Penligent’s published AI pentesting workflow, for example, separates signals from verified findings and emphasizes evidence, reproduction steps, remediation guidance and human-in-the-loop control. Its platform also supports independent validation paths and post-remediation retesting for authorized assessments. (Sträflich)

The value of an AI security system is not that it can produce the most aggressive payload. The value is that it can preserve context across asset discovery, hypothesis generation, controlled verification, evidence capture and remediation retesting.

A Minimum Evidence Standard for Vulnerability Validation

Every confirmed finding should answer the following questions.

Evidence field	Required detail
Affected asset	Host, URL, API, application, tenant or device
Product identity	Product, edition, version and relevant component
Exposure	How the vulnerable path is reached
Voraussetzungen	Authentication, role, network position and configuration
Test action	Exact controlled request or sequence
Observed behavior	Raw response, process event, log entry or state difference
Security impact	The boundary that was violated
Safety limits	Actions deliberately excluded from testing
Sanierung	Fixed version, configuration change or mitigation
Retest result	Evidence that the condition no longer reproduces
Compromise assessment	Whether historical exploitation was investigated

This standard prevents three common errors:

1. Reporting a version fingerprint as proof of exploitability.
2. Reporting a scanner match without confirming environmental conditions.
3. Closing a ticket after patching without evaluating historical compromise.

Detection Engineering for Rapidly Exploited Vulnerabilities

It is unrealistic to expect a perfect detection signature for every zero-day exploit. Detection engineering must therefore combine vulnerability-specific indicators with behavior that remains suspicious across many vulnerabilities.

Vulnerability-specific detections

These may include:

• known request paths;
• malformed protocol fields;
• suspicious parameter combinations;
• exploit-specific user agents;
• known attacker infrastructure;
• malicious filenames;
• webshell hashes;
• affected-process crash patterns;
• vendor-provided indicators.

These detections are precise but may be easy for attackers to change.

Behavioral detections

These focus on what happens after exploitation:

• internet-facing service spawning a shell;
• web application writing an executable file;
• appliance creating an unexpected administrator;
• service account accessing a credential store;
• application container contacting a mining pool;
• management server pushing an unapproved package;
• security platform disabling its own monitoring;
• unusual archive creation before outbound transfer;
• unexpected access to cloud metadata;
• lateral authentication from a server that normally does not initiate sessions.

Behavioral detections often remain useful even when the initial exploit request changes.

Environmental anomaly detection

These detections ask whether the asset is behaving differently from its established role:

• a CMS server initiates SMB connections;
• a VPN appliance makes DNS requests to a new dynamic domain;
• a CI runner accesses production secrets outside deployment hours;
• a monitoring platform creates interactive user sessions;
• an AI workflow container starts a cryptocurrency miner;
• a web application queries an internal identity controller.

The goal is not to guess the exact zero-day exploit. It is to identify the control-boundary changes that exploitation produces.

Vulnerability Management Metrics That Reflect Real Risk

Many executive dashboards reward activity rather than risk reduction.

Examples of weak metrics include:

• total vulnerabilities closed;
• average CVSS score;
• number of scans completed;
• percentage of assets scanned;
• raw critical-finding count.

These numbers may improve while exposed exploited systems remain unresolved.

Better metrics include:

Mean time to identify affected assets

Measure the time between a high-priority advisory and identification of the organization’s potentially affected assets.

This evaluates asset visibility.

Mean time to contain external exposure

Measure the time required to block or isolate the vulnerable path, even before the permanent patch is available.

This evaluates emergency control.

Mean time to remediate known exploited vulnerabilities

Track confirmed exploited vulnerabilities separately from the general backlog.

Percentage of exposed KEV instances within SLA

Count vulnerability instances, not only unique CVEs. One CVE on 500 exposed systems represents a different operational problem from one CVE on a single isolated host.

Percentage of high-impact cases receiving compromise assessment

This metric prevents teams from closing remote-code-execution and authentication-bypass tickets without forensic review.

Percentage of assets with validated ownership

An emergency workflow cannot succeed when ownership is unknown.

Retest success rate

Measure how often remediation is confirmed through controlled reproduction rather than assumed from package-management data.

Time from intelligence change to reprioritization

When a vulnerability enters KEV, receives a functional exploit or becomes associated with active scanning, the queue should update automatically.

A weekly manual review is too slow for a rapidly changing threat.

Common Mistakes During Zero-Day Exploit Response

Waiting for the scanner plugin

Scanner vendors need time to produce and validate checks. During that interval, security teams can still identify products, versions, exposed endpoints and suspicious behavior.

A missing plugin should reduce certainty, not stop investigation.

Treating public PoC availability as the beginning of risk

Public proof-of-concept code can increase exploitation volume, but private exploitation may already be occurring. Vendor disclosures and exploitation telemetry should be evaluated independently of GitHub availability.

Blocking one IP address and declaring containment complete

Attack infrastructure changes rapidly. IP blocking can reduce immediate noise but rarely removes the vulnerable attack path.

Patching only the externally visible node

Clusters, standby systems, disaster-recovery environments and restored snapshots may retain the vulnerability.

Ignoring credentials stored on the affected system

A patched server may remain a source of compromised API keys, database passwords, session tokens or signing credentials.

Rebuilding before collecting evidence

Rebuilding may be the correct remediation, particularly for appliances that cannot be trusted after compromise. Evidence should still be collected first when operationally feasible.

Using production data as proof

Security validation rarely requires extracting actual customer records. Controlled test accounts and synthetic data should be used wherever possible.

Allowing AI to convert uncertainty into confidence

An LLM can produce a coherent exploit narrative from incomplete evidence. Verification gates must be stronger, not weaker, when AI is used.

Does Every Known Exploited Vulnerability Require Emergency Patching?

No.

Known exploitation is one of the strongest prioritization signals, but the required action still depends on whether the organization is affected and exposed.

A KEV may apply to:

• a product you do not use;
• a feature that is disabled;
• a version that has already been fixed;
• an internal lab system;
• an isolated appliance scheduled for retirement;
• a publicly exposed production control plane.

Those scenarios should not receive identical operational treatment.

However, “not emergency patching” does not mean “ignore.” The organization should record why the vulnerability is not immediately actionable and what evidence supports the decision.

A defensible exception might state:

The affected component is installed, but the vulnerable service is disabled, the relevant port is blocked at the host and network layers, and a controlled validation confirms that the endpoint is unreachable. The system will receive the fixed version during the next approved maintenance window.

An indefensible exception might state:

The asset is probably internal and nobody has reported a problem.

Risk-based vulnerability management requires evidence in both directions.

Can a Vulnerability Be Dangerous Without a CVE?

Yes.

A CVE is an identifier and coordination mechanism. It is not what makes a vulnerability technically real.

Attackers can exploit a flaw before a CVE is assigned. A vendor may address a security issue without initially publishing a CVE. A misconfiguration, exposed administrative interface, default credential or business-logic weakness may produce serious risk without fitting neatly into the CVE system.

VulnCheck’s edge-device research documented vulnerabilities for which exploitation was observed before CVE assignment. (VulnCheck)

This is one reason vulnerability management should not be reduced to CVE management.

Organizations must also track:

• insecure configurations;
• exposed services;
• identity weaknesses;
• unsupported products;
• leaked credentials;
• authorization failures;
• cloud-policy errors;
• supply-chain compromises;
• malicious packages;
• unpatched non-CVE defects;
• business-logic vulnerabilities.

A perfectly maintained CVE dashboard can coexist with a highly exposed attack surface.

Is the Zero-Day Problem Mainly an AI Problem?

Not yet.

Current evidence suggests that AI is an accelerant rather than the sole cause.

The vulnerability ecosystem was already challenged by incomplete asset inventories, slow patching, unsupported appliances, internet-wide scanning, criminal specialization and the growing number of connected software components.

AI can accelerate parts of the workflow:

• code review;
• patch analysis;
• fuzzing preparation;
• exploit hypothesis generation;
• payload adaptation;
• scanner-template creation;
• reconnaissance summarization;
• translation of public research;
• phishing and social engineering;
• attack-chain planning.

But the VulnCheck data does not show that AI-discovered vulnerabilities are inherently more likely to be exploited. (VulnCheck)

The near-term risk is more operational:

AI can increase the number of security signals faster than organizations increase their ability to validate and remediate them.

That makes evidence-based prioritization essential.

What Security Leaders Should Change Now

Security leaders do not need to assume that every vulnerability is a zero-day exploit. They need a program that can recognize and respond when a vulnerability behaves like one.

The most important changes are straightforward.

Replace the single CVSS-sorted queue with a dynamic model that incorporates exploitation evidence, exposure, automation, impact and asset criticality.

Maintain a continuously updated inventory of externally reachable assets.

Create an emergency workflow that can operate without waiting for a scanner signature.

Treat exposed RCE and authentication-bypass vulnerabilities with pre-disclosure exploitation as possible incidents.

Consume multiple exploitation-intelligence sources rather than depending on one catalog.

Preserve evidence before rebuilding or patching high-risk systems.

Use EPSS as a predictive input, not as proof of exploitation.

Require controlled verification and post-remediation retesting.

Measure time to exposure containment and compromise assessment, not only ticket closure.

Apply the same controls to AI gateways, agent frameworks and workflow platforms that would be applied to other privileged infrastructure.

Frequently Asked Questions

What is a zero-day exploit?

A zero-day exploit uses a vulnerability that was previously unknown to the relevant defenders or software maintainer. In common industry usage, the term is also sometimes applied to vulnerabilities exploited before a patch or public advisory is available. NIST’s stricter definition focuses on exploitation of a previously unknown vulnerability. (NIST-Ressourcenzentrum für Computersicherheit)

Are one in four vulnerabilities exploited before disclosure?

No. The widely repeated 23.43% statistic refers to 495 vulnerabilities that VulnCheck had already confirmed as exploited during the first half of 2026. Among that exploited set, 23.43% showed evidence of exploitation on or before CVE publication. It does not mean that one quarter of all newly published CVEs were exploited before disclosure. (VulnCheck)

How quickly are vulnerabilities exploited after disclosure?

There is no universal timeline. VulnCheck reported that approximately 200 vulnerabilities reached KEV status within 31 days of publication during the first half of 2026. Rapid7 reported a five-day median from publication to CISA KEV inclusion for a selected group of newly disclosed high- and critical-severity vulnerabilities during 2025. The methodologies differ, but both show that selected vulnerabilities move faster than traditional patch cycles. (VulnCheck)

Is CVSS enough for vulnerability prioritization?

No. FIRST’s CVSS v4.0 guidance states that the Base score measures severity rather than organizational risk. Threat information and environmental context must be added to understand real priority. (FIRST)

What is the difference between EPSS and KEV?

EPSS predicts the probability that a published CVE will be exploited in the wild during the next 30 days. KEV indicates that credible exploitation has already been confirmed. EPSS is predictive; KEV is evidence-based. (FIRST)

Should every KEV be patched immediately?

Every KEV should be evaluated immediately. Remediation urgency depends on whether the organization uses the affected product, whether the vulnerable component is enabled, whether the asset is exposed, the impact of exploitation and whether compensating controls are effective.

Why is internet exposure so important?

Internet exposure gives external attackers direct access to the vulnerable surface. It also enables automated scanning and mass exploitation. An exposed authentication bypass or RCE usually deserves a faster response than a similar vulnerability on an isolated system.

Why is patching not always enough?

If exploitation began before the patch was applied, an attacker may already have established persistence, stolen credentials or moved to another system. Patching prevents the original vulnerability from being used again but does not remove every consequence of an earlier compromise.

When should vulnerability response become incident response?

The transition should occur when there is evidence that the organization’s asset was targeted or compromised, or when a high-impact exposed system spent meaningful time inside a confirmed exploitation window and compromise cannot be reasonably excluded.

Can penetration testing help with zero-day response?

Authorized penetration testing can help determine whether the affected product and vulnerable path are present, whether a mitigation is effective and whether remediation successfully removed the condition. Testing should use the least harmful proof necessary and avoid extracting real data or performing destructive actions without explicit approval.

Letzte Erkenntnis

Zero-day exploits are not breaking vulnerability management because every vulnerability is instantly weaponized. They are breaking it because conventional programs are optimized for orderly information that arrives in the expected sequence.

Real attacks are not orderly.

Exploitation may precede CVE publication. A CVE may exist before a complete advisory. A patch may be released before scanner coverage. A proof of concept may be public before an organization discovers its exposed asset. A KEV entry may appear after the first compromise. A successful patch may close the vulnerability while leaving the attacker’s persistence untouched.

The correct response is not to patch every CVE as an emergency. That approach is impossible and would waste the resources needed for the vulnerabilities that genuinely matter.

The correct response is to build a system that can continuously answer four questions:

Is the asset exposed? Is the vulnerability being exploited? Can the attack be automated? What happens if it succeeds?

CVSS helps describe technical severity. EPSS helps estimate future exploitation probability. KEV provides confirmation of known attacks. Asset intelligence explains whether the threat applies to the organization. Controlled security validation provides evidence. Incident response determines whether exploitation has already happened.

When these functions operate as one workflow, vulnerability management becomes a real security control rather than a queue of numbers.