PHP2Shell Vulnerabilities: RCE Risks, Affected Versions, and Patches

PHP2Shell Puts More Than Websites at Risk

Two critical PHP2Shell vulnerabilities have put millions of web servers and applications at risk of remote code execution (RCE).

The vulnerabilities affect PHP's core interpreter, which means updating applications like WordPress won't fix the underlying problem. In the months leading up to the October 21, 2026 disclosure, Bitsight observed approximately 29.2 million internet-facing PHP hosts, 18.4 million of which advertised vulnerable versions.

For CISOs and infrastructure managers, the priority is identifying exposed systems, applying the appropriate patches, and investigating signs of compromise. Successful exploitation has been confirmed, although the difficulty varies by deployment and configuration. Beyond patching, controlling privileged access can help limit how far attackers move if a server is compromised.

What Are the Risks of PHP2Shell?

To effectively communicate enterprise exposure to executive leadership, security teams must translate these low-level memory bugs into four core business risk domains:

• Remote Code Execution and Potential Server Compromise: Unauthenticated remote code execution (RCE) can allow attackers to execute commands under the PHP or web service account. Full administrative control may require additional privilege escalation.
  
• Application Credential Theft and Sensitive Data Exposure: Successful exploitation may expose credentials, tokens, and other sensitive information held in process memory. Attackers who achieve RCE may also access application configuration files containing hardcoded database connection strings, cloud API keys, and other credentials. Further access depends on the permissions and credentials available to the compromised process.
  
• Unauthorized Website Modification: Attackers gaining execution privileges can modify site source code, tamper with public-facing content, plant web shells, or use legitimate web properties to distribute malware.
  
• Lateral Movement into Internal Networks: A compromised web server may provide a foothold for LDAP queries, Active Directory (AD) enumeration, and attacks against other systems, depending on network access and permissions.

How Do the PHP2Shell Vulnerabilities Work?

Unlike application-layer vulnerabilities such as SQL injection or cross-site scripting, flaws within the PHP interpreter itself may not appear in application-code audits. The PHP2Shell alert concerns two bugs in PHP's memory management and fatal error handling routines:

• CVE-2026-109618 (Out-of-Memory Handling Flaw): Improper handling of an out-of-memory (OOM) condition during HTTP request parsing can leave request memory in an unsafe state. Crafted form-field names can trigger allocation failures at sensitive points in PHP's processing.}
  
• CVE-2026-109619 (Use-After-Free Flaw): During error handling, PHP can leave global pointers referencing freed memory. Later operations may access those dangling pointers, potentially enabling memory corruption and arbitrary code execution.

Both flaws involve error-handling control flow, including longjmp(). Exploitation may require carefully sized requests and techniques to overcome memory protections such as Address Space Layout Randomization (ASLR). Unit 42's technical analysis describes the underlying mechanisms.

These vulnerabilities require no prior authentication or user interaction. An attacker can send crafted HTTP requests to an affected PHP service, with any resulting commands running under the PHP or web-server worker's permissions. Practical exploitability depends on the PHP build, deployment method, process memory limits, and operating system.

Related PHP Vulnerability: CVE-2026-115560

The PHP project also described a separate, configuration-dependent session-handling issue, not addressed by the October 21 emergency releases. It arises when an application switches session.serialize_handler from php_binary or php_serialize to php at runtime, then calls session_start() with session upload progress enabled.

PHP advised setting session.upload_progress.enabled=0 in affected configurations pending a fix. The original PHP2Shell patches do not resolve this separate vulnerability.

How AI Helped Uncover PHP2Shell

The discovery of PHP2Shell highlights how artificial intelligence (AI) is changing vulnerability research. Complex memory corruption bugs had remained in the PHP codebase for more than a decade. Researchers used AI-assisted analysis to help uncover and investigate them, shortening the time needed to find flaws buried in legacy code.

“The combination of human expertise and AI-powered automation has fundamentally changed the speed of cyberattacks. Vulnerabilities that once took weeks to exploit can now be weaponized in hours. Organizations can no longer afford to treat patching as a routine maintenance cycle. 

The window between vulnerability disclosure and exploitation is rapidly closing, making immediate risk assessment, prioritization, and patching a business-critical necessity.” - Joseph Carson, Chief Security Evangelist & Advisory CISO, Segura™

The PHP2Shell flaws were uncovered through collaborative and independent work involving Wiz Research, Calif, OpenAI, and other researchers. Ryan Austin contributed research at Calif, while Wiz Research reports using AI tools from OpenAI and Google during discovery and exploit development.

AI-assisted research may accelerate defensive fixes and exploit development. Finding a flaw, producing a working exploit, and reliably compromising different real-world systems still require separate work.

Is PHP2Shell Being Exploited in the Wild?

Following public disclosure, researchers observed a sharp increase in probing and exploitation attempts. Cloudflare reported malicious requests even before the public announcement, with activity increasing rapidly afterward. On October 26, 2026, CISA added both CVEs to its Known Exploited Vulnerabilities catalog.

• Confirmed Remote Code Execution: Security researcher Adel Karimi documented successful command execution against PHP honeypots, including attempts to retrieve additional payloads. Wiz Research examined these captures and noted that the honeypots used a configuration favorable to exploitation. Successful exploitation may be more difficult in other environments.
  
• Confirmed Appliance Exploitation: In an October 29 update, Unit 42 confirmed exploitation of internet-exposed PAN-OS management interfaces, including a chain of PHP2Shell with a Linux kernel privilege-escalation vulnerability to obtain root access.
  
• Supply Chain and Infrastructure Exposure: PHP vulnerability assessments must extend beyond standard web applications. The NCSC-NL PHP2Shell affected-products tracker helps organizations identify potentially affected vendor-managed systems, including network appliances, load balancers, and hardware edge devices that embed PHP.

Affected PHP Versions and Available Patches

Because PHP is deployed through standalone binaries, container images, custom builds, and operating system packages, teams must verify the PHP runtime actually in use. The PHP project released fixes for supported branches on October 21, 2026.

Verifying PHP Patches and Vendor Backports

Updating higher-level applications or content management systems, such as WordPress core, themes, or plugins, does not fix a vulnerable PHP interpreter.

For environments managed by Linux distributions (e.g., Red Hat, Ubuntu, Debian) or cloud providers, verify that installed packages contain the fixes for CVE-2026-109618 and CVE-2026-109619. Some vendors offer patched builds of unsupported PHP branches, as demonstrated by Plesk's PHP2Shell security advisory. A version string alone may not reveal whether a vendor backport is installed.

PHP2Shell Response Checklist: 10 Steps for Security Teams

To ensure comprehensive coverage during emergency patching, engineering and security operations teams should follow these ten steps. Several can be carried out in parallel, particularly during an active incident. If compromise is suspected, containment should begin immediately rather than waiting for patching or inventory work to finish.

1. Comprehensive Asset Inventory: Scan and catalog PHP runtimes across production, staging, development, containers, virtual machines, and network management appliances.
2. Prioritize Internet-Facing Runtimes: Start with edge web servers, customer portals, API endpoints, and external administrative interfaces.
3. Deploy Official Runtime Upgrades: Update affected PHP binaries to patched releases. Restart or reload the relevant PHP and web-server services, then verify that active workers are running the patched build.
4. Verify OS/Vendor Packages: For distribution-managed PHP, check the vendor's security advisories and package build numbers for backported fixes.
5. Accelerate EOL Software Migration: Isolate or migrate unsupported PHP installations, prioritizing those with internet exposure. Check for vendor-maintained fixes where migration cannot happen immediately.
6. Check for PHP2Shell Exploitation Indicators.: Review Apache, Nginx, and PHP logs for correlated HTTP POST requests returning 500 errors, PHP memory-exhaustion messages, and worker crashes. ReliaQuest's lab testing described such a sequence. These are potential indicators; their absence does not rule out exploitation.
7. Execute Targeted Threat Hunting: Look for new PHP files in web roots, unexpected child processes or outbound connections from www-data or apache, unauthorized account changes, and suspicious scheduled tasks.
8. Secret and Credential Rotation: Identify secrets accessible to vulnerable PHP processes. If compromise is confirmed or reasonably suspected, prioritize rotation of potentially exposed credentials with incident response and application owners.
9. Apply Compensating Network Controls: Use WAF rules and network restrictions where supported. These are temporary controls and do not replace runtime patching. Consider taking high-risk, unpatchable systems offline until they can be secured.
10. Rebuild Compromised Hosts: If exploitation is identified, isolate affected hosts, preserve forensic artifacts, assess the scope, and rebuild from trusted images when indicated by incident response findings.

Patching the PHP runtime closes the known exploit path, but security teams must also investigate potential compromise and limit the access available from affected servers.

How PAM Helps Limit Damage After PHP2Shell Exploitation

If an attacker achieves RCE through an unpatched web runtime, the web server may become an initial foothold for lateral movement. Privileged Access Management (PAM), operating-system restrictions, and identity governance can limit what attackers reach from that foothold.

“A vulnerable web application should never become a gateway to an organization's entire infrastructure. When applications run with excessive privileges or have access to powerful credentials, a single compromise can quickly escalate into a much larger security incident. 

Segregation of privileges, strong identity controls, and the principle of least privilege are more critical than ever. Web applications should operate with only the permissions they absolutely need, and their credentials must never provide attackers with a pathway to move laterally or escalate privileges deeper into the environment. 

The goal is simple: even when an application is compromised, the attacker's access and ability to cause damage must remain limited.” - Joseph Carson, Chief Security Evangelist & Advisory CISO, Segura™

Privileged Access Controls to Limit Lateral Movement

• Dynamic Credential Vaulting: Reduce reliance on long-lived database credentials, service keys, and administrative passwords stored in configuration files such as wp-config.php or .env. Centralized secrets management and short-lived credentials can reduce exposure and limit the duration of unauthorized access. An attacker with RCE may still misuse credentials or connections available to the application.
  
• Session Monitoring and Least Privilege: Enforce the principle of least privilege for service accounts executing web runtimes. Use operating-system hardening, network restrictions, and identity permissions to limit unnecessary administrative access. Require multi-factor authentication (MFA) for privileged user access where supported. PAM session monitoring provides oversight of managed privileged sessions, but does not itself restrict everything a PHP worker can do.
  
• Emergency Access Governance: Establish isolated, audited break-glass workflows so security teams can access and remediate compromised hosts without sharing static root credentials.
  
• Platform Recommendation: Organizations evaluating post-RCE containment can consider Segura™ PAM alongside operating-system, network, and application controls. Segura™ provides privileged credential management and session monitoring capabilities that support least-privilege access strategies. Specific application-to-vault integrations and service-identity controls should be validated against deployment requirements.

PHP2Shell Frequently Asked Questions 

Can a Web Application Firewall (WAF) replace patching?

No. A WAF or virtual patch can help filter known malicious requests, but it doesn't fix the underlying vulnerability in PHP's interpreter. Patching the PHP runtime remains necessary.

What if an organization runs PHP 7.x or older?

PHP 7.x and 5.x releases are End-of-Life (EOL) and do not receive regular upstream security updates. Source-level fixes were made available for PHP 7.4, 8.0, and 8.1, and some vendors, including Plesk, offer backported packages.

Security teams should verify vendor-provided fixes, restrict access to unsupported systems, and plan migration to a supported PHP branch. Unpatchable systems may need to be taken offline.

Does PHP2Shell affect WordPress and other PHP applications?

Yes. Applications such as WordPress, Drupal, Symfony, and Laravel may be exposed when running on vulnerable PHP installations. Practical exploitability depends on the deployment and configuration.

Updating WordPress or other application software alone won't fix a vulnerable PHP runtime.

Keep Privileged Access Under Control

When an attacker compromises a web server, the credentials and permissions available to that server can determine how far they get.

Segura™ helps organizations control privileged access, manage credentials, and monitor privileged sessions across their environments.