🔴 CRITICAL — PATCH AS SOON AS RELEASED AND ENABLE WAF BLOCKING NOW: Two critical PHP flaws, dubbed "PHP2Shell," affect PHP's session upload-progress handling and may lead to remote code execution under certain conditions. Details leaked before PHP's planned emergency release, and Cloudflare reports early attempts to exploit them.

Cloudflare has deployed temporary WAF rules for known exploit patterns. Reported affected versions run from 5.4.0 through 8.5.11, per the research repository, but this range is not confirmed by PHP. PHP 8.1 and older are end-of-life and will not receive official fixes. Mallory reports roughly 883,717 internet-facing hosts running PHP 8.1 or earlier. Until PHP publishes fixed versions, apply the interim settings below and review PHP applications for file inclusion and deserialization risk.


 

overview

The PHP security team published a notice on October 20, 2026 announcing an emergency release for two critical vulnerabilities. Researchers track the issues as CVE-2026-109618 and CVE-2026-109619 and call them PHP2Shell. Technical details leaked before the scheduled release, which the PHP notice did not anticipate. PHP has not published technical details, and its notice does not name the CVEs. Cloudflare reports early attempts to exploit the flaws. Cloudflare has shared no evidence, so the scale and success of those attempts cannot be assessed, and no independent source confirms them.

 

TECHNICAL DETAILS (Per research reporting)

Affected Component: PHP session upload-progress handling (session.upload_progress)

Reported Issues:

  • The upload-progress handler stores a supplied filename in session data without validation
  • A session ID sent in a POST body can bypass session.use_only_cookies
  • A use-after-free, triggered by re-entry into a var_destroy destructor. The researcher reports confirming it with AddressSanitizer
  • A PHP-FPM serializer state that may persist across requests
  • A handler mismatch that may run a destructor after deserialization fails

Prerequisites: Some attack paths require an application gadget, a local file inclusion flaw, or access to a local file. No single path is presented as universal. One chain requires upload progress to be enabled. Whether that is the default setting is not stated.

Attack Vector and Authentication: Not confirmed by PHP. Treat as remote and potentially unauthenticated until PHP's advisory is reviewed.

Proof of Concept: A public verification repository includes tools and a PHP-FPM and Nginx lab, stated for controlled testing. Earlier reporting described claims of leaked demonstrations as unverified.

 

affected scope

Item

Status

Affected versions (research repository)

PHP 5.4.0 through 8.5.11. Not confirmed by PHP

Planned fixed versions (research repository)

8.2.35, 8.3.36, 8.4.27, 8.5.12. Verify against PHP's advisory before deploying

Support status

8.2 and 8.3 receive security fixes only. 8.4 and 8.5 are actively supported. 8.1 and older are end-of-life and will not receive official fixes

Exposure (Mallory, Shodan data from October 20)

883,717 internet-facing hosts running PHP 8.1 or earlier, about 59% of roughly 1.5 million hosts that disclosed a PHP version

Frameworks and applications

None named. Treat any internet-facing PHP application as in scope

Note: PHP's notice, as quoted in reporting, confirms the scheduled release for October 21, 2026 at 14:00 UTC. Fixed version numbers are not confirmed by PHP and should be checked against its advisory when published.

 

early exploitation activity

  • Reporting party: Cloudflare, which reports early attempts to exploit the flaws and says its mitigations are being updated as new vectors appear
  • Confidence: Reported by Cloudflare, not confirmed by independent sources. Cloudflare has not shared evidence, dates, source IPs, domains, user agents, payloads, or targeted paths
  • Exploitation status: Early attempts reported. No confirmed in-the-wild compromises are reported in the material reviewed
  • Reporting caveat: The reporting notes that new PHP2Shell exploit patterns may evade rules written for known requests, but does not tie them explicitly to these CVEs

 

potential impact

  • Server compromise: Code execution under the web server or PHP-FPM process account on vulnerable hosts
  • Data exposure: Access to application databases, configuration files, session data, and stored credentials
  • Lateral movement: Pivot from the web tier into internal networks and connected services
  • Unsupported versions: PHP 8.1 and older will not receive official fixes, so hosts on those versions require upgrade or isolation rather than patching

 

