This program doesn't disclose reports, so I'll have to keep everything nicely anonymous. I'll go as in-depth as I can while staying within the NDA.

How It Began...

Bug hunting at scale means you end up crawling through a lot of subdomains and forgotten portals. One quiet evening I was doing exactly that—mapping out everything under a major phone provider’s umbrella—when I stumbled across websitesportal.redacted.com.

I fired up the usual toolkit, threw a quick directory scan at it, and there it was, staring me in the face like it had been waiting for someone to notice:

https://websitesportal.[redacted].com/nomad/index_dev.php/_profiler/

If you know Symfony, you already know what that path means... If you don’t… buckle up.

The Symfony WebProfilerBundle is a fantastic debugging tool. In dev environments. It gives you god-mode visibility: every HTTP request, full stack traces, database queries (with parameters), POST bodies, cookies, session data, environment variables, the works. The official Symfony docs are crystal clear about it:

“Never enable the profiler in production environments as it will lead to major security vulnerabilities in your project.”

Yet here it was, wide open on what was clearly a production system.

Exploitation

I hit the profiler endpoint directly and immediately saw the “Last 10 requests” list populated with real traffic. Click any token and you’re looking at the complete request/response cycle.

Request headers. Cookies. POST parameters (yes, including passwords). Full stack traces. Doctrine queries with bound parameters. Everything.

But the real magic (and the real danger) came when I realized this profiler was passing cookies from the main app. Bingo. I knew right then and there we were shooting for ATO.

Here’s how it worked:

1. Attacker sends malicious link to victim.
2. Victim clicks and their cookies from main app get logged in the debugger
3. Copy/Paste cookies and you're logged in 😎

From there it was trivial to replay them against the main app. One curl later and I was fully authenticated as that user:

curl -X GET 'https://www.[redacted].com/msapi/accountservices/v2/onboarding' \
-H 'Host: www.[redacted].com' \
-H 'Cookie: [paste-the-stolen-cookies-here]' \
... [other headers] \
--compressed

Account takeover achieved. Now truthfully there was some limitations as the program has a pretty robust security posture, however PII, minor account modifications, and some other minorly impactful stuff was still possible. 

Why This Matters (and Why It Still Happens)

This isn’t some obscure zero-day. It’s a textbook framework misconfiguration that the docs literally scream at you to avoid. Yet production systems still ship with index_dev.php and the full WebProfilerBundle enabled because someone forgot to strip the dev tools before going live.

The impact here at face value is massive:

• Full session theft → instant account takeovers
• Password exfil from any login forms hitting the portal
• Internal mapping of controllers, services, database structure
• Easy chaining into other vulnerabilities (SQLi, XSS, whatever else the stack traces reveal)

All of it available to anyone who could find that one URL.

The Report & Outcome

I wrote up a clean, detailed report with step-by-step reproduction, PoC videos, and even some friendly remediation advice pulled straight from Symfony’s own recommendations (disable the profiler in prod, restrict at the web server level, only load the bundle in require-dev, etc.)and sent it into the company where it was promptly fixed. 

Final Thoughts

Framework debug tools belong behind authentication, IP whitelists, and in development environments only. Full stop.

If you’re running Symfony (or Laravel, or Django, or anything with similar debug features), go check your production boxes right now. Search for /_profiler/, index_dev.php, debug, webgrind, whatever your framework calls its “oops I left dev mode on” endpoints.

They’re out there. I promise.

Classic misconfigurations are far from dead — they’re just hiding in plain sight on portals nobody remembers exist.

Stay curious, keep mapping those subdomains, and never trust a path that ends in _dev.php.

See you in the next one 😉