CVE Flood Triage: Prove Which New Advisories Are Reachable

TL;DR

AI-assisted discovery pushed one vendor's monthly advisory count from a pre-June average near 100 to 1,415, and year-over-year CVE volume is up 105% while additions to CISA's Known Exploited Vulnerabilities catalog grew 37%. Volume is not exposure: of September's 975 Microsoft advisories, three saw in-the-wild exploitation, per Cisco Talos. The job is not to read every advisory — it is to prove which advisories touch a component that is present, reachable, and exploitable on the asset in front of you. That proof comes down to three artifacts: a fingerprint that identifies the component and version, a request that reaches the vulnerable code path, and a callback or differential showing the code ran. Everything else gets dropped with a written reason, not silently ignored.

What this is

CVE flood triage is the discipline of converting advisory volume into per-environment exposure claims that carry evidence. The unit of work is not the CVE ID. It is the tuple: component, deployed version, asset, reachable code path.

For each advisory you ask two questions, in order:

• Is this component on my attack surface, at a version inside the affected range?
• Can a request I am allowed to send reach the code path the advisory describes?

A "yes" to the first and "unknown" to the second is a fingerprint finding, not a vulnerability finding. Most triage queues collapse because they mix the two.

Why it matters

Two failure modes show up in every high-volume month, and they cost more than the CVEs do.

Queue collapse. When advisory counts jump tenfold, everything gets labeled critical because nobody has time to differentiate. Analysts start ranking by CVSS text and vendor severity instead of by what is on the estate, and the queue stops predicting anything. The patches that matter get lost among the ones that do not.

Blanket dismissal. The opposite error is louder right now: "AI slop, none of it is exploited." The exploitation rate really is low, but Talos notes the volume is concentrated in entrenched, long-lived libraries and tools — exactly the components attackers know well and can chain without variability. The log4j lesson was not that a library was dangerous. It was that the library was everywhere and uncataloged, so defenders spent the first days of the incident finding out whether they even used it.

If you own AppSec or pentest scope, the flood changes your workload, not your objective. You still have to hand someone a finding with proof attached.

How it works

Frontier vulnerability-detection models changed the discovery rate, not the exploitation rate. Talos reports that Microsoft's monthly advisory count moved from a pre-June average of roughly 100 to 975 in September and 1,415 this month, that CVE volume grew 105% year over year against 37% growth in KEV additions, and that only three of September's 975 Microsoft advisories saw in-the-wild exploitation (Cisco Talos). The bugs are being mined out of decades of technical debt in ubiquitous libraries and old tools — code that was never cataloged in the first place.

The practical consequence: a high-volume month produces many advisories concentrated in a small number of components you already run. Triage is a join between an advisory feed and a component inventory, not a reading exercise.

Affected-version ranges come from the vendor advisory or the NVD record, never from a scanner banner. A version string in a response header is a claim until you confirm it against the range published for that CVE, and the range is only meaningful once you can demonstrate the version on the asset. Record how you learned the version — that detail is what lets a second researcher check your work.

Evidence escalates in three tiers:

Tier	What you send	What it proves
Fingerprint	Requests for version-bearing surfaces: response headers, error pages, /package.json, source maps, static asset paths, favicon hashes	The component and its version are present on this asset
Reachability	A request carrying a benign out-of-band canary into the parameter that feeds the vulnerable sink	Attacker-controlled input reaches the vulnerable code path
Exploitability	A reproduction against the in-range version, or a patched-versus-unpatched differential	The flaw is exploitable here, not merely installed here

Illustrative example: an advisory lands against a logging library bundled inside a checkout service. The header fingerprint gets you a framework version, not the library. A canary domain in a user-controlled header on the login form produces a DNS lookup from the application host to your collaborator — timestamped, sourced from the target's egress IP. That lookup is the finding. Without it, you have a dependency guess.

When you cannot get a callback, the differential is your fallback. Send the same malformed request to a patched build and to the deployed build. A 500 versus a 400, a changed error string, a new validation message — the behavioral boundary between versions is evidence, provided you capture both sides of it.

Detection and response

