Example penetration test report

Example · fictional company

What every report includes

• Executive summary Overall risk, key themes, and priorities, in plain language for leadership.
• Technical findings Severity rating, CWE reference, affected assets, evidence, and reproduction steps for each one.
• Attack narratives How separate issues chain together into real impact.
• Remediation guidance Specific fixes for your stack, written for the engineers who will apply them.
• Attestation letter The test dates, scope, method, and results, to share with customers, auditors, or your insurer.
• Retest results An updated report and attestation letter once we’ve verified your fixes.

Example · fictional company

Executive summary

HackNow tested the Example Co. reporting platform, a web application and its API, from August 10 to 21, 2026. A low-privileged user could chain four issues that were low or medium on their own into read and write access to production customer data, including database backups. A separate flaw let any user read and change other customers’ reports. Example Co. fixed the critical, high, and medium findings, and our retest on September 21, 2026, confirmed each fix.

Example · fictional company

Scope and method

In scope

app.example.com (web application) and api.example.com (API)

Approach

Gray box, with test accounts for each of the platform’s three user roles in two separate customer organizations

Testing window

August 10 to 21, 2026, from agreed source IP addresses

Standards

OWASP Web Security Testing Guide v4.2, OWASP API Security Top 10 (2023), PTES, NIST SP 800-115

Severity

Each finding is rated Critical, High, Medium, Low, or Informational. How we rate findings

Out of scope

Denial-of-service testing

Final report

August 28, 2026

Example · fictional company

Severity overview

Critical

1

High

1

Medium

2

Low

1

Informational

0

Example · fictional company

Attack narrative

1. Step 1 · finding 3.5 (Low on its own): a malformed export request returned a stack trace naming the PDF renderer and the AWS host it runs on.
2. Step 2 · finding 3.1 (Medium on its own): the renderer fetched any URL placed in a report template, so we could make the server send requests for us (server-side request forgery).
3. Step 3 · finding 3.3 (Medium on its own): the renderer’s host still allowed IMDSv1, so one of those requests returned temporary credentials for the export-worker role.
4. Step 4 · finding 3.4 (Medium on its own): that role could read and write every storage bucket, including database backups.

We reported the attack path to Example Co.’s named contacts on August 12, within 24 hours of confirming it.

Rated one at a time, these are low and medium issues. Together they form one critical path from a low-privileged account to production customer data.

Example · fictional company

Findings

• 3.1 Server-side request forgery exposes cloud credentials and customer data

  Critical

  Step 2 of the attack path, rated by the impact of the path
• 3.2 Any user can read and change another organization’s reports by changing the report ID

  High

  Separate from the attack path
• 3.3 Cloud metadata service reachable from the PDF renderer (IMDSv1 enabled)

  Medium

  Step 3 of the attack path
• 3.4 Export worker role can read and write every storage bucket

  Medium

  Step 4 of the attack path
• 3.5 Stack trace on the export endpoint reveals the PDF renderer and its AWS host

  Low

  Step 1 of the attack path

POST /v2/reports/export HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi…
Content-Type: application/json

{"template":
  "<iframe src='http://169.254.169.254/latest/meta-data/iam/security-credentials/export-worker'></iframe>"}

In a full report, findings 3.3 to 3.5 each get the same treatment: evidence, reproduction steps, and specific fixes.

Example · fictional company

Retest status

• 3.1, 3.2, 3.3, and 3.4 Fixed. Verified in our retest on September 21, 2026.
• 3.5 Open. Example Co. has scheduled the fix for its next release.