Finding Schema

All findings produced by test skills MUST conform to this schema. Non-conforming findings may be dropped by /verify and /report.

Required Fields

Every finding is stored as a FINDING-NNN.md file in the findings/ directory and must include the following fields:

Field	Type	Description
finding_id	string	Unique identifier in FINDING-NNN format (e.g., FINDING-001)
vuln_type	string	Vulnerability classification (see Vulnerability Types below)
severity	string	Critical, High, Medium, Low, or Info
cvss40_vector	string	CVSS 4.0 vector string (e.g., CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N)
cvss40_score	float	Numeric CVSS 4.0 score (0.0 - 10.0)
cwe	string	CWE identifier (e.g., CWE-89)
endpoint	object	Target endpoint details: url, method, parameter
evidence	object	Proof of vulnerability: request, response_indicator, baseline_comparison
poc_http	object	Full HTTP request+response pair in Burp Suite raw format
impact	string	Business impact in concrete terms
remediation	string	Specific fix with code/config references
confidence	string	confirmed, likely, or possible
chain_potential	array	Plausible attack chains (e.g., ssrf_to_rce, xss_to_ato)
cleanup_status	string	cleaned, cleanup_failed, or not_applicable

JSON Schema

{
  "finding_id": "FINDING-NNN",
  "vuln_type": "sqli_blind_time | sqli_union | xss_reflected | xss_stored | ...",
  "severity": "Critical | High | Medium | Low | Info",
  "cvss40_vector": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
  "cvss40_score": 9.8,
  "cwe": "CWE-89",
  "endpoint": {
    "url": "https://target.com/api/v1/users",
    "method": "POST",
    "parameter": "sort"
  },
  "evidence": {
    "request": "Full HTTP request that triggers the vulnerability",
    "response_indicator": "Exact string/value in response that proves the vulnerability",
    "baseline_comparison": "What the normal (non-vulnerable) response looks like"
  },
  "poc_http": {
    "request": "Complete raw HTTP request — Burp Suite style",
    "response": "Complete raw HTTP response — Burp Suite style"
  },
  "impact": "Attacker can extract all user passwords from the database",
  "remediation": "Use parameterized queries in UserController.php line 42",
  "confidence": "confirmed | likely | possible",
  "chain_potential": ["sqli_to_data_exfil", "xss_to_ato"],
  "cleanup_status": "cleaned | cleanup_failed | not_applicable"
}

Severity Scale

Severity	CVSS 4.0 Score	Examples
Critical	9.0 - 10.0	RCE, SQLi with data exfiltration, authentication bypass to admin, full SSRF to internal services
High	7.0 - 8.9	Stored XSS, IDOR with PII exposure, LFI, JWT algorithm confusion, OAuth redirect bypass
Medium	4.0 - 6.9	Reflected XSS, CSRF on state-changing actions, security misconfiguration, CORS misconfiguration
Low	0.1 - 3.9	Missing security headers, clickjacking (no sensitive actions), verbose error messages
Informational	0.0	No current exploit or impact; security best practice to follow. Risk score = 0

Vulnerability Types

Accepted values for the vuln_type field:

Category	Types
SQL Injection	sqli_blind_time, sqli_union, sqli_error
XSS	xss_reflected, xss_stored, xss_dom
SSRF	ssrf_blind, ssrf_full
Access Control	idor, bola, bfla, mass_assignment
Client-Side	csrf, cors, clickjacking
Auth	jwt_alg_confusion, jwt_weak_key, oauth_redirect, session_fixation, mfa_bypass
Injection	ssti, cmdi, xxe, lfi, rce, crlf, hpp
Infrastructure	cache_poisoning, cache_deception, request_smuggling, open_redirect
Other	type_juggling, tls_weak, deser, prototype_pollution, file_upload, race_condition, business_logic, info_disclosure, other

PoC HTTP Format (Burp Suite Style)

Both poc_http.request and poc_http.response MUST be formatted as raw HTTP, exactly as Burp Suite displays them -- full headers, blank separator line, prettified body. Use fenced code blocks with http language tag in the FINDING-NNN.md file.

Request example:

POST /api/v1/users HTTP/1.1
Host: target.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWRtaW4ifQ.abc
Content-Length: 24

{"id": "1 OR 1=1--"}

Response example:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Request-Id: 8f3a1b2c
Content-Length: 312

