Skip to main content
The vulnerability reporting tool creates comprehensive, professional security reports with automatic CVSS scoring and LLM-based deduplication to prevent duplicate submissions.

Key Features

  • Automatic Deduplication: LLM-based detection of duplicate vulnerabilities
  • CVSS Scoring: Automatic calculation of CVSS 3.1 scores
  • Professional Format: Customer-ready, PDF-suitable reports
  • White-box Support: Code-level vulnerability documentation with diffs
  • CWE/OWASP Integration: Automatic classification support

When to Use

Use this tool to document a specific, fully verified security vulnerability.
DO NOT USE:
  • For general security observations without specific vulnerabilities
  • When you don’t have concrete vulnerability details
  • When you don’t have a proof of concept or aren’t 100% sure it’s a vulnerability
  • For tracking multiple vulnerabilities (create separate reports)
  • To re-report a vulnerability that was already reported

Required Parameters

title
string
required
Clear, specific title (e.g., “SQL Injection in /api/users Login Parameter”). Keep concise. Don’t mention CVE number in title.
description
string
required
Comprehensive description of the vulnerability and how it was discovered
impact
string
required
Impact assessment: what attacker can do, business risk, data at risk
target
string
required
Affected target: URL, domain, or Git repository
technical_analysis
string
required
Technical explanation of the vulnerability mechanism and root cause
poc_description
string
required
Step-by-step instructions to reproduce the vulnerability
poc_script_code
string
required
Actual proof of concept code, exploit, payload, or script that demonstrates the vulnerability. Python code.
remediation_steps
string
required
Specific, actionable steps to fix the vulnerability

CVSS Parameters

attack_vector
string
required
How the vulnerability is exploited:
  • N = Network (remotely exploitable)
  • A = Adjacent (same network segment)
  • L = Local (local access required)
  • P = Physical (physical access required)
attack_complexity
string
required
Conditions beyond attacker’s control:
  • L = Low (no special conditions)
  • H = High (special conditions must exist)
privileges_required
string
required
Level of privileges needed:
  • N = None (no privileges needed)
  • L = Low (basic user privileges)
  • H = High (admin privileges)
user_interaction
string
required
Does exploit require user action:
  • N = None (no user interaction needed)
  • R = Required (user must perform some action)
scope
string
required
Can the vulnerability affect resources beyond its security scope:
  • U = Unchanged (only affects the vulnerable component)
  • C = Changed (affects resources beyond vulnerable component)
confidentiality
string
required
Impact to confidentiality:
  • N = None (no impact)
  • L = Low (some information disclosure)
  • H = High (all information disclosed)
integrity
string
required
Impact to integrity:
  • N = None (no impact)
  • L = Low (data can be modified but scope is limited)
  • H = High (total loss of integrity)
availability
string
required
Impact to availability:
  • N = None (no impact)
  • L = Low (reduced performance or interruptions)
  • H = High (total loss of availability)

Optional Parameters

endpoint
string
API endpoint(s) or URL path(s) (e.g., “/api/login”) - for web vulnerabilities, or Git repository path(s) - for code vulnerabilities
method
string
HTTP method(s) (GET, POST, etc.) - for web vulnerabilities
cve
string
CVE identifier (e.g., “CVE-2024-1234”). Verify it’s valid using web search or vulnerability databases.
cwe_id
string
CWE identifier (e.g., “CWE-89” for SQL Injection, “CWE-79” for XSS). Use the most specific applicable CWE ID.
owasp_category
string
OWASP Top 10 (2021) category (e.g., “A01:2021 Broken Access Control”, “A03:2021 Injection”). Use full identifier with name.

White-box Parameters

MANDATORY for white-box testing: When you have access to source code, you MUST include code_file, code_before, code_after, and code_diff.
code_file
string
Exact affected source file path(s)
code_before
string
Actual vulnerable code snippet(s) copied verbatim from the repository
code_after
string
Corrected code snippet(s) exactly as they should appear after the fix
code_diff
string
Unified diff showing the code changes. Must be a complete, apply-able unified diff (git format) with proper file headers, line numbers, and sufficient context.

