PHP2Shell: Two Critical PHP Flaws Allow Unauthenticated Remote Code Execution

Key findings

The PHP project released fixes on October 21, 2026, for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both carry a Common Vulnerability Scoring System (CVSS) v4.0 score of 9.2 (Critical Severity).
Both flaws are use-after-free conditions in the PHP runtime. An unauthenticated attacker can send crafted web requests that lead to remote code execution (RCE), allowing them to take over vulnerable servers
Any PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php carries the highest risk.
Technical details leaked on October 20, before patches were available, and public proof-of-concept code has been reported.
Symantec and Carbon Black products protect customers, and additional protections are in development. Our Protection Bulletin is updated as new protection information becomes available.

Overview

Two critical flaws in PHP, one of the most widely used technologies for building websites, can let an attacker take over a web server without a password or any other prior access. The attacker only has to send specially crafted web requests to the server. The PHP project released fixes on October 21, 2026, but details of the flaws had leaked a day earlier, so any organization that runs PHP should treat patching as urgent.

The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively known as PHP2Shell, sit in the PHP runtime itself and not in any one website or application. A fully up-to-date application can therefore still be exposed if the PHP runtime beneath it has not been patched. In the worst case, an attacker could run their own code on the server, read sensitive data held in its memory, or use it as a foothold to move deeper into a network. Both flaws score 9.2 out of 10 on the Common Vulnerability Scoring System (CVSS) v4.0 scale.

How the vulnerabilities work

When PHP aborts a request because of an out-of-memory or other fatal error, it can leave stale internal data behind. A later request handled by the same worker can then reuse that state after the underlying memory has been freed. Demonstrated outcomes include remote code execution, arbitrary file reads and memory disclosure.

CVE-2026-109618 arises when PHP exits a request on an out-of-memory condition while request memory is only partly initialized. Several multipart parsing behaviors can reach this state within normal PHP limits. CVE-2026-109619 arises when error, session, object or extension state survives the end of a request. The PHP project confirmed attack paths through session upload-progress handling and, on PHP 8.5, through fatal-error backtraces.

The primary goal of exploitation is likely to be server takeover, with RCE leading to a web shell and then persistence or pivoting into the wider network. Crashing the server is an easy fallback, and credential or memory theft is a quieter alternative. Harm to the visitors of an affected site would be a downstream effect of the server being compromised.

Why these flaws are so critical

PHP underpins a large share of the web. WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense and OPNsense are all written in PHP, and PHP code also appears in components of proprietary products and appliances. Because the vulnerabilities sit in the runtime rather than in any one application, every site and product that runs on an unpatched runtime is exposed regardless of how well the application is maintained.

Exploitation requires no authentication and no user interaction. On Apache with mod_php, the attack completes before any application code runs, so application logs may show nothing. This also means that a patched application on an unpatched runtime remains vulnerable. The German Federal Office for Information Security (BSI) made this point and stressed that the PHP runtime itself must be patched.

The age of the affected code adds to the problem. PHP 5.4.0 and later versions are affected, and every branch before PHP 8.2 is already end of life. The PHP project has published no upstream fix for PHP 8.1 and older. Organizations running those branches must rely on operating system vendor backports or migrate.

Exploitation status

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) said it had not observed exploitation as of publication, and the Canadian Centre for Cyber Security said a proof of concept was public with no active exploitation identified. The European Union's CERT-EU said technical details and proofs of concept were circulating, which raised the likelihood of exploitation, but did not confirm attacks. The BSI reported no confirmed exploitation but unconfirmed reports of existing exploits, and expected broad exploitation within hours of the patches because public details make exploit development fast. Each agency urged immediate patching.

Several security vendors have reported potential exploitation. Their honeypot and customer telemetry reportedly showed exploitation attempts, including at least one report of activity on October 17, before the public disclosure, and others reporting attacks at scale on October 21, with attackers adapting payloads to evade web application firewall (WAF) rules. Given the public details and proof-of-concept code, any internet-facing PHP server that remained unpatched after October 20 should be treated as potentially exposed.

Who is affected?

Any PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project assessed Apache with mod_php as the highest risk. Third-party products, appliances, containers and hosting platforms that embed PHP may also be affected. The Dutch National Cyber Security Centre (NCSC-NL) is maintaining a repository of affected third-party products.

Broadcom has said that no Broadcom Enterprise Security Group products have been confirmed affected.

Patching

Patching is the recommended remediation. The PHP project's fixed versions are:

PHP 8.5: upgrade to 8.5.12
PHP 8.4: upgrade to 8.4.27
PHP 8.3: upgrade to 8.3.36
PHP 8.2: upgrade to 8.2.35

Organizations should also take the following steps.

Restart after upgrading. Restart PHP-FPM pools and Apache so that no worker keeps running the old binary. PHP-FPM must be patched too.
Find every instance. Inventory internet-facing hosts first, then internal ones. Check the version the web server actually runs, for example, with php-fpm -v, or by checking the Apache module, and not only with the command-line php -v, since the two can differ.
Rebuild containers and check appliances. Rebuild images on patched base images, and check third-party appliances and hosting providers that embed PHP.
Handle unsupported branches. The PHP project published no upstream fix for PHP 8.1, 7.x and 5.x, although it has provided limited source backports for 7.4, 8.0 and 8.1. Check with your operating system vendor for backported packages. For example, Red Hat has published an advisory for PHP 7.4 (RHSA-2026:87080) and Fedora has issued updates. Where no backport exists, apply the interim mitigations below and plan an upgrade to a supported branch.

CISA recommended taking unpatched systems offline, and the BSI recommended considering disconnecting vulnerable servers from the internet, if patching cannot be done promptly. The CERT-EU advisory recommended isolating internet-facing applications until the fix is applied and verified.

Interim mitigations

If immediate patching is not possible, the PHP project's advisories list configuration changes that reduce exposure. These steps do not fully address either vulnerability, so they should be used only until the upgrade is complete, and each one should be tested first. The PHP advisories include further settings, such as limits on request size and structure for CVE-2026-109618.

Disable session upload-progress tracking by setting session.upload_progress.enabled = 0 in the active php.ini.
Disable OPcache by setting opcache.enable = 0. This removes the OPcache stale-cache technique, which gives arbitrary file reads. A noticeable performance cost is to be expected.
Check fatal-error backtraces. One technique requires them to be enabled, so turn them off if they are on and follow the PHP advisory for the exact setting.
Reload PHP. Restart PHP-FPM or Apache so the new settings take effect.
Put a WAF in front of the application. Several WAF vendors released virtual-patch rules covering the anomalous multipart and session traffic these exploits use. Confirm with your vendor that the rule is deployed and in blocking mode.
Reduce exposure. Restrict access to PHP applications that do not need to be public, and run PHP workers with least privilege so that a compromise exposes as few files, credentials and connected services as possible.

The BSI also recommended enabling SELinux or AppArmor where possible on Linux to limit the impact of any RCE vulnerability.

Protection

Symantec, Carbon Black and CBX protect against this threat. The Protection Bulletin lists every protection by name and is updated as new information becomes available, so it should be treated as the definitive reference. Additional product protections are in development.

Behavior-based protection

Symantec Endpoint behavioral protection (SONAR) includes 16 signatures covering suspicious behavior, suspicious process launches, registry and file writes, process starts and User Account Control (UAC) bypass attempts associated with PHP2Shell exploitation.

Carbon Black App Control

Carbon Black App Control customers can use four execution control rules to monitor, and later block, behavior potentially related to PHP2Shell exploitation. Every rule should start in Report mode. The rules should be updated with known indicators of compromise (IOCs) as they are published, and reported activity verified before any rule is switched to Block.

Linux PHP suspicious application execution: php-fpm, php-cgi, httpd or apache2 launching sh, bash, python, perl, curl, wget or nc.
Linux suspicious command lines: any process whose command line matches /dev/tcp/, fsockopen or mkfifo.
Windows PHP suspicious application execution: php-cgi.exe or php.exe launching cmd.exe, powershell.exe, certutil.exe or cscript.exe.
Windows suspicious command lines: nc.exe run with -e, or PowerShell command lines containing System.Net.Sockets.TcpClient or New-Object Net.WebClient.

Endpoint detection and response hunting

Hunting queries and watchlist queries are available for both Carbon Black Cloud and Carbon Black OnPrem. They look for the same behavior as the App Control rules: PHP and web server processes spawning shells, scripting interpreters or download tools on Linux, PHP processes spawning command interpreters on Windows, and the suspicious command lines listed above. Customers should hunt for this behavior on any PHP server that was unpatched after October 20.

File-based protection

Symantec file-based protection detects related tooling as Hacktool.Php2shell.

The full list of SONAR signature names, the complete App Control rule definitions and the exact Carbon Black query syntax are in the Protection Bulletin.