Credit: Sonvh (Pentester)
October 2024. Cold winds began rustling the trees, and dry leaves fell in flurries onto the windowsill. They seemed desperate to sneak into the warmth of the room, seeking shelter before winter fully arrived. But all attempts were stopped cold by the unfeeling glass. Under my sight, I couldn’t help but relate—wondering, “Am I any different from those leaves? Can I slip past the firewall that’s blocking me?”
Turns out… I could.
This wasn’t just another random vulnerability. This was one of those moments where creativity meets research—where bypassing WAF and pulling off RCE wasn’t just the goal, it became the statement. More than just a win, it was a chance to help the client update their understanding of modern attack surfaces.
This particular client was no slouch when it came to security: Cloudflare WAF was fully enabled, bot detection was on for both staging and production, DNS redirection was in place, and there was even basic auth layered in. Before we could properly dig into the scope, we had to jump through some serious setup hoops.
Eventually, I found my golden ticket: a file upload feature for PDFs, user-role only, but wide open enough to make it worth investigating. Naturally, as a handsome and responsible security professional, I started with a standard best-practice review. Soon enough, I realized the only real path left was to slip in something malicious.
First step, I traced the PDF’s journey. Turns out, the final stop for these files was rendering in Google Docs gview. And from what I know, if the site isn’t doing any heavy sanitizing, you can sometimes sneak JavaScript execution right through a PDF.
Side note: it’s not just gview you have to worry about. PDF.js, the well-known PDF rendering library from Mozilla, was hit with a critical vulnerability in April of the same year.
So yeah, no matter what rendering engine you’re using, if you’re not properly validating input, you’re basically playing with fire, without wearing any protective gear.
That reminded me of a classic PDF XSS trick. I crafted a normal-looking file, cracked it open in a text editor, and dropped in a payload, hoping to get a PoC to pop.
Uploaded. Traced. Viewed.
In the test environment, it hit. Full RCE.
Even though by this point the client was already sweating bullets, I still wanted to test my luck, see if I could get past the production environment.
When I reproduced it there, the file just vanished. Not too surprising, with Cloudflare standing guard.
I was just trying my luck, planning to close the report and move on to another bug. But then… I heard it, a call from the ancestors: “No, my child. You will not be defeated by this WAF. You will bypass it.”
Now, based on what I know, most WAFs handle malicious input in two ways:
- Rewrite or encode the payload to defuse it.
- “If you don’t change yourself for me, I will break up with you”, drop and block.
This case felt like option 2: no sanitizing, just outright rejection. So rather than waste time trying to reverse-engineer encoding logic, I went for the creative route, finding a payload that the WAF’s devs or their ML system hadn’t accounted for yet.
My approach was to systematically test a variety of payload variations, alternating them with small modifications and observing the server’s response each time. The goal was to both predict and identify:
- Which patterns the WAF would block or allow, providing insight into the rulesets in use.
- The correlation between payload length and response time, which could reveal characteristics like regex-based inspection or deep packet analysis by the WAF.
Trial after trial, and finally: success. A clean bypass, capped off with a satisfying alert(1).
And just like that, I’d slipped past the firewall.
The PDF-man strikes again.
From there, the door was open for anything: cookie theft, user behavior hijacking, even accessing internal APIs — all depending on how well the application was secured behind the firewall.
Afterward, I worked with the client to submit a support ticket to Cloudflare. They acknowledged the issue, but due to policy limitations, couldn’t dive into it further on the technical side.
While none of this is particularly groundbreaking, it’s a good reminder: WAFs and other perimeter defenses aren’t silver bullets. They may slow attackers down at first, but for persistent pros, it’s just a matter of time. If the core app isn’t built with solid security in mind, WAFs are just expensive window dressing.
And so, the saga of the PDF-man continues.
What happens next? Stay tuned…
