PHP2Shell: what CVE-2026-109618 and CVE-2026-109619 mean and how to respond

On October 21, 2026, the PHP project released emergency updates for two critical vulnerabilities in PHP itself, not in a specific application or CMS. Tracked as CVE-2026-109618 and CVE-2026-109619, and nicknamed PHP2Shell, they can let an attacker run code on a web server without logging in. Because PHP powers a large share of the web, from WordPress sites to internal tools, the potential reach is enormous: Palo Alto Networks reported more than 22.6 million internet-facing instances that are potentially vulnerable.

This article explains what the flaws are, who is affected, what to do first, and how to look for signs that someone already tried. The situation is still developing; the facts below were checked against the official advisories on October 23, 2026, and we will update this article as the picture changes.

What happened

Both vulnerabilities are remote code execution flaws in the PHP engine, rated 9.2 (critical) on CVSS version 4.0 by the PHP project. They come from the same root cause: when PHP hits certain errors, such as running out of memory, it can leave internal memory in a broken state, and a later step in the request, or a later request, trusts that memory.

• CVE-2026-109618, "RCE via OOM corruption": an out-of-memory error in the middle of request processing leaves request data half-initialized, and the cleanup that follows treats that invalid data as valid. Crafted multipart requests, the kind used for file uploads, can trigger the memory error within normal PHP limits.
• CVE-2026-109619, "RCE via stale global state": after a fatal error, some internal state keeps pointing to memory that has already been freed, a classic use-after-free. A later request handled by the same worker process can use that stale state. Besides code execution, the advisory confirms this one can disclose memory from the server.

In both cases the code runs with the permissions of the web server's account. The details are in the official GitHub advisories: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.

A disclosure that did not go to plan

The release was meant to be coordinated, but according to several security vendors, details of the flaws circulated publicly on October 20, the day before the patches came out. PHP had announced the security release on October 20 and published it on October 21 as scheduled. Proof-of-concept exploit code is now public.

Are you affected?

The PHP advisory says all PHP installations that serve web requests are at risk, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The risk differs by setup:

• Apache with mod_php is the most exposed. Code execution was confirmed with default settings, using a single unauthenticated request that triggers the problem before any application code runs.
• PHP-FPM is considered susceptible. A working attack against the second flaw was validated in a normal FPM setup, and the first is susceptible by source analysis.
• FrankenPHP and LiteSpeed are likely susceptible according to the advisories, though no complete exploit has been confirmed for them in default configurations.

Command-line PHP scripts that do not serve web traffic are not the main concern.

Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older in those branches is vulnerable. For PHP 8.1, 8.0 and 7.4, which no longer receive official releases, the PHP team published minimal source patches only; in practice, fixes for those versions come from your Linux distribution or an extended support vendor.

Also make sure you check the PHP that actually serves your websites. Running php -v shows the command-line version, which can differ from the version used by PHP-FPM or the Apache module on the same server.

What to do first

1. Find every PHP web server

   List the servers, containers and hosting accounts that run PHP and serve web traffic, starting with those reachable from the internet. Do not forget forgotten ones: old marketing sites, test environments and internal tools.

2. Patch

   Update to a fixed PHP release or to your distribution's patched package, then restart all PHP workers (PHP-FPM, Apache, LiteSpeed). PHP's advisory is blunt: updating is the only complete fix. If you use managed hosting or a platform service, check your provider's status page.

3. Mitigate what you cannot patch today

   For servers that cannot be updated immediately, the advisories list partial measures. They reduce the risk but, in PHP's words, do not make an installation safe:

   • Disable session upload progress with session.upload_progress.enabled = 0 in the main configuration (not with ini_set() or .user.ini), then restart the workers.
   • On PHP 8.5, also set fatal_error_backtraces = 0.
   • Limit request size, the number of form fields and the number of multipart parts at the web server or reverse proxy, and block multipart requests on sites that do not accept uploads.
   • Put the most exposed sites behind a web application firewall that has rules for these CVEs. Several vendors have released them.

4. Look for signs of exploitation

   Because exploit code was public before many servers were patched, check the servers that were exposed before you patched them. The next section covers what to look for.

On October 23, PHP also published an informational advisory about a third, much narrower issue, CVE-2026-115560, which needs an unusual combination of configuration and application code. Disabling session upload progress, as above, covers it as well.

Is it being exploited?

Reports were still conflicting when we checked:

• Sophos reported scanning and a small number of exploitation attempts on October 22. It initially described one successful compromise, then corrected that the same day: the attempts had failed and there was no evidence of a successful compromise.
• Palo Alto Networks Unit 42 reported an attack on a European government organization in which, within two hours of exploitation, the attacker reached password hashes and tried to escalate to domain administrator.
• CISA's Known Exploited Vulnerabilities catalog did not list either CVE in its October 23 version. Check the catalog for updates.

Treat the flaws as likely to be exploited at scale soon, whatever the current count.

How to look for signs of attack

A successful exploit makes the PHP process do something it never does in normal operation. Security vendors including Huntress, Sophos and Unit 42 recommend looking for:

• The web server starting a shell or a download tool: php-fpm, php-cgi, apache2, httpd or lsphp as the parent of sh, bash, curl, wget, python, perl or nc on Linux, or of cmd.exe and powershell.exe on Windows.
• Reconnaissance commands run by the web server account, such as whoami, id, uname -a or cat /etc/passwd, run by www-data, apache or nginx.
• New executables in temporary folders such as /tmp, /var/tmp or /dev/shm, especially followed by chmod +x.
• Persistence: new cron jobs, new SSH keys in authorized_keys, new local accounts, and new or modified files in the web root, which may be web shells.
• Unusual requests in web server logs: bursts of large or malformed multipart POST requests, often from scanning infrastructure. Sophos published indicators from the activity it saw, including the scanner User-Agent php2shell-scan/109618. Indicators like these change quickly, so use them as a starting point, not as proof of safety.

If your servers run Microsoft Defender for Endpoint, this advanced hunting query looks for the first pattern on Linux:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "php-fpm"
    or InitiatingProcessFileName in~ ("php-cgi", "apache2", "httpd", "lsphp", "frankenphp")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "python3", "perl", "nc")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

Some legitimate applications do run shell commands, so review the results rather than alerting on every hit. If you find a real sign of compromise, isolate the server, preserve the web server and PHP logs, and treat it as an incident: patching alone does not remove an attacker who is already in.

Why it matters for a SOC analyst

PHP2Shell is a reminder that the most serious vulnerabilities are sometimes in the platform everything else runs on, not in the application your team watches. It also shows how quickly the timeline compresses when details leak: patch, scan and exploit code all appeared within days. Knowing where PHP runs in your environment, how it is packaged and what normal behavior looks like for its processes is what lets you answer the two questions that matter: are we patched, and were we hit first? Good patch management answers the first; process and log monitoring answer the second.