Response

success
boolean
Whether the report was created successfully
message
string
Status message
report_id
string
Unique identifier for the report
severity
string
Calculated severity (critical, high, medium, low)
cvss_score
number
Calculated CVSS 3.1 score

Duplicate Detection Response

duplicate_of
string
ID of the existing report this duplicates
duplicate_title
string
Title of the existing report
confidence
number
Confidence score (0-1) that this is a duplicate
reason
string
Explanation of why it’s considered a duplicate

Example

create_vulnerability_report(
    title="Server-Side Request Forgery (SSRF) via URL Preview Feature Enables Internal Network Access",
    
    description="""A server-side request forgery (SSRF) vulnerability was identified in the URL preview feature that generates rich previews for user-supplied links.

The application performs server-side HTTP requests to retrieve metadata (title, description, thumbnails). Insufficient validation of the destination allows an attacker to coerce the server into making requests to internal network hosts and link-local addresses that are not directly reachable from the internet.

This issue is particularly high risk in cloud-hosted environments where link-local metadata services may expose sensitive information (e.g., instance identifiers, temporary credentials) if reachable from the application runtime.""",
    
    impact="""Successful exploitation may allow an attacker to:

- Reach internal-only services (admin panels, service discovery endpoints, unauthenticated microservices)
- Enumerate internal network topology based on timing and response differences
- Access link-local services that should never be reachable from user input paths
- Potentially retrieve sensitive configuration data and temporary credentials in certain hosting environments

Business impact includes increased likelihood of lateral movement, data exposure from internal systems, and compromise of cloud resources if credentials are obtained.""",
    
    target="https://app.acme-corp.com",
    
    technical_analysis="""The vulnerable behavior occurs when the application accepts a user-controlled URL and fetches it server-side to generate a preview. The response body and/or selected metadata fields are then returned to the client.

Observed security gaps:
- No robust allowlist of approved outbound domains
- No effective blocking of private, loopback, and link-local address ranges
- Redirect handling can be leveraged to reach disallowed destinations if not revalidated after following redirects
- DNS resolution and IP validation appear to occur without normalization safeguards, creating bypass risk (e.g., encoded IPs, mixed IPv6 notation, DNS rebinding scenarios)

As a result, an attacker can supply a URL that resolves to an internal destination. The server performs the request from a privileged network position, and the attacker can infer results via returned preview content or measurable response differences.""",
    
    poc_description="""To reproduce:

1. Authenticate to the application as a standard user.
2. Navigate to the link preview feature (e.g., "Add Link", "Preview URL", or equivalent UI).
3. Submit a URL pointing to an internal resource. Example payloads:

   - http://127.0.0.1:80/
   - http://localhost:8080/
   - http://10.0.0.1:80/
   - http://169.254.169.254/ (link-local)

4. Observe that the server attempts to fetch the destination and returns either:
   - Preview content/metadata from the target, or
   - Error/timing differences that confirm network reachability.

Impact validation:
- Use a controlled internal endpoint (or a benign endpoint that returns a distinct marker) to demonstrate that the request is performed by the server, not the client.
- If the application follows redirects, validate whether an allowlisted URL can redirect to a disallowed destination, and whether the redirected-to destination is still fetched.""",
    
    poc_script_code="""import json
import sys
import time
from urllib.parse import urljoin

import requests

BASE = "https://app.acme-corp.com"
PREVIEW_ENDPOINT = urljoin(BASE, "/api/v1/link-preview")

SESSION_COOKIE = ""  # Set to your authenticated session cookie value if needed

TARGETS = [
    "http://127.0.0.1:80/",
    "http://localhost:8080/",
    "http://10.0.0.1:80/",
    "http://169.254.169.254/",
]


def preview(url: str) -> tuple[int, float, str]:
    headers = {
        "Content-Type": "application/json",
    }
    cookies = {}
    if SESSION_COOKIE:
        cookies["session"] = SESSION_COOKIE

    payload = {"url": url}
    start = time.time()
    resp = requests.post(PREVIEW_ENDPOINT, headers=headers, cookies=cookies, data=json.dumps(payload), timeout=15)
    elapsed = time.time() - start

    body = resp.text
    snippet = body[:500]
    return resp.status_code, elapsed, snippet


def main() -> int:
    print(f"Endpoint: {PREVIEW_ENDPOINT}")
    print("Testing SSRF candidates (server-side fetch behavior):")
    print()

    for url in TARGETS:
        try:
            status, elapsed, snippet = preview(url)
            print(f"URL: {url}")
            print(f"Status: {status}")
            print(f"Elapsed: {elapsed:.2f}s")
            print("Body (first 500 chars):")
            print(snippet)
            print("-" * 60)
        except requests.RequestException as e:
            print(f"URL: {url}")
            print(f"Request failed: {e}")
            print("-" * 60)

    return 0


if __name__ == "__main__":
    raise SystemExit(main())""",
    
    remediation_steps="""Implement layered SSRF defenses:

1. Explicit allowlist for outbound destinations
   - Only permit fetching from a maintained set of approved domains (and required schemes).
   - Reject all other destinations by default.

2. Robust IP range blocking after DNS resolution
   - Resolve the hostname and block private, loopback, link-local, and reserved ranges for both IPv4 and IPv6.
   - Re-validate on every redirect hop; do not follow redirects to disallowed destinations.

3. URL normalization and parser hardening
   - Normalize and validate the URL using a strict parser.
   - Reject ambiguous encodings and unusual notations that can bypass filters.

4. Network egress controls (defense in depth)
   - Enforce outbound firewall rules so the application runtime cannot reach sensitive internal ranges or link-local addresses.
   - If previews are required, route outbound requests through a dedicated egress proxy with policy enforcement and auditing.

5. Response handling hardening
   - Avoid returning raw response bodies from previews.
   - Strictly limit what metadata is returned and apply size/time limits to outbound fetches.

6. Monitoring and alerting
   - Log and alert on preview attempts to unusual destinations, repeated failures, high-frequency requests, or attempts to access blocked ranges.""",
    
    # CVSS Breakdown
    attack_vector="N",
    attack_complexity="L",
    privileges_required="L",
    user_interaction="N",
    scope="C",
    confidentiality="H",
    integrity="H",
    availability="L",
    
    # Optional fields
    endpoint="/api/v1/link-preview",
    method="POST",
    cwe_id="CWE-918",
    owasp_category="A10:2021 Server-Side Request Forgery"
)

