PHP shipped emergency fixes for two unauthenticated remote code execution bugs
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical flaws that can let an outside request run code on a web server. Update now, and check your vendor if you use a distro package.
PHP’s security team released four patched versions on 21 October 2026. They fix two bugs that can let an unauthenticated visitor run code on a server. The team had warned about the release a day earlier.
The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. Researchers have started calling the pair PHP2Shell. Each one is rated 9.2 under CVSS v4.0.
What the two bugs do
- CVE-2026-109618, out-of-memory corruption. If a request runs out of memory at the wrong moment, PHP can leave half-built internal data behind and later treat it as valid. That corrupts memory, and the attacker can use the corruption to run code.
- CVE-2026-109619, stale global state. A fatal error at the wrong point can leave internal state pointing at memory from a previous request. A later request on the same worker can use that freed memory. The PHP Foundation’s post says the reporter got code execution on a real application running on Apache with mod_php.
Both bugs sit in code that almost every request touches, which is why they are serious.
Three outside groups found them: Calif, Wiz and OpenAI. BleepingComputer’s report credits all three. OpenAI’s part is the notable one, because an AI lab reported a flaw in a web language that most of the internet runs on. For PHP, the fix shipped on the same day as the advisory.
For another recent case of a developer tool going bad, see our LiteLLM 1.107.0 post.
Who is at risk
PHP’s advisory says all installations that serve web requests are exposed. That covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
The team rates mod_php as the highest risk. It has a demonstrated exploit where a request can trigger the attack before any of your application code runs. If you run PHP on Apache with mod_php, treat this as the most urgent item on your list.
Which versions are fixed
| Branch | Fixed version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 8.1 and older no longer get updates from the PHP project. The team did publish minimal source backports for 7.4, 8.0 and 8.1, for people who build PHP from source. If you use a Linux distribution or an LTS vendor, check with them, because they may have shipped backported packages.
If you can’t update right away
The advisory lists mitigations, but it is clear that none of them make a server safe. The main ones are:
- Set
memory_limit=-1in a way the application can’t override, and check that no pool or app setting puts a limit back. - Set a low
post_max_size. The advisory suggests 8M for apps that take no file uploads, and 32M if you need uploads. - Enforce request size and field-count limits at the web server or proxy, including for requests with no usable
Content-Length.
Treat these as a stopgap for the days until you can patch.
Update, 23 October
On 23 October the PHP team published a separate advisory for a third issue, CVE-2026-115560. It is not fixed by these releases, and the project is not shipping an emergency patch for it. The advisory’s recommendation is to set session.upload_progress.enabled=0 until the next regular bugfix release. The project says the setup needed to hit this is unusual. If you already applied the mitigation from the 21 October advisory, you don’t need to do more.
Why this is more than a PHP story
PHP runs a large share of the websites on the internet, including WordPress, Drupal and a lot of custom shop and blog code. Shared hosts and cPanel-style setups often update PHP on their own schedule. If your host hasn’t said anything about this release, ask them directly which PHP version they run.
The PHP Foundation’s post also makes a point about how these bugs were found. A PHP core developer working on a fix from the 2024 external audit noticed the first signs of the memory problem behind CVE-2026-109618. The team had theorised a possible exploit back then, but other, clearer issues took priority. That is a useful reminder that audits can flag a risk long before anyone builds a working exploit.
My take: The fix is simple: update to the fixed version for your branch today. The harder part is the gap between “the patch is out” and “every server running PHP has it.” That gap is where attackers operate, so the people who run shared hosting and old PHP installs should move first.
Sources
- PHP News Archive 2026, php.net advisory for 20, 21 and 23 October
- Today’s PHP Security Release, and How We’re Strengthening PHP Security, The PHP Foundation (21 Oct 2026)
- PHP ships emergency patches for critical PHP2Shell flaws, BleepingComputer (21 Oct 2026)
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618), PHP security advisory
- GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), PHP security advisory
Note on sources: I read the php.net advisory, The PHP Foundation post and the BleepingComputer article in full. The Google Cloud and Hacker News write-ups I only saw as search snippets, so I have not cited them for details. The exploit demonstration described for mod_php comes from the PHP team’s own advisory, and no independent lab has reproduced it in this post.