Is this a real penetration test report?

Yes. It is an unedited report from an actual SwarmPT engagement — the same document a paying client receives. The target is a business that has since closed and whose site is offline, which we retain deliberately so we can publish a genuine report without exposing a live customer. Nothing has been softened or reformatted for marketing.

Do I have to give you my email to download it?

No. It is a direct link with no form, no gate and no follow-up sequence. You should be able to see the quality of the work before you talk to anyone — that is the entire point of publishing it.

How long should a penetration test report be?

Length follows findings, not padding. This one is 23 pages for 7 findings, because each finding carries full analysis, working proof-of-concept code and remediation. Be sceptical of very long reports that are mostly boilerplate methodology and scanner appendices, and equally of a two-page summary with no evidence.

What are the attack paths in the report?

Individually-scored findings understate real risk, because attackers chain them. The report has a dedicated Attack Paths section showing the routes an attacker could actually walk through the confirmed findings, step by step, with the business impact of each chain. One of the three paths in this sample deliberately dead-ends — the master password held and the chain stops there. We report that too, because what stopped an attacker is as useful to you as what did not.

Why does the report list things that were not exploitable?

Appendix A records what was actively attempted and did not succeed — parameter pollution, method tampering, SQL injection, XSS, IDOR, RCE, SSRF, subdomain takeover, and the client-excluded brute-forcing. A findings list alone never tells you what was tried, which is exactly how a scan can be passed off as a test. The boundary of the testing is part of the deliverable.

Will this format satisfy our auditor or cyber-insurance underwriter?

Yes. Auditors want scope, methodology, evidence, severity rationale and tracked remediation — all present. The report also carries a MITRE ATT&CK mapping appendix and a compliance mapping appendix tying each finding to OWASP, PCI DSS, SOC 2 and NIST CSF control references, both of which are shown in this sample. Add a live briefing if your leadership wants it walked through against the evidence.

Do you retest after we fix the findings?

Yes, and it is included. Once you have remediated we retest the critical and high findings and reissue the report with confirmed closure status — which is the document your auditor actually wants to see.

Can we get a report like this for our environment?

Yes. Use the instant estimator to price your scope in about a minute, or contact us and we will scope it with you. Every engagement produces this deliverable — AutoPT or SwarmPT, the report is the same.

A real penetration test report

Q: What is in a penetration test report?

A good report has two halves. The executive layer — severity summary, findings overview and business risk framing — is for leadership and auditors. The technical layer gives each finding its own section: CVSS score and vector, CWE classification, affected endpoint, a description, business impact, technical analysis of how it was established, reproduction steps with working proof-of-concept code, and specific remediation guidance. If a report has the first half and not the second, you bought a summary of a scan.

Not a template. Not a redacted teaser. This is an unedited 23-page report from an actual SwarmPT engagement — the same document a client receives, with working proof-of-concept code for every finding.

Download the report (PDF)Price your environment

No email required. No form. Direct link.

Pages

Confirmed findings

Rated high

100%

With working PoC code

What is in a penetration test report?

A penetration test report has two layers. The executive layer — severity summary, findings overview, business risk framing — is what leadership and auditors read. The technical layer gives every finding its own section: CVSS score and vector, CWE classification, affected endpoint, description, business impact, technical analysis, reproduction steps with working code, and specific remediation.

The technical layer is where you can tell a real engagement from a scan with a cover page. If findings arrive without evidence you can reproduce, nobody proved anything — they matched a signature and moved on.

What the engagement found

Seven confirmed findings, ordered by severity — exactly as they appear in the report's overview table.

ID	Finding	Severity	CVSS
vuln-0001	Publicly Exposed Odoo Database Manager at /web/database/manager	HIGH	8.6
vuln-0004	Cart Quantity / Order Total Manipulation via Unvalidated set_qty	HIGH	8.2
vuln-0006	Contact Form Integrity Control Bypass via Missing Signature Enforcement	HIGH	7.3
vuln-0002	Odoo JSON-RPC Verbose Traceback Information Disclosure	MEDIUM	5.3
vuln-0003	Odoo Version Information Disclosure via /web/webclient/version_info	MEDIUM	5.3
vuln-0007	Mailcow autoconfig exposes backend mail server hostname and admin URL	MEDIUM	5.3
vuln-0005	Host Header Injection in /web/reset_password Allows URL and Cache Poisoning	MEDIUM	4.2

Note what is nothere: no informational padding, no "missing security header" filler to inflate the count. Seven findings that were proven, and the report says plainly which bypass attempts failed.

Anatomy of a finding

Every finding in the report carries all five of these. If a report you are comparing is missing the last two, it cannot be acted on.

Finding metadata

ID, severity, CVSS 3.1 score and full vector string, CWE classification, target, endpoint and HTTP method — everything an auditor needs to verify the rating you were given.

Description and impact

What the flaw is, and separately what it means for the business. The impact section is written for someone who does not read CVSS vectors for a living.

Technical analysis

How the finding was established, including what was tried and did not work. Bypasses that failed are documented too — that is how you know the testing was real.

Working proof of concept

Numbered reproduction steps plus runnable code. Your engineers can confirm the finding themselves rather than taking our word for it.

Specific remediation

Named config directives, exact endpoints to restrict, controls to enforce. Not "apply security best practices".

Fix priority and effort

Every finding carries a P1/P2/P3 priority and an effort estimate, so your engineers know what to do first and roughly how long it takes — not just how bad it is.

One finding, in full

Finding 2 from the report — a business logic flaw no scanner will ever find, because finding it requires understanding what a shopping cart is for.

HIGH · CVSS 8.2vuln-0004 · CWE-807

Cart Quantity / Order Total Manipulation via Unvalidated set_qty

An unauthenticated visitor can submit an arbitrary set_qty value for any product. The server accepts the client-supplied quantity and recalculates the subtotal, tax and order total with no upper bound, stock check or business-rule validation.

Proven impact

$14.95 product → $16,183,358.82 order total

via set_qty=999999 — subtotal $14,949,985.05 plus $1,233,373.77 tax

Why it matters beyond the cart

Distorts sales reporting and tax calculation
Bypasses fraud thresholds and payment-provider limits
Corrupts any downstream ERP or invoicing that trusts the cart total

The report includes a runnable async Python script that reproduces this end to end — extracting the CSRF token, posting the inflated quantity, and reading back the manipulated total. Your engineers can verify it in minutes.

Read all seven findings

Sample Report — Common Questions

Want one of these for your environment?

Price your scope in about a minute, or talk to a pentester. Every engagement produces this deliverable — including the remediation retest.

Get an instant estimate Talk to a pentester