Two critical PHP vulnerabilities were disclosed on October 20, 2026, raising serious concerns worldwide for website owners and server administrators. Known as PHP2Shell, the issue involves two critical vulnerabilities that can allow attackers to execute code on affected web servers without logging in.
The PHP development team released security updates on October 21, 2026. The flaws affect PHP’s core engine, so the risk isn’t limited to a particular content management system or web application. Websites built on WordPress, Drupal, and Joomla may also be exposed if they use a vulnerable PHP installation.
The risk is critical for internet-facing servers, where attackers may exploit these flaws without authentication. Administrators should prioritize affected servers and apply the relevant security updates immediately.
What Is the PHP2Shell Vulnerability?
PHP2Shell refers to two critical remote code execution (RCE) vulnerabilities identified in PHP’s core engine:
- CVE-2026-109618: A memory corruption flaw associated with PHP’s handling of out-of-memory errors during request cleanup.
- CVE-2026-109619: A flaw involving outdated internal state that may be reused after memory has been released.
Both vulnerabilities have a reported CVSS v4.0 severity score of 9.2, placing them in the critical category.
PHP processes requests and manages memory while executing application code. Errors in this process can leave internal data in an invalid state. An attacker can exploit these conditions to disrupt memory handling and gain control of code execution.
Exploiting this vulnerability can let attackers take control of affected servers, steal confidential data, and deface the websites running on them.
In fact, cybersecurity agencies worldwide advised organizations to update immediately or take vulnerable systems offline.
How Does PHP2Shell Work?
PHP2Shell exploits weaknesses in how PHP handles memory during request processing and error recovery.
In one scenario, a specially crafted request can trigger an out-of-memory condition. PHP may then process internal data that was not fully initialized during cleanup. In the other scenario, PHP may retain references to memory that has already been released. If the same worker process handles a later request, it may reuse this outdated state.
Under vulnerable conditions, these memory-handling errors can give an attacker a path to remote code execution.
The attack is particularly concerning because it may take place before the application executes its normal code. This means application-level login protections may not prevent exploitation.
The vulnerabilities affect the PHP runtime itself. Updating WordPress plugins or strengthening application passwords will not fix a vulnerable PHP installation.
Which PHP Versions and Servers Are Affected?
The vulnerability affects PHP installations that handle web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The risk is particularly high for Apache with mod_php, as a demonstrated exploit shows that an unauthenticated request can trigger the vulnerability before the application code executes.
In short, all PHP installations that serve web requests are at risk (including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed).
A vulnerability scan can help uncover other known security flaws, outdated software, and server misconfigurations that may put your infrastructure at risk. Our Vulnerability scanning service helps identify security issues and prioritize them for remediation.
What Are the Risks of a Successful PHP2Shell Attack?
Successful remote code execution can let an attacker run unauthorized code within the compromised server environment. The actual impact depends on the PHP process’s permissions and the server’s configuration.
Potential consequences include:
- Unauthorized server access: An attacker can execute commands or modify files within the affected process’s permissions.
- Data exposure: An attacker can steal sensitive information accessible to the PHP process. Related memory-disclosure flaws can expose passwords, API keys, authentication tokens, or certificates.
- Website compromise: Attackers can alter website content, introduce malicious code, or use the compromised server as a starting point for further attacks.
A compromised web server can also put customer information and business operations at risk. Shared hosting environments may require additional investigation to determine the extent of exposure.
How to Protect Your Server From PHP2Shell
The PHP development team has released security updates for supported branches. Update immediately to fix both critical vulnerabilities. You can download the latest updates at this link.
| PHP Branch | Fixed Version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
These releases address CVE-2026-109618 and CVE-2026-109619. If you need help identifying PHP vulnerabilities across your server environment, Bobcares’ AI-powered security assessment service can help assess security risks and identify issues that require attention.
Unable to update PHP immediately?
If you can’t update PHP immediately, here are a few measures to reduce attack paths. However, they do not fully secure a vulnerable installation. Apply the official security updates as soon as possible.
Mitigations for CVE-2026-109618: RCE via Out-of-Memory Corruption
| Mitigation | Recommended Action | Important Note |
|---|---|---|
| Adjust the PHP memory limit | Set memory_limit=-1 through a configuration that applications cannot override, such as php_admin_value in the FPM pool or Apache configuration. Check for conflicting settings. | This removes the controllable PHP memory-limit failure path, but underlying allocation failures may still trigger the vulnerability. |
| Restrict request sizes | Set a low post_max_size. Use 8M if file uploads are unnecessary or 32M if they are required. Keep upload_max_filesize below post_max_size. | Enforce additional limits at the web server or proxy level for decoded request size, input fields, multipart parts, headers, and nesting depth. Ensure these controls also cover requests without a usable Content-Length. |
| Limit resource consumption | Use container or cgroup limits to constrain resource usage. Prefer a policy that terminates only the affected worker. | Avoid substituting RLIMIT_AS or RLIMIT_DATA, as these may trigger the vulnerable allocation-failure path. |
Need Help Handling PHP2Shell Vulnerability?
Mitigations for CVE-2026-109619: RCE via Stale Global State
| Mitigation | Recommended Action | Important Note |
|---|---|---|
| Disable session upload progress | Set session.upload_progress.enabled=0 in php.ini, an FPM pool, or server configuration that applies before request parsing. Restart all workers. | Do not rely on ini_set() or FPM .user.ini. This blocks confirmed session-related attack paths, but not every possible variant. |
| Disable fatal error backtraces on PHP 8.5 | Set fatal_error_backtraces=0 and restart all workers. | This blocks the confirmed fatal backtrace path only. |
| Review diagnostic settings | Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. | Hiding diagnostics through error_reporting, display_errors, or the @ operator does not address the underlying issue. |
| Address fatal errors and timeouts | Fix attacker-triggerable fatal errors and execution timeouts in callbacks, upload or import processing, and cleanup operations. | Review error-handling and cleanup paths that process untrusted input. |
These mitigations are temporary measures, not replacements for security updates. Review the official PHP advisory before applying configuration changes, and test them carefully to avoid disrupting legitimate application behavior.
PHP2Shell Security Checklist
Use this checklist to assess your PHP environment and reduce the risk of exploitation.
| Security Checklist |
|---|
| Audit PHP Installations |
| Check PHP versions and security status on all servers handling web requests. Include production and staging servers, containers, and PHP installations bundled with third-party software. Verify PHP versions and configurations for each website, including separate PHP-FPM pools. |
| Check for Signs of Exploitation |
| Review web server, PHP, and system logs for suspicious requests or unexpected errors. Examine activity from before and after the vulnerability disclosure, especially on unpatched servers. Investigate suspicious processes, modified files, and unexpected outbound connections. If you suspect a compromise, follow your incident response process and assess whether you need to replace credentials or other sensitive data. |
| Apply Temporary Protections |
| Use web application firewalls and network controls to help block known malicious requests. If an immediate update isn’t possible, review the official PHP advisory for temporary mitigation guidance. Treat temporary protections as an interim measure, not a replacement for security updates. |
| Apply Security Updates |
| Install the appropriate security update as soon as possible. Verify that every affected PHP installation has been patched. Recheck server security after updating and investigate any signs of prior exploitation. |
Conclusion
PHP2Shell highlights the risks that can arise from vulnerabilities in the software powering a website, even when the application itself has strong security controls. Bobcares helps businesses identify server vulnerabilities, apply security patches, and investigate signs of compromise. Our Cybersecurity services can help you assess your PHP environment and address security risks before they lead to serious incidents. If you manage multiple servers or rely on legacy PHP applications, expert assistance can help you identify affected systems and plan the necessary updates.