{
  "users": [
    {"id": 1, "username": "admin", "email": "admin@target.com", "role": "ADMIN"},
    {"id": 2, "username": "alice", "email": "alice@target.com", "role": "USER"}
  ]
}

PoC Rules

• Include ALL relevant request headers (Authorization, Cookie, Content-Type, Host, etc.)
• Prettify JSON and XML bodies (indent 2 spaces)
• Include the actual response body, not a placeholder. The default pentest standard is the complete response, not a summary or truncated snippet. Only minimally redact secrets or non-essential sensitive data when necessary
• For timing-based SQLi: add a comment with observed delay (e.g., # Response delayed: 5.12s)
• For blind SSRF: show the OOB callback received, not the original response
• For visual/browser-driven findings, collect representative screenshots in the evidence package
• For bug bounty findings, keep the PoC as fast as possible, preferably a single curl, and attach a video of the working PoC

Confidence Levels

Level	Criteria
confirmed	Working poc_http request+response pair demonstrates the vulnerability. Response contains proof.
likely	Behavior is consistent with vulnerability but not definitively proven (e.g., timing-based with some variance).
possible	Suspicious behavior that warrants manual investigation. NOT included in final report without escalation to confirmed.

Only confirmed and likely findings go in the report

Findings with possible confidence are written to logs/unverified/ for manual review. They are never included in the final client report.

FINDING-NNN.md Format

Each finding is stored as a Markdown file in findings/:

# FINDING-001: SQL Injection in User Search

| Field | Value |
|-------|-------|
| **Vulnerability Type** | sqli_blind_time |
| **Severity** | Critical |
| **CVSS 4.0** | 9.8 (`CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N`) |
| **CWE** | CWE-89 |
| **Endpoint** | `POST /api/v1/users?sort=name` |
| **Confidence** | confirmed |
| **Cleanup** | not_applicable |

## Description
The `sort` parameter in the user search endpoint is vulnerable to
time-based blind SQL injection...

## Evidence
[PoC HTTP blocks as shown above]

## Impact
An attacker can extract the entire database contents...

## Remediation
Use parameterized queries...

## References
- CWE-89: SQL Injection
- OWASP Testing Guide: SQL Injection

CHAIN-NNN.md Format

Attack chains are documented in findings/CHAIN-NNN.md after /chain-findings correlates individual findings:

# CHAIN-001: SSRF to Cloud Credential Theft

| Field | Value |
|-------|-------|
| **Chain** | FINDING-003 (SSRF) -> FINDING-007 (Cloud Metadata) |
| **Combined Severity** | Critical |
| **Combined CVSS 4.0** | 9.8 |

## Attack Flow
1. SSRF in PDF generator (FINDING-003) allows internal requests
2. Access AWS metadata endpoint at 169.254.169.254
3. Retrieve IAM role credentials
4. Access S3 buckets with stolen credentials

## Mermaid Diagram
[Mermaid flowchart of the attack chain]

## Combined Impact
Full AWS account compromise via chained SSRF...

Common Chain Patterns

Chain	Components
SSRF to RCE	SSRF + cloud credentials + code execution
XSS to ATO	Stored XSS + session theft + account takeover
SQLi to Exfil	SQL injection + data extraction + PII exposure
CMDi + LFI	Command injection + local file inclusion
LFI + SSRF	Local file read + internal service access
XXE + JAR	XXE + Java archive protocol handler
JWT + BAC	JWT weakness + broken access control
UserEnum + NoRateLimit	Username enumeration + brute force
XSS + CORS	Cross-site scripting + CORS misconfiguration

Rules Summary

1. Every finding MUST have poc_http -- if you cannot produce a complete HTTP request+response pair, it is not a finding
2. evidence.response_indicator must be exact -- copy the specific string/value, not a summary
3. baseline_comparison prevents false positives -- show what normal looks like so the difference is clear
4. chain_potential enables /chain-findings -- list plausible attack chains even if not yet demonstrated
5. Only confirmed and likely findings go in the report -- possible goes to logs/unverified/
6. cleanup_status must be set for all stored/persistent payloads -- no test artifacts left in production
7. For pentests, the same full HTTP evidence must propagate into FINDING-NNN.md, HedgeDoc/Outline notes, and generated .docx reports
8. For bug bounty, prefer the fastest reproducible PoC, usually curl, and do not submit without real evidence, representative screenshots when relevant, and a working-PoC video