Understanding Results

Finding structure

Each finding represents a single vulnerability:

{
  "id": "finding-uuid",
  "severity": "high",
  "title": "SQL Injection in login form",
  "description": "The login endpoint accepts unsanitized input...",
  "vulnType": "sqli",
  "sourceTool": "Web Scanner",
  "proofOfExploit": "POST /login with payload ' OR 1=1 -- ...",
  "remediation": "Use parameterized queries...",
  "verificationStatus": "confirmed",
  "cvss": 8.6,
  "cvssVector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
  "cwe": "CWE-89",
  "owaspCategory": "A05:2025 Injection",
  "reproduction": "curl -s -X POST https://example.com/login --data '...'",
  "continuityStatus": "confirmed"
}

Key fields

• verificationStatus - whether the finding was actively confirmed (Paladin reproduced it) or is unverified (displayed as "Tool-reported" - flagged by a Phase 1 tool but not yet exploit-verified). A third value, not_applicable, is used where verification does not apply
• owaspCategory - the mapped OWASP Top 10 2025 category
• cwe - the associated CWE identifier
• cvss / cvssVector - CVSS v3.1 score and vector string
• proofOfExploit - evidence captured when the finding was verified
• reproduction - read-only, non-destructive steps (e.g. a curl/dig/openssl command or precise browser steps) you can run to re-check the finding yourself
• continuityStatus - how the finding relates to prior pentests: new, confirmed, or retest_confirmed

Severity levels

Each finding includes a CVSS v3.1 vector string (e.g. CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) that breaks down how the score was calculated. Hover over the vector string in the results page to see a tooltip explaining each metric. Admin users can override the AI-assigned severity if needed.

Tool results

Each tool reports its own status independently:

A pentest is complete once all tools have finished and the Phase 2 AI analysis has produced the final findings (regardless of individual tool status).

Prioritizing fixes

1. Start with critical and high findings
2. Group findings by type (e.g., fix all XSS at once)
3. Run a new pentest (uses one credit) - retest validation automatically re-checks previous findings against fresh evidence and records a per-finding verdict