indicators of compromise

  • Unusual requests involving PHP session handling, especially POST requests carrying session identifiers or upload-progress fields
  • PHP worker processes launching unexpected programs or spawning shells
  • Unexpected files written to session storage or web roots

Note: No specific network IOCs, IP addresses, domains, or hashes were provided in the reporting.

 

monitoring and telemetry

  • Build an inventory of all servers and containers running PHP, including version, SAPI (mod_php, PHP-FPM, CLI), and whether session.upload_progress is enabled
  • Forward web server access and error logs, and PHP-FPM logs, to SIEM (Microsoft Sentinel). Alert on POST requests to PHP endpoints that include session identifiers
  • Alert on unexpected child processes spawned by PHP-FPM or web server processes
  • Monitor for new or modified files in web roots and session directories, and for unexpected outbound connections from web servers
  • Confirm that WAF rules are in block mode, not log-only, and review blocked events for PHP2Shell patterns

 

compliance impact

PCI DSS: Requirement 6 (timely patching of critical vulnerabilities in public-facing web applications) applies directly. Hosts on unsupported PHP versions require documented compensating controls until upgraded.

HIPAA: Web applications handling ePHI must be protected under the HIPAA Security Rule (45 CFR §164.308 and §164.312). Assess exposure and document risk management decisions for unpatched or unsupported hosts.

SOX: Applications supporting financial reporting fall under ITGC change management. Apply emergency patches through the documented emergency change process with approval and rollback planning.

ISO/IEC 27001: Relevant controls include technical vulnerability management (A.8.8), change management (A.8.32), and secure development and configuration (A.8.25 to A.8.27).

NIST CSF: Maps to IDENTIFY (Asset Management, ID.AM; Risk Assessment, ID.RA), PROTECT (Platform Security, PR.PS), DETECT (Continuous Monitoring, DE.CM), and RESPOND (Mitigation, RS.MI).

GDPR: Web applications processing personal data must maintain security of processing (Article 32). If exploitation is confirmed, assess personal data breach notification under Article 33 (72 hours).

 

recommendations

PRIORITY 1 — Act Now (Before Release):

  • Identify every server, container, and application that runs PHP, with version, SAPI, and session configuration
  • Apply the interim settings below to all PHP hosts: disable session.upload_progress, and set session.use_only_cookies to On. These reduce exposure to some paths but are not a substitute for patching
  • Confirm WAF rules are enabled and in block mode. Cloudflare has deployed temporary WAF rules for known exploit patterns. These are a stopgap, not a fix
  • Plan upgrades for hosts on PHP 8.1 or earlier, since these will not receive official fixes

PRIORITY 2 — Patch on Release (October 21, 2026, 14:00 UTC and after):

  • Apply fixed PHP releases as soon as PHP publishes them. Confirm version numbers against PHP's advisory. The research repository lists 8.2.35, 8.3.36, 8.4.27, and 8.5.12 as planned fixes, which are unconfirmed
  • Restart PHP-FPM and web server services so the running process uses the new version
  • Verify the running version on each host. Re-enable session.upload_progress only after confirming the fixed version, if the application needs it

PRIORITY 3 — Review Applications:

  • Review PHP applications for local file inclusion and unsafe deserialization, since some attack paths depend on these weaknesses
  • Isolate internet-facing applications where operationally feasible while patching is pending, and document the decision and its owner

PRIORITY 4 — Post-Patch Verification (24 to 72 Hours):

  • Review web server and PHP logs from the period before patching for unusual session-handling requests
  • Check whether PHP worker processes launched unexpected programs
  • Engage incident response support if indicators of exploitation are found

 

SUPPORTING DOCUMENTATION


RCE Remote Code Execution (RCE) vulnerabilities Remote Code Execution vulnerabilities Flash Notice Critical Vulnerability RCE Flaw Blog