PHP2Shell: Critical PHP flaws put millions of websites at risk

Executive Summary

On 20 October 2026, the existence of two critical PHP core vulnerabilities—CVE-2026-109618 (OOM/longjmp memory corruption) and CVE-2026-109619 (stale global-state use-after-free)—leaked publicly, prompting PHP maintainers to issue an emergency advisory. Both flaws carry a CVSS v4.0 score of 9.2 (Critical) and permit unauthenticated remote code execution on any internet-facing PHP server. Approximately 69% of websites run PHP, making the exposure surface extraordinarily broad. Government portals in the Netherlands, Denmark, Finland, and France, as well as Wikimedia services, 4Chan, and Something Awful, took services offline as a precaution.

Administrators must treat this as a drop-everything patch event. Apply the PHP 8.2+ emergency builds to every internet-facing and internal PHP host immediately. For PHP 7.4 / 8.0 / 8.1 deployments, compile the provided source patches and rebuild, or plan an urgent migration to a supported 8.x branch. Until patching is complete, place all PHP endpoints behind a WAF, restrict network exposure of PHP-FPM/Apache listeners to the minimum required, and run PHP worker processes under the least-privileged account. Cloudflare deployed temporary WAF rules as a stopgap; equivalent filtering at your own perimeter is strongly advised.

The One Source SOC is monitoring this disclosure and tracking vendor guidance, patch availability, and reported exploitation activity as the situation develops.

Vulnerability Advisory

Vulnerability Overview

OneWatch Score

Overall OneWatch Score: 8.5 / 10 (CRITICAL)

Root Cause Analysis

CVE-2026-109618 exploits PHP's use of longjmp() during out-of-memory handling, which can leave request memory in an uninitialized state that the cleanup path subsequently reads or branches on. CVE-2026-109619 exploits PHP global state that temporarily references request memory; when that state is not correctly reset (or is repopulated after reset), it dangles into freed memory that later requests read before full initialization.

CVE-2026-109618: PHP calls longjmp() to abort request handling on OOM. Certain execution contexts do not account for this non-local exit, leaving request-scoped memory uninitialized. The request-cleanup procedure then reads or branches on that uninitialized memory, and multiple OOM-triggering strategies can consistently steer the corrupted state toward code execution.

CVE-2026-109619: PHP global state (e.g., internal structures that temporarily point into per-request memory) is not always correctly reset between requests, or is repopulated after being reset. The stale pointer references memory that has already been freed. Subsequent requests read or branch on this dangling reference before it is fully re-initialized, enabling attacker-controlled data to influence control flow.

Both flaws reside in PHP core (not in a specific extension) and require no authentication, no user interaction, and no special configuration; the CVSS vector records AV:N / PR:N / UI:N with AC:H reflecting the complexity of reliably shaping heap state across requests.

Asset Impact Analysis

Public-Facing Assets CRITICAL RISK

• Broad Exposure: Approximately 69% of websites run PHP. Every internet-facing PHP application—CMS, e-commerce, API gateway, SaaS front-end—is in scope. Government portals (Overheid.nl, Danish school platform, Finnish government services, French local-administration sites), Wikimedia, 4Chan, and Something Awful went offline as a precaution.
• No Authentication Boundary: The CVSS vector is AV:N / PR:N / UI:N. An attacker needs only network reachability to the PHP endpoint; no credentials, session cookie, or user interaction are required.
• Operational Consequence: Successful exploitation yields code execution as the web-server user, enabling web-shell deployment, data exfiltration, defacement, and supply-chain compromise of hosted applications.

Internally Facing Assets HIGH RISK

• Internal Tools and Management Consoles: Internal PHP-based dashboards, CI/CD web UIs, monitoring panels, and ticketing systems are equally vulnerable. If reachable from a compromised workstation segment, they become a foothold.
• Lateral Movement: Code execution on a PHP host provides a pivot into adjacent internal networks, shared databases, file servers, and container orchestrators, amplifying blast radius well beyond the web tier.
• Patching Lag & Legacy Deployments: PHP 7.4 / 8.0 / 8.1 are end-of-life and receive source patches only—no vendor binaries. Organizations running these branches must compile and deploy custom builds or migrate to 8.2+, introducing a window of continued exposure.

Threat Landscape & Exploitation Outlook

• Exploitation State: Cloudflare reported signs of early exploitation prior to the public patch release and deployed temporary WAF rules as a stopgap. watchTowr's FAQ (21 Oct 2026) states that no confirmed in-the-wild exploitation had been observed at the time of its writing. PoCs, write-ups, and partial mitigations were circulating on the Internet before the embargo expired.
• Exploit Availability: Proof-of-concept material and exploit research (including a GitHub Gist) circulated publicly before the 21 October patch drop. A security firm (Sansec) expected mass attacks within 15 minutes of release. Administrators should assume weaponized exploits are available.

Mitigation Strategies

Apply the PHP emergency patches as the primary remediation; the steps below reduce exposure while patching is in progress.

Primary Remediation: Apply PHP Emergency Patches

Upgrade all PHP 8.2 / 8.3 / 8.4 / 8.5 installations to the 21 October 2026 security releases. For PHP 7.4 / 8.0 / 8.1, compile the published source patches and rebuild, or migrate to a supported 8.x branch.

1. Update the PHP packages via your distribution's package manager (apt, yum/dnf, apk, etc.) to the patched 8.2+ builds published on 21 October 2026.
2. Restart the PHP-FPM service (and any dependent web server) so the patched binary is loaded.

   sudo systemctl restart php*-fpm

