Context: a rough week for web security

The launch follows a period in which Cloudflare responded to the compromise of eight eMudhra intermediate certificates — raising the prospect of forged certificates used to impersonate servers — and to php2shell, the set of serious PHP vulnerabilities affecting the runtime used across much of the Web. Cloudflare shipped client updates and multiple mitigations, added WAF rules to block exploitation of the PHP flaws, and introduced full transaction detection. All of these capabilities were made available on every plan, Free included.

Purpose of the challenge

Cloudflare frames vulnerability defense as a continuous process rather than a one-time fix. With AI giving attackers faster ways to find new vectors, real-world data is needed to test assumptions and harden protections. The result is the Cloudflare PHP Capture the Flag challenge, run through the company's HackerOne Bug Bounty program: a deliberately vulnerable PHP installation sits behind the WAF, and researchers are invited to bypass the protections and capture a flag.

The environment

The challenge targets CVE-2026-109618 and CVE-2026-109619, the two vulnerabilities behind php2shell. The stack is stock PHP 8.5.11 with standard extensions, Apache 2 via mod_php, and an empty index.php, all running in a Cloudflare Container. Cloudflare's default WAF rules for these vulnerabilities are enabled in front of it, and the sandbox holds a file at /flag.

The goal is to bypass the WAF, exploit the sandbox, and recover the contents of /flag. Participants may use their own research tools; environment details, scope and a flag verification form are on the challenge page. The sandbox, flag file included, is reset every few minutes.

Eligibility and reporting requirements

The challenge is time-limited and governed by HackerOne's terms and the Cloudflare program rules (the "Bounty Terms"). To claim a bounty, a participant must first create a HackerOne account and accept those terms before taking part, then meet the following conditions:

  1. Demonstrate attacker-controlled PHP code or command execution inside the sandbox through an authorized POST request.
  2. Use that RCE to read the current /flag contents and verify the flag through the CTF user interface promptly, before a reset.
  3. File a private HackerOne report titled with PHP CTF, containing:
    1. The endpoint, full payload and request sequence, with relevant headers, encoding and body bytes preserved.
    2. Raw request/response captures, or a readable proof of concept sufficient to reproduce the full chain.
    3. An explanation of the WAF bypass, the code or command executed, and how it recovered /flag.
    4. The attempt ID, the successful UI verification result, and UTC timestamps for the exploit and verification; include the flag privately if verification requires it.
    5. What makes the method or payload materially distinct, plus any related submissions the researcher knows of.

UI verification alone does not file a HackerOne report or establish reporting priority. Several outcomes are ineligible: file disclosure without RCE; RCE without flag recovery and UI verification; local-only exploits; rediscovery of the known PHP vulnerabilities; and WAF detection differences or partial chains that don't reach the full objective.

Diagram of sending the exploit payload, capturing and verifying the flag.

Awards require a materially distinct bypass method or exploit payload, even against the same CVE. New flags, resets, attempt IDs and cosmetic changes — equivalent encodings included — do not count as unique. Equivalent submissions are treated as duplicates even if still unfixed, and only the first complete, reproducible HackerOne report is considered; Cloudflare makes the final duplicate and reward decisions.

Scope and privacy

Attempt metadata and request payloads are recorded to help analyze reports, so only test data should be sent — no credentials, personal information, or anything not meant for a research record. Cloudflare's privacy notice should be read before testing.

Testing is authorized solely against the challenge hostname's WAF-protected /php/* endpoints using POST. Out of scope are other Cloudflare services, direct access to the underlying infrastructure, the upstream PHP project and third-party systems. Denial of service, high-volume scanning, persistence, social engineering and attacks on other participants are prohibited, and researchers receiving a 429 or 503 should back off. If the blog post and the Bounty Terms conflict, the Bounty Terms prevail.

Cloudflare may suspend or terminate the challenge at any time; once it is removed from HackerOne, it is officially over, so the Cloudflare HackerOne page is the authoritative source on whether it remains open.

WAF is not a patching substitute

Response blocking can keep exposed data from reaching an attacker, but it cannot reverse actions already taken at the origin. Operators running PHP should follow the latest PHP security advisories and apply the relevant updates.