Debug & Development Surfaces

Severity: Critical

The tool the developer used to fix the app is now a tool for anyone to run it.

What it is

Frameworks ship powerful debugging aids: interactive consoles on error pages, profilers, admin shells, status pages that print configuration. They are meant for a developer's laptop. When the 'debug' switch is left on in production, those aids become remote code execution or full configuration disclosure for anyone who can trigger an error.

Some of these surfaces are protected by a secret — a PIN, a token — but the secret is often derived from facts about the machine. If another bug lets you read those facts, the protection falls with it, which is why debug surfaces show up in chains more often than alone.

The organisational cause is environment drift: a setting that was correct in development was never changed for deployment, and nothing in the pipeline checked.

How to approach it

Fingerprint the framework from headers, error pages, cookies and default routes.
Trigger an error deliberately (wrong type, missing parameter) and read what the error page offers.
Check the framework's well-known debug, console, status and metrics paths.
If the surface is gated, read the framework's documentation for how the gate is derived, and ask whether anything else on the target leaks those inputs.
Treat any interactive console as code execution and stop at proof.

How you'll recognise it

The tells that should make you slow down and test this class properly.

Detailed stack traces with source snippets or local variables.
A framework banner or console prompt on an error page.
Paths like console, debug, actuator, _profiler, phpinfo or status answering in production.
Configuration values (environment names, internal hosts, keys) printed in responses.

Your task

Find the development tool that was left reachable, work out how its protection is derived, and get past it.

▶ Access the lab

Opens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.

Proving it to a triager

On a real programme the report is what gets paid. What the evidence needs to show, and what usually gets it closed.

Show the debug surface and the request that reaches it; for a console, run one benign command and stop.
If configuration leaks, list the classes of secret exposed, not the values.
Severity is critical for an interactive console, medium to high for configuration disclosure depending on what it contains.
Common N/A: a verbose error page with nothing sensitive and no interactive component.

🎓 Want the full course? — from Uncle Rat, half price with code DISCOUNT

003 Ultimate Bug Bounty Guide Part 1 — Main App Hacking ↗ How I take apart a single main application, end to end. 040 Uncle Rat's Burp Suite Workflow Handbook ↗ The Burp workflow I actually hunt with.

How to prevent it

Make debug mode impossible in production builds, not just 'off by default' — fail the deploy if it is on.
Serve generic error pages to users and send detail to logs only.
Remove or network-restrict consoles, profilers and status endpoints in every non-local environment.
Do not rely on a secret derived from machine facts; assume those facts can leak.

More Recon & Attack Surface labs

Recon & Attack Surface — You cannot test what you never found. Build the inventory first.

← All labs