Cloudflare's PHP CTF Tests WAF Bypasses Against the php2shell Flaws

Cloudflare has opened a capture-the-flag challenge that asks researchers to get past its web application firewall (WAF) and read a file from a live PHP sandbox. The target is built around the two PHP vulnerabilities behind php2shell, so the question is less whether a known bug exists and more whether the WAF's protections hold up when someone tries hard to break them.

Why test the WAF this way

Cloudflare shipped client updates, several mitigations, new WAF rules and a feature called full transaction detection while php2shell was unfolding. Those protections were made available on all plans, including Free. But a rule set written under time pressure is a hypothesis, and this challenge is a way to test it against people who actively look for gaps.

The timing matters. Cloudflare's framing is that widespread AI tooling lets attackers find new vectors much faster than before. That's a claim about the threat model rather than something the challenge proves, but it explains why the company wants real-world attempts rather than only internal testing. Protecting against vulnerabilities like these is an ongoing process, and each bypass attempt is data about where the detections are thin.

The challenge has already produced results. Cloudflare has said that submissions helped it harden its existing php2shell protections and build new detections, and that managed-rule changes are documented in its WAF changelog.

What the target actually runs

The setup is deliberately narrow. The target runs stock PHP 8.5.11 with standard extensions, Apache 2 via mod_php, and an empty index.php inside a Cloudflare Container. The default WAF rules for CVE-2026-109618 and CVE-2026-109619 sit in front of it. Inside the sandbox is a single file, /flag.

The sandbox resets every few minutes, and the flag file resets with it. That rules out slow, persistent footholds. A working chain has to land, read the flag and get verified before the environment is wiped.

The objective is to bypass the WAF, execute code on the PHP sandbox, and recover the current contents of /flag. Participants can bring their own tooling, and the challenge page holds environment details, scope and the flag verification form.

What counts as a valid submission

This is where the challenge gets more interesting than a typical CTF. Getting a flag isn't enough to claim a bounty. Participants need to:

• Create a HackerOne account and accept the Bounty Terms before taking part.
• Demonstrate attacker-controlled PHP code or command execution through an authorized POST request.
• Recover the current /flag contents and verify them in the CTF interface promptly, before a reset.
• File a private HackerOne report titled with "PHP CTF," including the full payload and request sequence, raw captures or a reproducible proof of concept, an explanation of the bypass, the attempt ID, verification result and UTC timestamps.
• Explain what makes the method materially distinct and list related submissions the researcher knows about.

The rule that matters most is the duplicate standard. Awards require a materially distinct WAF bypass mechanism, even when the underlying CVE is the same. Reports that use the same bypass mechanism are duplicates, regardless of differences in exploit code, payload, RCE technique or flag-recovery method. New flags, resets, attempt IDs and cosmetic changes don't count, and neither do equivalent encodings. Only the first complete, reproducible report is considered, even if the issue is still unpatched. Cloudflare makes the final duplicate and reward decisions.

Several things are explicitly ineligible: file disclosure without RCE, RCE without flag recovery and UI verification, local-only exploits, rediscovery of the known PHP bugs, detection differences alone, and partial chains that don't reach the full objective. That's a sensible filter. A WAF detection gap that doesn't lead to code execution is useful to know about, but it isn't the same finding as a working bypass.

Scope and data handling

Testing is limited to the challenge hostname's /php/* endpoints, and only via POST. Other Cloudflare services, the underlying infrastructure, the upstream PHP project and third-party systems are out of scope. Denial of service, high-volume scanning, persistence, social engineering and attacks on other participants are all off the table. If the target returns a 429 or 503, back off.

Cloudflare records attempt metadata and request payloads to analyze reports, so researchers should use test data only and keep credentials and personal information out of their requests. The privacy notice applies before testing begins. Cloudflare has also said the Bounty Terms prevail if this blog post conflicts with them, and it can suspend or end the challenge at any time. Once it's removed from HackerOne, it's over, so the HackerOne program page is the place to check current status.

What this doesn't replace

A WAF can block exploit traffic and keep exposed data from leaving the origin, but it can't undo anything an attacker already did on the server. Cloudflare says plainly that its WAF isn't a substitute for patching. If you run PHP, the practical step is to follow the PHP security advisories and apply the relevant updates. The CTF measures how far the perimeter holds, not whether your servers should stay unpatched behind it.

Here's the thing I'd watch: the bypass classes that come out of this challenge will be more useful than any single flag. Each materially distinct mechanism shows where signature-style detection for PHP deserialization and code-execution paths is weak, and that's the data defenders can turn into better rules. If you want to try, the flag is at php-rce.cloudflare.app, and Cloudflare would like to know whether you can get it.