Results at a glance
Case flow
- 01Test the proxy boundary
Request-smuggling research reached the protected administrative host.
- 02Remove User-Agent
The simplified request omitted the header entirely.
- 03Observe fail-open behavior
The Google OAuth wall disappeared and the internal login rendered.
- 04Report and remediate
The security team confirmed the privilege impact and fixed the proxy rule.
A few months ago, my friend MoSec convinced me to look into HTTP Request Smuggling (HRS). I usually avoid classic vulnerabilities because of the heavy competition, but I decided to test my new skills on my primary, private HackerOne target.
The target's admin panel (https://admin.target.com/) was protected by an OAuth proxy that forced unauthenticated users to log in via Google. I wanted to see if HRS could smuggle a request past this proxy.
I downgraded an HTTP/2 connection to HTTP/1.1 and sent a multi-part payload, deliberately leaving the User-Agent header out of the smuggled block:
GET /test?a=a% HTTP/1.1
Host: admin.target.com
User-Agent: Mozilla/5.0...
GET /admin/login HTTP/1.1
Host: admin.target.comTo my shock, the Google OAuth wall vanished. In its place was a standard application login screen. Per the program's policy—which explicitly requested reports if the internal login panel could be exposed—I immediately submitted the finding as an HRS bypass.
The Plot Twist
The security team triaged the report in under 10 minutes, changing the severity to Critical. I was stunned by the speed until a triager explained the impact: if an attacker logged into this exposed panel using standard consumer credentials from the main site, they would inherit full administrative privileges over the entire platform.
Then came the real surprise. The team reviewed the infrastructure and realized my "smuggled" request hadn't exploited an HRS flaw at all. Instead, the proxy was configured to simply ignore or fail open on requests missing a User-Agent header.
The actual exploit was beautifully simple:
GET /admin/login HTTP/1.1
Host: admin.target.comBy completely removing the User-Agent header, the OAuth proxy dropped its guard entirely, exposing the internal application logic.
The Takeaway
The bug was fixed, and I was awarded a four-figure bounty within a single hour.
Even though the vulnerability wasn't what I originally set out to find, the process of testing for it uncovered a critical flaw. Sometimes, when you are searching for one specific gate, you end up stumbling into an entirely different entrance.
For more security write-ups, you can follow me on Twitter: @siratsami71
Could the same assumption be hiding in your attack surface?
Test the exact trust boundary—and the paths around it—with evidence-led manual security assessment.
Discuss a security assessment
Sirat Sami
10+ years in cybersecurity and bug bounty hunting. Reported 200+ vulnerabilities including 50+ high and critical severity issues across 130+ companies, among them Slack, the U.S. Department of Defense, Sony, PlayStation, Snapchat, TikTok, Amazon, Zoom, and GitLab. Attended the H1-4420 live hacking event in London.
View profile and research