PHP “php2shell” RCE (CVE-2026-109618/109619): what to do now
Incident response · 6-min read · Check your PHP version → · updated October 2026
Two critical, unauthenticated remote-code-execution flaws in PHP core — nicknamed php2shell (CVE-2026-109618 and CVE-2026-109619, both CVSSv4 9.2) — let an attacker run code on your server over plain HTTP, with no login. Millions of instances are exposed and exploitation is being reproduced. If you run PHP on the internet, this is a patch-today situation. Here’s the runbook.
The fix: update to your branch’s patched release
| Your PHP branch | Update to |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 7.4 / 8.0 / 8.1 (end-of-life) | No full fix — upgrade to a supported branch |
Paste your PHP version into the checker → to confirm whether the version you run is below the fix.
What to do — in order
Run php -v and check your server. CVE-2026-109618 hits Apache mod_php hardest; CVE-2026-109619 also affects PHP-FPM (via session handling when fatal_error_backtraces is enabled — the default on 8.5). If PHP is internet-facing and below the fixed version, treat it as exposed.
Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 depending on your branch. These are the versions that contain the fix — nothing earlier on that branch is safe.
Those branches get only limited source backports, not proper fixes — you must upgrade to a supported branch. Unsupported PHP is a standing risk well beyond this one bug.
The advisory lists stopgaps — set memory_limit=-1 administratively, disable session.upload_progress.enabled=0 in php.ini, and on 8.5 set fatal_error_backtraces=0. The maintainers call these INCOMPLETE — they reduce, not remove, the risk. Patch as soon as you can.
These are unauthenticated RCE in the web worker. If an internet-facing server ran a vulnerable version, review for web shells, unexpected processes/outbound connections and changed files; if you find signs of intrusion, rotate credentials and secrets and treat it as an incident.
memory_limit=-1, session.upload_progress.enabled=0, and on 8.5 fatal_error_backtraces=0) are described as incomplete. Use them only if you genuinely can’t patch this hour — then patch.Why this one is serious
- Unauthenticated — no account, no user interaction. An HTTP request is enough.
- In PHP core — below your application, framework or CMS. A patched WordPress/Laravel on a vulnerable PHP runtime is still exposed.
- Both mod_php and PHP-FPM are in scope, under default configuration.
- Huge exposure — millions of internet-facing instances, with exploitation being reproduced.
Turn this into action. Two critical, unauthenticated remote-code-execution flaws in PHP core (CVSS 9.2), with exploitation reported. The exact fixed versions, how to tell if you’re affected, interim mitigations, and the end-of-life trap — a patch-now runbook.
Check your PHP version — free →Frequently asked questions
What is php2shell (CVE-2026-109618 / CVE-2026-109619)?
Two critical vulnerabilities in PHP core, collectively nicknamed "php2shell". CVE-2026-109618 is a memory corruption during out-of-memory handling (worst on Apache mod_php); CVE-2026-109619 is a use-after-free involving state retained between requests (affects mod_php and PHP-FPM). Both are unauthenticated remote code execution with a CVSSv4 score of 9.2.
Which PHP versions fix it?
Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 for your branch. PHP 7.4, 8.0 and 8.1 are end-of-life and received only limited backports — upgrade to a supported branch instead.
Am I affected?
If you run a PHP version below the fixed release for your branch and the server processes HTTP requests (especially Apache mod_php, but PHP-FPM too), assume you are affected. No authentication is required to exploit it.
Is it being exploited?
Researchers have reproduced the flaws and a working exploit was developed during research; exploitation in the wild is reported/anticipated, and millions of instances are exposed. Treat it as an emergency and patch now rather than waiting.
Can I mitigate without patching?
Partially. The advisory suggests memory_limit=-1, session.upload_progress.enabled=0, and (on 8.5) fatal_error_backtraces=0 as stopgaps — but it explicitly calls them incomplete. They buy time; they are not a substitute for updating.
I run PHP in a container / behind a framework — does that help?
It does not remove the flaw: the bug is in PHP core itself, below your application code. A WAF may block some attempts but should not be relied on. Update the PHP runtime in your base image and redeploy.
This guide is vendor-neutral and informational, grounded in publicly-available guidance from bodies such as OWASP, NIST and CISA. IsItPatched is independent and not affiliated with them, and this is not legal or compliance advice. See our disclaimer.