What happened
PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619. On October 21, 2026, the PHP project shipped emergency releases, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, to fix two critical flaws that it says "can allow unauthenticated remote code execution" (PHP security advisory). The day before, PHP had given advance notice that both were rated CVSS v4.0 9.2. If you upgrade, also rotate any secrets a compromised host could have read; the Railway breach the same week shows why.
The two bugs, as PHP describes them:
- CVE-2026-109618, RCE via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat that invalid data as valid.
- CVE-2026-109619, RCE via stale global state. Request-owned internal state can outlive the memory behind it, and a later request on the same worker may use it before normal initialization resets it.
Two days later, on October 23, PHP published a short informational advisory about a separate issue, CVE-2026-115560. It is not fixed by the October 21 releases. PHP calls it "an unlikely RCE vector" and is handling it in the regular release cycle rather than with another emergency release.
Who is exposed
PHP's own answer for the October 21 flaws is broad: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." It considers the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs (advisory). In other words, a clean application does not protect you. The bug sits in the runtime.
PHP 8.1 and older no longer get updates from the project. PHP published minimal source backports for 7.4, 8.0 and 8.1 for people building from source, and says some distributions and LTS vendors ship backported fixes.
The October 23 issue is much narrower. According to PHP, it needs all of the following:
session.serialize_handler set to php_binary or php_serialize in configuration, application code that switches it to php at runtime with ini_set() before session_start(), and session upload progress still enabled. PHP has not said which versions are affected or when the fix ships.What attackers are doing
Everything in this section comes from The Hacker News, which attributes each claim to the vendor named. I have not verified these against the vendors' own posts.
THN reports that Amazon said its honeypots logged an exploit attempt against both CVEs on October 17, four days before disclosure. It reports Cloudflare saying attempts rose from tens of thousands within 45 minutes of the October 21 disclosure to millions by early October 22. It also reports that Sophos and Arctic Wolf saw attempts to install a Mirai botnet variant, and that Previdian, Wordfence and others report scanning and probing but no confirmed code execution so far.
Read that last point carefully. "No confirmed code execution" is a statement about what defenders have observed, not a guarantee. A pre-disclosure attempt also means someone had details early. Patch as if a working exploit exists.
The checklist
1. Find every PHP runtime you actually run
Check the CLI and the web runtime separately, because they are often different binaries:
For Apache with mod_php, check the loaded module version through your package manager or a
phpinfo() page served only to an admin. Remember containers, base images, CI runners and managed hosting.If you use distribution packages, the upstream version number may not change. PHP notes that Linux distributions and LTS vendors received the patches in advance (advisory). Check your vendor's security tracker for the package version that carries the fix for both CVEs, rather than looking for "8.4.27" in
php -v.2. Upgrade and restart
Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package. Then restart every FPM pool, Apache and any long-running worker. A package upgrade that leaves old workers running has not patched anything. Note that PHP 8.2 reaches end of life on December 31, 2026, per php.net, so plan that upgrade now.
3. Turn off session upload progress
Set this in
php.ini, the FPM pool or server configuration, then restart every worker:PHP lists this as a mitigation for CVE-2026-109619 and says it also covers CVE-2026-115560. PHP warns not to rely on
ini_set() or FPM .user.ini for it, because the setting must apply before request parsing. Upload progress is on by default, so check whether any feature of yours depends on it before switching it off.4. If you truly cannot patch today
PHP is explicit that only an update is a complete fix. Its stopgaps for the October 21 bugs include
memory_limit=-1 set in a way applications cannot override, a low post_max_size, request size and part limits at the web server or proxy, fatal_error_backtraces=0 on PHP 8.5, and container or cgroup limits as an availability boundary. It specifically warns against RLIMIT_AS and RLIMIT_DATA, which can cause the vulnerable allocation failure. Read the full list before applying any of these, since several trade availability for exposure.5. Use your WAF, but do not lean on it
If your WAF or CDN vendor has published managed rules for these CVEs, enable them. Treat them as noise reduction while you patch, not a substitute for patching.
6. Look for signs of a foothold
No indicators have been published that I can verify, so use standard post-exploitation checks on any host that was exposed and unpatched:
- New or modified
.phpfiles in upload, cache and temp directories, especially files written by the web server user. - New crontab entries for the web user or root, and new systemd timers or services.
- Unknown processes running as the web user, and outbound connections from PHP workers to hosts you do not recognize.
- Unexpected binaries in
/tmp,/var/tmpor/dev/shm, given the reported Mirai attempts.
If you find anything, isolate the host and rebuild from a known-good image rather than cleaning in place. The LiteLLM 1.107.0 incident response guide walks through rebuild and key rotation in more detail.
7. Keep watching
Alert on PHP worker crashes and out-of-memory events, since both bugs involve those paths. Watch request logs for spikes in large or malformed multipart requests, and track your vendor's advisory pages for updated package versions.
FAQ
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on October 21, 2026, fix CVE-2026-109618 and CVE-2026-109619. Distribution packages may carry the fix under a different version number, so check your vendor's tracker.
Does a secure application protect me?
No. The bugs sit in the PHP runtime, and PHP describes a mod_php exploit that triggers before any application code runs.
Do the October 21 releases fix CVE-2026-115560?
No. PHP is handling CVE-2026-115560 in its regular release cycle. Setting
session.upload_progress.enabled = 0 in server configuration is the listed mitigation.What comes next
PHP says it will publish a full advisory for CVE-2026-115560 with the next release (php.net). Another fix is already queued: PHP has flagged CVE-2026-115560 for its next routine release, so expect another patch round soon, and keep
session.upload_progress.enabled=0 in place until then.