CVE Validation

Domain

Validate candidate CVEs against the current target evidence without assuming exploitability. The module consumes cve_candidate_list, product/version evidence, service fingerprints, and scope data, then decides whether the CVE path is usable, patched, not applicable, or needs more recon.

Trigger

cve_candidate_list_ready

Feedback Gates

• Scope Gate: target and asset must be in the declared authorization boundary.
• Evidence Gate: candidate CVE must map to observed product, version, endpoint, service, or fingerprint evidence.
• Applicability Gate: version range, configuration, and reachable component must plausibly match.
• Patch Gate: observed version or vendor advisory must not prove the issue fixed.
• Execution Gate: active validation requires a registered scoped adapter; missing adapters block rather than pretending execution happened.

Boundaries

• Do not run destructive or broad exploit attempts.
• Do not validate outside the declared target and scope.
• Do not treat CVE names alone as proof.
• Prefer passive or low-noise confirmation first.
• If evidence is insufficient, return to recon or CVE lookup rather than guessing.

Pivot Hints

• Candidate has no product/version match -> return to recon-intake for better fingerprinting.
• Candidate is patched or not applicable -> route by highest-ranked attack surface from recon.
• Tool or adapter missing -> record missing capability and request/choose an equivalent adapter.
• Too many candidates -> rank by reachable component, confidence, impact, and version fit.

Exit Conditions

• Confirmed applicable candidate -> continue to the specific validation/testing skill.
• All candidates patched/not applicable -> exit to evidence-based router.
• Evidence incomplete -> return to recon-intake or cve-lookup.
• Required tool/scope/adapter missing -> block with the missing capability or scope evidence.

Exit Evidence