Skip to content
Pilot Docs

Investigating a finding

A Nuclei finding appears in the Vulnerabilities list. This page walks through the motion of triaging it.

1. Read the row

The Vulnerabilities table row shows:

  • Severity pill — critical / high / medium / low / info.
  • Template name — what Nuclei detected (e.g. apache-airflow-default-credentials, wordpress-xmlrpc-pingback).
  • Host — the target the template fired against.
  • Matched at — the exact URL or parameter (sometimes truncated).
  • CVE id (when applicable) — link out to the CVE database.
  • CVSS — vulnerability score when the template publishes one.

Click the row to open the detail panel.

2. Confirm the match is real

Nuclei templates vary in confidence. Some assert the CVE conditions directly (proof-of-exploit); some only fingerprint a vulnerable version. Read the template’s info.classification and info.tags fields, both shown in the detail panel.

For a “version fingerprint” template:

  • The CVE is plausible, not proven. Treat it as a lead.
  • Re-test manually with curl or a one-off Nuclei run against the template id.

For a “match found” template (Nuclei actually demonstrated the condition):

  • The CVE is confirmed exploitable from outside.
  • Move to remediation.

3. Check the blast radius

Click the host in the finding to open the Target detail. You now see:

  • Resolved IPs — is this host in your infrastructure or a third-party CDN?
  • Technologies — what else runs here? (A patched CVE on the underlying CMS may have a fix.)
  • Subdomains of the same root — does the vulnerability pattern apply to siblings?

For a wider check, jump to the Attack Graph with the host as the entry-point. Walk 2–3 hops out to see what this host connects to (IdPs, cloud assets, leaked secrets nearby).

4. Ask Pilot for context

Open the agent (emerald pill bottom-left) and ask:

“Tell me everything you know about acme.com host:api.acme.com, and what other findings are open on related infrastructure.”

Pilot will call get_company_profile for context, graph_neighborhood for the host, and list_findings for related rows. You get a one-shot synthesis with citations to every step.

5. Hand off

For your ticketing system:

  • Title — [CRITICAL] {{template_name}} on {{host}} works as a default.
  • Body — the finding’s info.description field + the matched-at URL + a link to the Pilot detail page.
  • Acceptance criteria — re-run the same Nuclei template against the host and confirm no match. Pilot’s next scheduled scan will validate naturally.

6. Re-scan to verify the fix

From the Vulnerabilities → Active tab, launch a new scan against just the host you fixed. When it completes, the original finding’s row either disappears (the template no longer matches) or stays (the fix didn’t land). No manual re-triage required — Pilot owns the verification loop.

Common gotchas

  • The CVE is real but already mitigated by a WAF. Click into the finding’s detail; if the matched-at URL returns the WAF block page on manual curl, the exploit is intercepted. Mark the finding as “won’t fix” and document the WAF rule.
  • The template fingerprint is the only signal. Re-test manually before escalating. Nuclei version checks have false-positive rates

    10% for some popular CMS templates.

  • The host belongs to a third party. Check the resolved IP’s AS-name. If it’s cloudflare, fastly, akamai, etc., the host is the CDN’s edge and you can’t patch it. Contact the SaaS provider instead, or mark as out-of-scope.