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:

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:

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)

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: