On October 21, 2026, the PHP project issued an out-of-cycle security release for two critical vulnerabilities now being tracked under the shorthand "PHP2Shell." Both let an attacker execute arbitrary code on a server with no authentication at all, and both were already being exploited in the wild before most sites had a chance to patch. If you run PHP in production — directly, through a framework, or through a host you haven't checked lately — this is worth stopping for.
The two CVEs
| CVE | CVSS v4.0 | Root cause |
|---|---|---|
| CVE-2026-109618 | 9.2 | An out-of-memory condition during request parsing (reported in connection with multipart/form-data handling) can trigger a longjmp() that aborts processing mid-way, leaving request data partially initialized. Later cleanup code then operates on that invalid state. |
| CVE-2026-109619 | 9.2 | A PHP worker process can retain references to memory from a previous, already-freed request. A subsequent request handled by that same worker can then read or act on that stale, use-after-free state. |
Both land in PHP's core request-handling path rather than in a specific extension or framework, which is why the affected surface is so broad: every PHP application on an unpatched interpreter is exposed, regardless of what framework or CMS sits on top.
Who's affected
- Supported branches patched: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 — all released October 21, 2026.
- Unsupported branches (8.1 and earlier): no official PHP release. The PHP security team published minimal source-level backports, but you're on your own for building and applying them unless your distro or host does it for you.
- PHP 8.6 release candidates were not patched as part of this release.
- WordPress.org has said no WordPress-side update is planned — the PHP interpreter update is the fix, full stop.
- Some managed hosts (cPanel, CloudLinux, and various cloud platforms) have shipped their own backports to older branches, and some patch without bumping the visible version string — check the build date, not just the version number, if you're on a host.
Disabling things like session upload progress or tweaking memory limits reduces exposure to some exploitation paths but does not close either hole completely. Updating the PHP interpreter itself is the only full fix. Treat anything else as a stopgap, not a solution.
How to check and patch
- Check your running version: `php -v` on the server, or check the PHP version your host reports for each site/app.
- If you're below 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 on a supported branch, update immediately through your OS package manager, container base image, or host's control panel.
- If you're on PHP 7.4–8.1, plan an upgrade to a supported branch now — this release is a reminder that running an end-of-life PHP version means no official fix when (not if) the next critical flaw lands.
- If you can't patch immediately, isolate exposed endpoints behind a WAF rule as a temporary buffer, but don't treat that as resolved — schedule the real patch within hours, not weeks.
- After patching, rebuild and redeploy any containers or AMIs that bundle PHP, not just the live servers — a stale base image will quietly reintroduce the flaw on the next deploy.
Why this one matters more than the average PHP CVE
Unauthenticated RCE at CVSS 9.2 is already serious on its own, but three things make this release stand out: exploitation started before public disclosure in at least one reported case, the root cause sits in core request handling rather than an opt-in feature, and there's no clean mitigation short of upgrading. That combination — wide blast radius, active exploitation, no workaround — is why it's being treated as an emergency patch rather than routine maintenance.
The practical lesson for teams running PHP in production: know exactly which PHP version every app, container, and host is actually running today, and have a path to patch within hours rather than during the next scheduled maintenance window. A fast, boring patch pipeline is what turns a release like this into a non-event instead of an incident.
Not sure what PHP version your stack is actually running?
If you want a quick audit of your PHP version exposure across apps, containers, and hosts — or help getting a fast patch pipeline in place — happy to help.
Let's talk →