On October 21, 2026, the PHP project shipped an emergency security release fixing two critical remote code execution flaws in the PHP engine itself. Security researchers nicknamed the pair PHP2Shell. PHP powers roughly 69% of the websites whose server-side language can be identified, so a flaw in the runtime reaches WordPress sites, Laravel apps, Drupal and Joomla installs, custom backends and containers.
This guide covers what the vulnerabilities are, how they work, which versions are affected, what the exploitation picture looks like, and exactly how to patch, verify and harden your servers.
TL;DR: What You Need to Do Today
- Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your Linux distribution's patched package.
- Restart Apache and every PHP-FPM worker after updating. Old code keeps running until you do.
- Verify the fix through your package changelog or vendor advisory, not
php -v. - If you run PHP 8.1 or older, the PHP project has no official release for you. Get a vendor backport and plan an upgrade.
- If you cannot patch immediately, apply the temporary stopgap settings below. They reduce risk but are not a fix.
- Updating WordPress, Laravel or Composer packages does not fix this. The bug is in the PHP runtime.
Timeline of Events
| Date | Event |
|---|---|
| July 2, 2026 | PHP releases fixes for two lower-severity bugs, CVE-2026-12184 and CVE-2026-14355 (8.2.32, 8.3.32, 8.4.23, 8.5.8) |
| October 21, 2026 | PHP publishes fixed releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and a security advisory for CVE-2026-109618 and CVE-2026-109619 |
| October 21, 2026 | Palo Alto Networks publishes a threat brief and begins shipping network signatures. CISA's catalog released that day does not yet list either CVE as exploited. |
| October 22, 2026 | Official Docker php images for the fixed tags are available. Debian and Ubuntu publish patched packages. Red Hat rates the issue Important and is still preparing guidance. |
| October 23, 2026 | PHP publishes an additional informational advisory about session upload progress |
| October 25, 2026 | Unit 42 retracts an earlier claim that a real-world attack on a European government agency was confirmed exploitation of PHP2Shell |
What Is PHP2Shell?
PHP2Shell is the name for two memory-safety bugs in the PHP engine: CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code execution and are rated 9.2 (Critical) on CVSS 4.0. Red Hat scores CVE-2026-109618 lower, at 8.1 on CVSS 3, because its default PHP-FPM setup is harder to exploit.
The flaws sit below your application code. It does not matter whether you run WordPress, Laravel, Symfony, Drupal, Joomla or a hand-written site. If the PHP runtime serving requests is unpatched, it is exposed.
Technical Breakdown
Both bugs share a pattern: a failed request leaves PHP's internal state in a corrupted condition, and the next request handled by the same worker trips over it.
CVE-2026-109618: Out-of-Memory Corruption
When PHP runs out of memory, it aborts the request using longjmp(). If that happens while request memory is only partly initialized, the shutdown code later treats that memory as valid. An attacker can deliberately trigger the out-of-memory condition, for example with a crafted multipart upload where one part carries an unbounded number of headers, and turn the result into reliable code execution.
CVE-2026-109619: Stale Global State
The same longjmp() style of fatal-error handling can leave global memory pointing at freed regions. Examples include a fatal-error backtrace on PHP 8.5 and session upload-progress data. A later request reads or branches on that freed memory, which is a use-after-free that can lead to arbitrary code execution. One public write-up describes the root cause as a skipped request-shutdown step that lets pointers survive into the next request.
Why the Attack Crosses Requests
This is what makes PHP2Shell unusual. The attacker's malicious request does not need to carry the final payload on its own. It poisons the worker, and a following request does the damage. That also means a clean log is not proof of safety: the advisory warns the trigger can fire before PHP writes any error message.
Which PHP Versions Are Affected?
| Branch | Vulnerable | Fixed in | Support status |
|---|---|---|---|
| 8.6 (pre-release) | RC1 to RC3 | 8.6.0 RC4 | Pre-release |
| 8.5 | 8.5.0 to 8.5.11 | 8.5.12 | Active |
| 8.4 | 8.4.0 to 8.4.26 | 8.4.27 | Active |
| 8.3 | 8.3.0 to 8.3.35 | 8.3.36 | Security only |
| 8.2 | 8.2.0 to 8.2.34 | 8.2.35 | Security only, ends Dec 31, 2026 |
| 8.1 and older (including 7.x and 5.x) | All versions | No official release | End of life |
PHP's own advisories list only branches 8.2 to 8.5 as affected, but the NVD range for CVE-2026-109619 starts at PHP 5.4.0, and several researchers say older branches are vulnerable too. The safe assumption is that every branch is affected. PHP published minimal source-level backports for 7.4, 8.0 and 8.1, and vendors such as Ubuntu Pro cover older packages, but a supported branch is the durable answer.
Older PHP is still very common. W3Techs reported on October 22, 2026 that about 34.6% of identifiable PHP sites still run PHP 7 or 5.
Are You Exposed? It Depends on Your Setup
| Server setup | What the advisories say |
|---|---|
| Apache with mod_php | Most exposed. The out-of-memory path fires during request startup, before any application code runs, and full code execution is reported with default settings. |
| PHP-FPM (nginx or Apache) | FPM kills a child whose startup fails, which blocks that exact sequence. The PHP Foundation still confirmed code execution through application-level code paths. Not a mitigation. |
| FrankenPHP | Reported as likely susceptible to application-independent attacks. Static binaries bundle their own PHP, so update the binary. |
| php-cgi | In scope per php.net. No server-specific analysis published. |
| Docker official php images | Affected until you pull and rebuild from a fixed tag. |
Note that a plain apt install php on Ubuntu installs Apache with mod_php, the configuration the advisory rates as most exposed.
Is It Being Exploited?
The honest answer is that reports conflict, so treat it as urgent.
- Proof of concept exists. Wiz Research built a full exploit chain, which it calls php2shell, and demonstrated unauthenticated code execution against the official WordPress, Drupal and Joomla container images. Public exploit repositories also exist.
- AI-assisted research. Wiz says the chain was built with the help of AI models, and that one researcher finished in about a week what would previously have taken a team months. This shortens the gap between disclosure and working attacks for every future bug of this kind.
- CISA KEV. As of the catalog released October 21, 2026, neither CVE was listed as known exploited.
- Unit 42 retraction. Palo Alto first linked a post-compromise attack on a European government agency to these bugs, then retracted that on October 25 because it could not confirm the initial access came from the PHP2Shell CVEs.
The bug is also not new. The PHP Foundation says a core developer found early signs of it in 2024 while fixing a security audit finding, and that the fix then stalled for months, which it called a structural failure. Attackers can often find old bugs the same way, so assume anyone motivated can