If you spend enough time staring at a terminal, hunting for vulnerabilities on hardened domains, your eyes start to play tricks on you. You start seeing zero-days where there are none.

Recently, while testing a highly secure, high-profile government VDP on Bugcrowd, I hit what I thought was the absolute jackpot. I found a way to perfectly bypass an AWS Web Application Firewall (WAF) using a novel path traversal technique. I was already picturing the P2 payout, the reputation points, and maybe even a CVE.

Instead, I got a brutal lesson in HTTP protocols, RFC standards, and why you should never implicitly trust your command-line tools.

Here is a breakdown of how I faked my own WAF bypass, why the payload never actually hit the target, and how to avoid this classic bug bounty trap.

The Setup: Hunting for Path Traversals

I was mapping out the infrastructure of a target domain (we will call it target.com). The backend was running Apache Tomcat, and it was sitting securely behind an AWS ELB WAF.

Like any standard recon phase, I was checking directories for misconfigurations. I attempted a classic path traversal to read the web.xml file:

Bash

curl -I "https://www.target.com/images/../../../../WEB-INF/web.xml"

The response was exactly what you would expect from a properly configured WAF:

HTTP

HTTP/2 403 
server: awselb/2.0
date: Wed, 25 Mar 2026 11:52:29 GMT

The WAF caught the ../ sequences and slammed the door. 403 Forbidden.

The "Aha!" Moment: Smuggling the Payload

I started playing with URL encoding, null bytes, and semicolons to see if I could create a discrepancy between how the WAF and the backend server parsed the URI.

Then, I tried inserting URL fragments (#) between the traversal sequences. The hypothesis was that the WAF might normalize the path differently than the Tomcat backend. I fired off this payload:

Bash

curl -I "https://www.target.com/images/../#../#../#../WEB-INF/web.xml"

I hit enter. My terminal output the following:

HTTP

HTTP/2 200 
date: Wed, 25 Mar 2026 11:52:31 GMT
content-type: text/html;charset=UTF-8
server: Apache Tomcat
200 OK

My heart rate spiked. The WAF didn't block it. I immediately replicated it on a subdomain and got the exact same 200 OK response. I spent the next hour documenting the PoC, wrote up a detailed report outlining the systemic AWS WAF configuration flaw, and hit submit on Bugcrowd.

I thought I had just documented a highly impactful, novel WAF bypass.

The Reality Check

A few days later, the Bugcrowd triager responded. The state of the submission was updated to Informational

The triager noted that a similar vulnerability had been reported on a different endpoint, but reading between the lines of the resolution, the truth was much harsher: my vulnerability didn't actually exist.

To figure out why, I had to stop looking at the target's server and start looking at my own Kali environment.

The Deep Dive: Why the Tools Lied

The issue wasn't a WAF misconfiguration. The WAF did its job perfectly. The "bypass" was entirely a mirage created by curl and the foundational rules of the internet.

It all comes down to RFC 3986 (Uniform Resource Identifier Generic Syntax).

According to the official IETF standard, the fragment identifier (the # and everything following it) is meant strictly for local, client-side execution. Browsers use it to scroll to a specific anchor tag on a webpage. Because of this, the RFC dictates that the fragment must not be sent across the network.

Because curl follows RFC standards, it silently parses the URL locally before it ever opens a socket connection.

When I typed this:

curl -I "https://www.target.com/images/../#../#../#../WEB-INF/web.xml"

curl saw the first # and instantly deleted it and the rest of the payload. The actual HTTP request that left my machine and hit the AWS WAF was simply:

GET /images/../ HTTP/2

The WAF inspected GET /images/../, saw that I was effectively just asking for the root directory (/), and let it through because it is perfectly harmless. The Tomcat server received the sanitized request and served me the default HTML homepage—hence the 200 OK and the text/html content type.

The WAF never bypassed my payload. My terminal deleted it before it even had the chance to try.

The Takeaway for Researchers

It is incredibly easy to get tunnel vision when you are chaining payloads in your terminal. You assume that what you type is exactly what hits the wire.

This false positive is a rite of passage, but you can avoid wasting your own time (and the triagers' time) by following one golden rule: Proxy your CLI tools.

If I had routed my terminal traffic through Burp Suite (curl -x http://127.0.0.1:8080 ...), I would have seen the truncated GET request in the proxy history immediately. I would have instantly realized the payload was dropping locally.

Bug bounty is a grind, and rabbit holes like this are part of the game. You don't always find a zero-day, but every false positive forces you to understand protocols at a deeper level. Next time you think you've broken a WAF with a weird character, check your proxy logs first. Your tools might just be following the rules a little too well.

Let's connect! I'm actively looking for opportunities in cybersecurity, red teaming, and tool development. You can find me on GitHub or reach out on LinkedIn.

If you found this breakdown helpful, give it a clap 👏 and share it with your network!