Professional Report Guidelines

Customer-Facing Format: Reports must be professional and PDF-ready. Do NOT include internal details.

What NOT to Include

  • Local or absolute paths (e.g., “/workspace”)
  • Internal tools, agents, orchestrators, sandboxes
  • Model names or system prompts/instructions
  • Connection issues or internal errors
  • Stack traces or debug logs
  • Tester machine environment details

Tone and Style

  • Formal and objective: Use third-person perspective
  • Vendor-neutral: Don’t mention specific testing tools unnecessarily
  • Concise: Clear paragraphs, avoid runbooks or checklists
  • Precise: Use exact technical terms, avoid hedging

Standard Structure

  1. Overview (description)
  2. Severity and CVSS (calculated automatically)
  3. Affected asset(s) (target, endpoint)
  4. Technical details (technical_analysis)
  5. Proof of concept (poc_description + poc_script_code)
  6. Impact (impact)
  7. Remediation (remediation_steps)
  8. Evidence (in technical_analysis field)
Numbered steps are allowed ONLY within the proof of concept section. Elsewhere, use clear, concise paragraphs.

Deduplication

The tool includes automatic LLM-based deduplication. Reports describing the same vulnerability (same root cause on the same asset) will be rejected.
If the tool returns success=false with a duplicate mention:
  • DO NOT attempt to re-submit
  • The vulnerability has already been reported
  • Move on to testing other areas
The deduplication system analyzes:
  • Vulnerability root cause
  • Affected target/asset
  • Technical mechanism
  • Endpoint and method
  • Impact description

Build docs developers (and LLMs) love