picoCTF · picoGym Web Exploitation Easy 75 pts

Heapdump — Exposed Diagnostic Endpoint

OWASP A05 — Security Misconfiguration

Vulnerability Overview

A diagnostic memory dump endpoint (/heapdump) was left publicly accessible in production with no authentication requirement. The endpoint returned an 11MB snapshot of the server's memory, which contained the flag in plain text.

Discovery

The application's API documentation — accessible on the public blog — listed all available endpoints, including:

GET /heapdump — Diagnosing the memory allocation

Accessing the endpoint directly triggered an immediate download of heapdump-1780748535203.heapsnapshot.

Extraction

A simple grep against the heap snapshot file recovered the flag from within the 11MB dump:

grep -o "picoCTF{[^}]*}" heapdump-*.heapsnapshot

Root Cause

Diagnostic tooling was left enabled and publicly reachable in a production environment. Server heap snapshots can contain API keys, session tokens, database credentials, and full application state — making an exposed heapdump endpoint one of the most information-rich targets an attacker can find.

ControlImplementation
Remove diagnostic endpoints from production/heapdump, /debug, /metrics, /actuator should never be reachable publicly
Require authentication on all non-public routesIf a diagnostic endpoint must exist, restrict access to authenticated admins or internal network only
Automated scanningInclude common diagnostic paths in pre-deploy security checks
Key Insight: Read the documentation. In real-world engagements, API docs, Swagger UIs, and README files often expose endpoints that developers forgot to lock down. A memory dump endpoint in production is not a vulnerability — it is a full information disclosure event.
Flag See challenge on picoCTF picoGym