The telemetry that matters here is egress, not ingress. Version probing is cheap and noisy; an application server resolving or connecting to an attacker-controlled host is neither.

A defender should be checking:

• DNS egress from application hosts to resolvers outside the corporate set, especially queries for recently registered or low-reputation domains. For lookup-injection, deserialization, and XXE classes this is the highest-fidelity signal available, and it fires whether or not the payload succeeds.
• Outbound LDAP, RMI, and non-standard ports from application tiers. An app server opening 389, 636, or 1099 to the internet is almost never business traffic.
• Interpreter syntax in requests. ${jndi:, #{, __proto__, and template expressions appearing in headers, parameters, and User-Agent strings are payload signatures, not user behavior.
• Version-surface requests in access logs. /actuator/info, /package.json, /META-INF/, /.git/config, and source-map requests clustered from one source indicate a researcher or a scanner mapping your build — and both warrant a look at what the response returned.
• Process anomalies under the application service account — shells, curl, nslookup, certutil — which indicate a reachability test that succeeded further than intended.
• Patch-lag inventory. For each component you track, the deployed version, the date you learned it, and the date the advisory published. That table is what turns a monthly flood into a work queue.

On the offensive side, the artifacts to keep are the raw request, the raw response or callback log with timestamp and source IP, the target hostname, and the account or role used. A finding that cannot be retested from those four items is a note, not a finding.

What to do

1. Build the component inventory before the next patch cycle. For each internet-facing asset, record the component, the version, and the fingerprint method that produced it. Anything you cannot version is an unknown, and unknowns outrank low-severity knowns.
2. Join the month's advisories onto that inventory. Produce a short list of (component, version-in-range, asset) tuples. Everything that fails the join gets dropped in writing: "component not present," "version outside range," "not internet-reachable."
3. Rank by reachability evidence, not by CVSS. A medium-severity flaw on a path you can reach in one request outranks a critical flaw behind three layers of authentication you cannot pass.
4. Test reachability with an out-of-band canary inside an authorized window and scope. Use a benign payload that triggers a lookup and returns nothing — you want the interaction, not the exploit.
5. Capture the differential when the callback fails. Send the same request to a patched build and to the deployed build, and keep both responses. The behavioral boundary is your proof of version exposure.
6. Attach the evidence to the finding in a form a second researcher can replay: request, response or callback, timestamp, target, account. Link the vendor advisory or NVD record that defines the affected range.
7. Retest after the patch with the same request. A closed finding without a retest artifact is a claim about a change, not a verification of one.

FAQ

Do I need to test all 1,415 advisories? No. You need to test the subset that joins to a component present on your surface at an in-range version. In practice that is a small fraction of the month's total, and the join itself is the deliverable that lets you defend dropping the rest.

A CVE exists in a library my app uses. Am I exploitable? Not necessarily. Presence is the first tier. Exploitability requires that input you control reaches the vulnerable code path, which is why the canary or the differential matters more than the advisory text.

How do I test a vulnerability I cannot reach from the outside? Two options: find a path that does reach it, or document the exposure without claiming exploitation. An internal component with a proven version and an unpatched advisory is a real finding for the patch queue; it is not a demonstrated compromise, and the write-up should say so.

Is the KEV catalog enough to prioritize by? It is necessary, not sufficient. KEV tells you what is being exploited somewhere. It does not tell you whether the component is on your estate, whether the path is reachable, or whether your version is in range. That gap is where most real findings live.

Why is disclosure volume breaking the 90-day model? Because the reasoning has shifted: if one model can find a weakness, another can find it too, so some researchers treat the vulnerability as effectively public on discovery. Whether or not you agree, the practical effect for defenders is shorter warning windows and a stronger argument for continuous inventory over annual review.

Sources

• Cisco Talos, "There's only so much code: the rise in vulnerability numbers" — https://blog.talosintelligence.com/theres-only-so-much-code-the-rise-in-vulnerability-numbers/
• NIST National Vulnerability Database — https://nvd.nist.gov/
• CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• FIRST EPSS (Exploit Prediction Scoring System) — https://www.first.org/epss/
• OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/
• Validation and exploitability context for continuous exposure work — https://trusteed.io