> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Cloudflare launches CTF to test WAF against php2shell PHP RCE flaws - URL: https://f4n6.co.uk/security-feed/cloudflare-launches-ctf-to-test-waf-against-php2shell-php-rce-flaws/ - Published: 2026-10-27T15:36:22.000Z - Updated: 2026-10-27T15:36:22.000Z - Author: Jeff Davies - Tags: #security-feed, CVE-2026-109618, CVE-2026-109619 ## 1\. Executive summary Cloudflare has opened a HackerOne bug-bounty capture-the-flag challenge built around php2shell, the pair of PHP runtime flaws tracked as CVE-2026-109618 and CVE-2026-109619\. Both are rated CVSS 9.2 CRITICAL, both are listed in CISA KEV with an add date of 2026-10-26, and both carry an EPSS score of 100%, so exploitation is not hypothetical: Cloudflare reported attack traffic against its customers before the challenge launched and shipped WAF rules roughly nine hours ahead of public disclosure. The flaws affect every PHP release from 5.4 onward, and fixes exist only for the 8.x branches (8.5.12, 8.4.27, 8.3.36, 8.2.35); PHP 5.x through 8.1.x are end-of-life with no upstream fix. For EMEA financial services the exposure is the PHP estate itself, including customer-facing WordPress, Drupal, Joomla, Laravel and Magento applications and any third-party or hosting provider running unpatched PHP, and the CTF does not change that exposure: it is a defensive test exercise, not a new attack vector. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | DORA Art. 17 | Two CVSS 9.2 PHP runtime flaws in CISA KEV with EPSS 100% require an ICT-related incident management process that covers detection, containment and patch rollout across the PHP estate, including internet-facing applications and provider-managed hosting. | Firms must be able to show a documented, exercised process for handling an actively exploited runtime flaw, not an ad hoc patch scramble. | | DORA Art. 28 | PHP is frequently run by hosting providers and third-party application operators, so the patch state of CVE-2026-109618 and CVE-2026-109619 sits partly outside the firm's direct control. | Third-party risk management must confirm provider patch status and contractual notification of exploitation affecting the firm's applications. | | NIS2 Art. 21(2)(d) | The flaws sit in a shared runtime used across the supply chain, and upstream fixes exist only for supported 8.x branches, leaving EOL PHP 5.x to 8.1.x without a vendor patch. | Supply chain security measures must cover dependency and runtime version tracking, including identifying EOL PHP in the estate and in supplier environments. | ## 3\. Technical analysis & attack chain The two CVEs are memory-safety flaws in how PHP handles a request that fails partway through processing. PHP allocates memory to process an HTTP request and releases it when the work finishes. When processing stops unexpectedly, for example on memory exhaustion or a fatal error, PHP does not clean up safely, and the flaws arise when it then uses data that was never fully initialised or memory that has already been freed. NVD classifies both as CWE-416 (Use After Free) with CWE-755; Cloudflare's write-up describes the same mechanism in terms of error-path cleanup rather than naming the CWE, and the two descriptions are consistent. The two differ in when the unsafe access happens. In CVE-2026-109618, PHP runs out of memory and interrupts its work before some internal data has been properly initialised, then during cleanup of that request uses the unfinished data as though it were valid. In CVE-2026-109619, a fatal error interrupts a request and leaves PHP holding a reference to memory it has already released. Both are triggered by specially crafted HTTP requests; large requests are one way to put memory under pressure, but the impact goes beyond resource exhaustion. Confirmed attack chain, as far as public sources establish it: 1. An attacker sends a crafted HTTP request to a PHP application, using request size or content to drive PHP into the error path (memory exhaustion for CVE-2026-109618, a fatal error for CVE-2026-109619). 2. PHP's error handling fails to clean up the affected memory, leaving uninitialised or freed memory in use. 3. The attacker manipulates the data PHP encounters in that invalid memory to influence execution. 4. Depending on the payload, the outcome is a crash of the PHP process (denial of service), exposure of sensitive information, or execution of attacker-supplied code. 5. Where code execution succeeds, the expected follow-on is a web shell giving the attacker a browser-accessible control panel on the host, which Wiz assessed as the likely mass-exploitation outcome. Affected and fixed versions, per Kevin Beaumont's reporting cited by Tenable and confirmed by Krebs: PHP 8.5.x fixed in 8.5.12, 8.4.x in 8.4.27, 8.3.x in 8.3.36, 8.2.x in 8.2.35\. PHP 5.x through 8.1.x are end-of-life with no upstream fix; Linux distributions that ship older PHP packages may backport, so distribution package users should check their vendor's advisories. CERT-EU advisory 2026-018 names both CVEs and states they could affect all PHP versions from 5 onward; the demonstration video references PHP 5.4.0 and later. W3Techs puts PHP at 69.3% of websites with a known server-side language. Estimates of internet-exposed vulnerable hosts vary: Silas Cutler's rough figure is over 1.3 million, Henk Poley's Shodan count is over 1.9 million. Treat both as order-of-magnitude estimates, not a census. The CTF environment itself is worth understanding because it tells defenders what Cloudflare believes its WAF can and cannot stop. 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, with default WAF rules for these CVEs in front. A file at /flag is the objective and the sandbox resets every few minutes. Testing is authorised only against the challenge hostname's WAF-protected /php/\* endpoints using POST. Cloudflare states plainly that the WAF is not a replacement for patching: response blocking can stop exposed data reaching an attacker but cannot undo actions already performed at the origin. Confidence caveats. The technical mechanism above rests on Cloudflare's own write-up and is single-sourced for the memory-handling detail; the PHP project had not published full technical detail at the time Tenable compiled its FAQ. The claim that watchTowr reproduced CVE-2026-109618 comes from watchTowr via BleepingComputer and is single-sourced. No named threat actor is associated with exploitation in any source, and no MITRE ATT&CK profile applies, so attribution is unconfirmed. The 1.3 million and 1.9 million host figures are individual researchers' estimates. CVSS scores differ across sources: the PHP security team rates both CVSSv4.0 9.2, while early reports including watchTowr and a Hacker News post described them as 10.0; the 9.2 rating is the one carried here. ## 4\. Mitigation & containment P1 within 24 hours - Patch PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 according to branch, on every internet-facing host running PHP. Both CVEs are in CISA KEV with EPSS 100%; treat any unpatched internet-facing PHP as compromised-adjacent and prioritise it above other patch work. - For PHP 5.x through 8.1.x, which have no upstream fix, either upgrade to a supported 8.x branch or apply the distribution vendor's backport; where neither is possible, remove the application from direct internet exposure. - Hunt for web shells on PHP hosts. Wiz assessed web shells as the likely mass-exploitation payload. Look for recently created or modified .php files in web roots and upload directories, and for PHP processes spawning shell commands. - If Cloudflare WAF is in front of the application, confirm the php2shell managed rules are active. They were deployed by default to all plans including Free from 2026-10-21 03:02 UTC, and the protections use full transaction detection, which inspects the origin response as well as the request. P2 within 72 hours - Inventory PHP versions across the estate, including applications run by hosting providers and third parties, and record which are EOL. This inventory is the input to the DORA Art. 28 and NIS2 Art. 21(2)(d) positions in section 2. - Review WAF and origin logs from 2026-10-20 onward for crafted requests to PHP endpoints that produced 500-series responses, memory-exhaustion errors, or unexpected output. Cloudflare observed attackers mutating payloads to evade its rules, so absence of WAF blocks is not evidence of absence of attempts. - Check PHP memory\_limit and request size limits on exposed applications. Large requests are one documented route to the error path; tighter limits raise the cost of triggering it, though they do not fix the flaw. P3 within 7 days - Add PHP runtime version to the standard asset inventory and patch cadence so EOL branches are visible before the next runtime CVE, not after. - Where a third-party provider runs the PHP application, obtain written confirmation of patch status against the fixed versions above and record it against the DORA Art. 28 obligation. ## 5\. Indicators of compromise No indicators of compromise available in the source material. The sources describe observable behaviours but publish no atomic indicators: no hashes, no domains, no IP addresses, no file paths beyond the CTF's own /flag, and no web shell filenames. Behavioural indicators | behaviour | where to observe | confidence | | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------------------- | | Crafted HTTP requests driving PHP into memory exhaustion or a fatal error, followed by abnormal process termination | Web server access and error logs, PHP-FPM or Apache error logs | Medium; mechanism described by Cloudflare, no request signatures published | | PHP process crash or restart correlated with a single inbound request | Process monitoring, systemd or container restart events | Medium | | Web shell creation in web-accessible directories following exploitation | File integrity monitoring on web roots and upload paths | Medium; Wiz assessment of likely payload, single-sourced | | Attackers mutating exploit payloads to evade WAF rules | WAF match logs cross-referenced with origin responses | Medium; Cloudflare observation, no payload strings published | ## 6\. Detection Insufficient indicators to author detection rules. The sources give the vulnerability mechanism and the affected versions but no artefact of the threat itself: no exploit strings, no web shell filenames or contents, no command lines, no registry keys, no network indicators. A rule built from CVE identifiers or product names would detect reporting about the flaw, not exploitation of it. Detection effort should go to the behavioural indicators in section 5 and to version-based exposure checks against the fixed releases in section 3. ## CVE assessment 2 referenced CVEs — **2 actively exploited (CISA KEV)**, 2 critical (CVSS ≥ 9.0) | CVE | CVSS | Exploited | EPSS | Summary | | ---------------------------------------------------------------------------------- | ------------ | ---------------- | ---- | ------------------------------------------------------------------------------------------------------------------------------- | | [CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618?ref=f4n6.co.uk) | 9.2 Critical | ⚠ KEV 2026-10-26 | 100% | PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts… | | [CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619?ref=f4n6.co.uk) | 9.2 Critical | ⚠ KEV 2026-10-26 | 100% | PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly… | ## 7\. Sources - Cloudflare, "Introducing the Cloudflare PHP Capture the Flag challenge", https://blog.cloudflare.com/php-ctf/, 2026-10-27. - Cloudflare, "Cloudflare deploys protections against php2shell vulnerability", https://blog.cloudflare.com/php-vulnerabilities-waf-protection/, October 2026. - Tenable Research, "php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions about critical PHP remote code execution vulnerabilities", https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote, October 2026. - Krebs on Security, "Widespread PHP Flaw May Cause Many Site Outages Today", https://krebsonsecurity.com/2026/10/widespread-php-flaw-may-cause-many-site-outages-today/, October 2026. ## 8\. Adverse Trace position Adverse Trace assesses CVE-2026-109618 and CVE-2026-109619 as the highest-priority patching item for any EMEA financial services firm running PHP, on the strength of the CVSS 9.2 CRITICAL rating, CISA KEV listing from 2026-10-26 and EPSS 100%, not on the CTF announcement, which is a defensive testing exercise and adds no new exposure. The client impact is concentrated in internet-facing PHP applications and in PHP run by hosting or application providers, where the firm's patch authority is indirect; the absence of any named actor or published exploit artefacts means attribution is unconfirmed and detection must rest on behaviour and version state rather than signatures. We will track the PHP advisory for the fixed-version confirmation and any published technical detail, monitor Cloudflare's rule changelog for new php2shell detections, and reissue this note if a named actor, web shell artefacts or atomic indicators become public. Clients should confirm their PHP version inventory against the fixed releases in section 3 and report back on any EOL PHP still exposed. --- [Read the original source →](https://blog.cloudflare.com/php-ctf/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*