From Detection to Validation: Fixing Broken Vulnerability Workflows

What it REALLY means to test for exploitability
Your engineering team will thank you.

Executive Summary

A modern vulnerability management program should only surface issues an attacker could actually exploit in your environment. By safely validating exploitability and returning evidence for each finding, you cut false positives, reduce ticket noise, and let engineers focus on the fixes that matter most.

Intro

Here’s the awkward truth: traditional scanners largely rely on version checking, which may feel sufficient, but it lies by omission. It can’t tell you whether compensating controls, backports, or configuration make the vuln non‑exploitable in your environment. Meanwhile, adversaries exploit only a small fraction of published CVEs; roughly ~6% ever show evidence of exploitation in the wild. So drowning teams in “maybe” findings is counter‑productive.

Exploitability matters. Versions lie.

Enter Nuclei.

Nuclei is our open‑source, template‑driven scanner that runs evidence‑based checks at runtime. Unlike traditional scanners like Nessus, Nuclei automates the manual work of validating exploitability while scanning. Here is how that works: Each YAML template encodes a test as metadata (id, severity, refs) plus one or more protocol‑specific requests (HTTP, DNS, TCP, etc.) to execute against your target. Findings are confirmed with matchers (conditions that must hold true on the response) and optional extractors that pull dynamic values (like CSRF tokens or headers) for reuse and to capture concrete proof. With the v3 flow engine, templates can chain and conditionally orchestrate multi‑step logic (e.g., authenticate → trigger bug), so you’re validating real exploit paths rather than brittle version banners. The result: Nuclei reports evidence‑backed hits, not guesses.

What good looks like - The CrushFTP Example

Two 2025 CrushFTP cases are perfect to illustrate signal vs. noise:

• CVE‑2025‑31161 (March/April 2025): an auth‑bypass stemming from an AWS4‑HMAC (S3‑style) auth race/logic flaw; widely exploited. NVD+1
• CVE‑2025‑54309 (July 2025): an AS2 validation flaw that enables admin access only when the DMZ proxy is not in use; actively exploited zero‑day; added to CISA KEV.

Our template philosophy: prove it, don’t assume it

For CVE‑2025‑54309, our Nuclei template does three things you can’t get from a banner grab:

1. Reachability & preconditions. It talks to the real HTTP(S) interface the way an attacker would.
2. Execute the specific logic flaw safely. It triggers the bypass in a non‑destructive way.

3. Return evidence. It requests a benign, read‑only resource that the server will only return if the bypass worked (e.g., a user list indicator), giving the analyst hard proof in the response.

Why this matters: The template’s positive result proves the vulnerability is exploitable here and now… not just that you’re below a certain version.

Note on conditions: Both 31161 and 54309 have nuance around network architecture; e.g., CrushFTP’s DMZ proxy changes exposure. Any serious check should confirm those preconditions rather than assume them.

What noise looks like - The “Version Checking” Approach

There are times when vendors ship a version‑only detection; especially on day‑zero disclosures or when safe remote checks aren’t feasible. Example: for CVE‑2025‑54309, Tenable’s public plugin 242340 explicitly states it relies on the application’s self‑reported version instead of testing the flaw. It also flags “Exploit available,” but that label refers to the existence of an exploit generally, not execution in your environment. Tenable

Important distinction: “Exploit available” ≠ “Your instance is exploitable.” Many orgs run DMZ‑fronted CrushFTP; version‑only checks will still alarm on those, even though 54309 doesn’t apply when the DMZ proxy is used. That’s pure ticket noise.

The CrushFTP walkthrough shows the difference: validation turns a suspected issue into a confirmed, actionable fix, while version checks yield a banner match and a “maybe.” At scale, “maybe” becomes the familiar mess; PDFs with thousands of “critical” findings, a swelling backlog, confused triage, and engineer fatigue. Evidence‑backed checks keep the list short and trustworthy, setting up why this matters for risk, cost, and time to fix.

Why this matters (to your backlog and burn‑down)

• False positives waste engineering cycles. Version‑only rules flag hardened, patched, or DMZ‑protected systems. Your team spends time trying to prove a negative.
• Ticket queues balloon. Every “maybe exploitable” becomes a ticket, a review, a change request, a CAB slot… rinse and repeat.
• Context is king. A CVSS 9.8 without exposure is less urgent than a CVSS 7 with a working exploit on your edge. (CISA KEV and EPSS are good outside‑in signals; your exploit‑proof checks are the inside‑out truth.)

By going beyond version checks, you’ll reduce noise, speed up critical fixes, and keep engineering smiling.

ProjectDiscovery saves time and work

Our approach emphasizes proof of exploitability:

• Evidence or it didn’t happen. Findings include a minimal, read‑only artifact that demonstrates the path is real (e.g., a deterministic response reachable only via the flaw)
• Fewer false positives. Preconditions (reachability, DMZ/arch checks, header/behavior gates) prevent non‑issues from reaching your queue.
• Analysts can trust the alert. When a ticket carries proof, triage is minutes, not days.
• Compatibility with risk models. We still enrich with external signals (EPSS, KEV) but don’t substitute them for evidence.

Stop guessing based on banners. Start proving exploitability.
See ProjectDiscovery in action: https://projectdiscovery.io/request-demo