php2shell: Critical Unauthenticated RCE in PHP Core

php2shell is a pair of critical memory-safety vulnerabilities in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution and disclosure of process memory. PHP released fixes on October 21, 2026. Administrators should update PHP immediately. This is a critical vulnerability with the potential to disrupt many services across the globe.

Vulnerability Type (CWE)

CWE-755: Improper Handling of Exceptional Conditions
CWE-824: Access of Uninitialized Pointer
CWE-416: Use After Free
CWE-1325: Improperly Controlled Sequential Memory Allocation

CVSS Score

Base Score: 9.2

Attack Vector: Network

Attack Complexity: High

Privileges Required: None

User Interaction: None

Impact on CIA: Confidentiality: High, Integrity: High, Availability: High

Impacted Versions

Mitigation Steps

• Update PHP. This is the critical first step, patching the software below the PHP application.
• Restart every PHP process. Restart Apache, PHP-FPM, and any long-running PHP workers so the fixed code is loaded.
• Update the runtime, not just the application. Updating WordPress, Drupal, or plugins does not update the PHP runtime beneath them.
• Inventory all PHP runtimes. Include container images, hosting control panels, application-bundled PHP, and vendor appliances, and confirm the running version on each host.
• Rotate exposed secrets. Rotate credentials, API keys, and certificates the PHP application could reach if the server was exposed before patching.

Exploit Process

Send unauthenticated HTTP requests to any PHP endpoint

The attacker does not need application credentials; they target the PHP runtime itself (not app-specific logic).

Trigger a mid-request fatal condition (CVE-2026-109618)

The attacker forces PHP into an out-of-memory (OOM) or other fatal error while PHP is still building internal request structures.

Confirmed trigger paths include:

• Multipart parsing (named in PHP’s advisory)
• The PHP 8.5 fatal-error backtrace path
• Session upload progress handling after an OOM/fatal error

During cleanup, PHP can incorrectly treat partially-built request data as valid, leading to memory corruption.

Reuse freed request state across requests (CVE-2026-109619)

Some request-owned state can persist even after its memory is freed.

A follow-up request hitting the same worker can use that stale state before PHP fully resets it.

A confirmed exploitation path uses session upload progress tracking, which is enabled by default.

Shape the heap to control reclaimed memory

The attacker “grooms” the worker’s heap so attacker-controlled data is placed where freed structures used to live.

Early analysis suggests reliable code execution depends on:

• Build-specific memory offsets
• Winning a heap race / timing window

Achieve impact: code execution or memory disclosure

Successful exploitation can:

• Execute commands as the PHP worker user, or
• Disclose PHP worker memory (notably for CVE-2026-109619), potentially exposing secrets such as passwords, session tokens, API keys, and certificates from other requests—even without achieving RCE. 

Typical failure mode (operational symptom)

Failed attempts often crash the PHP worker.

Common external indicators:

• Behind a reverse proxy (e.g., nginx): bursts of 502 responses
• With mod_php and no proxy: connections may drop/reset
   

Timeline

Centripetal’s Perspective

php2shell differs from most web vulnerabilities because it sits beneath the application. A fully patched WordPress or Drupal site is still exposed if the PHP runtime under it has not been updated and restarted. Application-level patch tracking will not surface this risk.

The memory disclosure path of CVE-2026-109619 is a particular concern. An attacker can read credentials, session tokens, and keys from worker memory without executing code, which leaves little for host-based tools to detect.

As with wp2shell, the most reliable point of control is the network edge, where exploit traffic can be blocked before it reaches a vulnerable PHP worker. CDN and WAF rules only help if the origin server refuses traffic that bypasses them.

Update every PHP runtime to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, restart all PHP processes, and verify the running version directly on each host. Then address the harder question: was the server accessed before it was patched? Review web roots for new or modified PHP files, check for unexpected accounts and scheduled tasks, and rotate any credentials, API keys, and certificates the PHP application could reach. Finding no indicators reduces the likelihood of compromise, but it does not prove the system was never accessed.

php2shell lets anyone on the internet take over or quietly read secrets from a PHP server, regardless of the application running on it. Patches are out, a public exploit is out, and attacks started before either. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor’s backport), restart every PHP process, and confirm the running version. Retire or isolate anything on PHP 8.1 or older. Then hunt for signs of compromise and rotate secrets on any server that was exposed before it was patched. Perimeter controls and configuration changes buy time but do not replace the update.

If you are a current user of PHP and would like to assess your vulnerability status, please contact support@centripetal.ai.

Centripetal is also pleased to offer Penetration Testing and Vulnerability Assessment services to help organizations identify vulnerabilities and reduce risk. If interested, please contact our Professional Services team at profservs@centripetal.ai or reach out to your Centripetal Account Representative.

Resources

• PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
• https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/
• https://cvefeed.io/vuln/detail/CVE-2026-109618
• https://www.rescana.com/post/php-rce-flaws-patch-october-2026-prepare-now
• https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
• https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
• https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao