The Vulnerability

Debug pages are a common byproduct of development. Tools like phpinfo() are incredibly useful while building and troubleshooting an application, since they dump detailed information about the server environment: PHP configuration, loaded modules, environment variables, file paths, and more.

The problem is that this same information is a goldmine for an attacker if the page is ever left accessible in production. Environment variables in particular often hold:

• API keys and secrets
• Database credentials
• Session signing keys (like SECRET_KEY)
• Internal service URLs

Step-by-Step Solution

1. Browse the application with Burp running

With Burp Suite intercepting traffic, I loaded the lab’s home page as a normal user would. This populates Burp’s site map with the page and its underlying requests.

2. Search for clues in HTML comments

Rather than guessing at hidden paths, I used Burp’s built-in comment finder. In Target > Site Map, I right-clicked the top-level entry for the lab and selected Engagement tools > Find comments.

This surfaced an HTML comment on the home page referencing a link labeled “Debug,” pointing to:

/cgi-bin/phpinfo.php

3. Send the debug page to Repeater

In the site map, I right-clicked the /cgi-bin/phpinfo.php entry and selected Send to Repeater to inspect the response more closely.

4. Retrieve the debug output

Sending the request in Repeater returned the full output of a phpinfo() call. This page is normally used to help developers verify their PHP configuration, but here it exposed the server's environment variables in full — including:

SECRET_KEY = zz296qa73qpb5t6k6yddcb5pj0fxr387

No authentication, no obfuscation — the value was returned directly in the HTTP response body.

5. Submit the solution

I copied the SECRET_KEY value, returned to the lab, clicked Submit solution, and entered it. The lab was marked as solved.gets exposed.

Written by Zeyad Naguib,
🔗 https://www.linkedin.com/in/zeyadnageeb
✍️ https://medium.com/@zeyadnaguib1