3. Plan migration to PHP 8.2+ as soon as feasible.

Edge Reverse Proxy / WAF Filtering

Cloudflare deployed temporary WAF rules against PHP2Shell exploitation attempts. Mirror equivalent filtering at your perimeter until patching is complete.

• Enable your WAF's vendor-published PHP2Shell rule set (Cloudflare, ModSecurity/OWASP CRS, AWS WAF managed rules, etc.) on every PHP-facing virtual host.
• Restrict inbound traffic to PHP endpoints to the minimum required source ranges; block direct access to PHP-FPM sockets and to *.php paths on management subnets.
• Rate-limit POST and unusual-method requests to PHP endpoints to raise the cost of the high-complexity exploitation chain (AC:H).

Host-Level Confinement and Function Hardening

Reduce the post-exploitation blast radius by limiting what the PHP process can do even if code execution is achieved.

• Disable dangerous PHP functions that facilitate command execution, as recommended in CERT-EU and ACSC guidance:

  disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

• Run PHP-FPM workers under a dedicated, unprivileged user with no sudo, no interactive shell, and a restricted filesystem scope (open_basedir, AppArmor/SELinux profile).
• Set memory_limit and max_execution_time conservatively to reduce the attack surface for OOM-triggered exploitation paths.

Network Segmentation and Least Exposure

Limit the number of hosts an attacker can reach with a single network-accessible PHP endpoint.

• Place PHP application servers behind a reverse proxy (nginx, Apache, HAProxy, cloud ALB) so that only the proxy's IP reaches the PHP listener.
• Apply firewall rules so that PHP-FPM (default 127.0.0.1:9000) and Apache mod_php listeners accept connections only from the loopback interface or the designated proxy subnet.
• Segment PHP hosts from databases, file servers, and container runtimes; require mutual TLS and least-privilege service accounts for inter-service calls.

Detection and Incident Response

Detection should focus on anomalous PHP worker behaviour, unexpected outbound connections, and WAF/proxy logs showing exploitation-pattern requests.

Web Access Logs

• Alert on POST requests to PHP endpoints that return HTTP 500 with unusually large response bodies, repeated OOM-class errors, or requests with abnormal Content-Length / chunked-transfer patterns that could trigger the OOM code path.
• Correlate bursts of requests to the same PHP endpoint from a single source within a short window—consistent with the multi-request state-corruption technique described for CVE-2026-109619.
• Review WAF / reverse-proxy logs for Cloudflare PHP2Shell rule hits and any ModSecurity/CRS signatures targeting PHP2Shell; treat every hit as a potential exploitation attempt.

Process Execution Monitoring

• Monitor for child processes spawned by php-fpm, php-cgi, httpd, apache2, nginx, lighttpd, or litespeed workers. Legitimate PHP workloads rarely invoke:

  sh, bash, python, perl, nc, curl, wget, chmod, chown, base64, xxd,
  gcc, cc, ld, cat /etc/passwd, /dev/tcp

• Alert on any PHP worker writing to /tmp, /var/tmp, /dev/shm, the web root, or cron directories, and on new files with executable permissions in those paths.
• Track outbound network connections initiated by the PHP-FPM user; connections to non-allow-listed IPs, especially on high ports, are a strong post-exploitation signal.

Filesystem Integrity and Web-Shell Detection

• Run file-integrity monitoring (AIDE, Tripwire, osquery, Wazuh FIM) on web roots, PHP include paths, and php.ini locations; alert on any unexplained modification to .php files, .htaccess, php.ini, php-fpm.conf, or www.conf.
• Scan for newly created .php, .phtml, .phar, .shtml files, and files containing:

  eval(  base64_decode(  gzinflate(  assert(  preg_replace with /e
  create_function(  call_user_func(  system(  exec(  shell_exec(
  passthru(  popen(  proc_open(  pcntl_exec(  dl(  putenv(  ini_set(

• Check for unexpected modifications to disable_functions in php.ini and for new auto_prepend_file / auto_append_file directives that could act as a persistence mechanism.

PHP Runtime and OOM Anomaly Monitoring

• Enable PHP-FPM slowlog (request_slowlog_timeout) and monitor for repeated OOM warnings, Allowed memory size of … exhausted messages, and abnormal longjmp-related crash patterns in the PHP-FPM master log (/var/log/php*-fpm.log).
• Track PHP-FPM worker restart rates and child exited on signal events; a spike in worker crashes correlated with specific request patterns may indicate exploitation attempts targeting the OOM path.
• If using an eBPF-based runtime sensor (Falco, Tetragon, Tracee), create rules that detect mprotect, mmap with PROT_EXEC, and ptrace calls originating from the PHP-FPM process tree.

Vendor Statement

The PHP security team published an advance notice on October 20, 2026 and released an emergency security update on October 21, 2026 at 14:00 UTC — a day ahead of the original embargo — covering all supported branches. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The team is strongly urging all PHP users to update immediately, and has additionally published minimal source backports for the end-of-life 7.4, 8.0, and 8.1 branches for organizations that build from source or lack an LTS vendor. Linux distributions and LTS vendors received the patches before public release; administrators should check their distribution for updated packages.

https://www.php.net/archive/2026.php#2026-10-20-1

References

• PHP Security Advisory: php.net
• CVE-2026-109618 Record: cve.org
• CVE-2026-109618 NVD: nvd.nist.gov
• CVE-2026-109619 Record: cve.org
• CVE-2026-109619 NVD: nvd.nist.gov
• CISA Known Exploited Vulnerabilities Catalog: cisa.gov