On 21 October 2026, the PHP security team shipped patches for two critical remote code execution vulnerabilities, collectively dubbed PHP2Shell by the researcher who found the exploit chain, Kirill Firsov. Both flaws carry a CVSSv4.0 score of 9.2. Both are exploitable before any application code runs, with no authentication required.
If your server runs PHP to handle web requests — and it almost certainly does — patch now.
What is actually broken
CVE-2026-109618 — OOM Corruption
PHP can exhaust available memory while initialising request data structures. When that happens mid-way through initialisation, the internal state is only partially set up. PHP’s cleanup code does not check for this; it treats the half-built data as valid and proceeds. The result is memory corruption that an attacker can steer toward arbitrary code execution.
CVE-2026-109619 — Stale Global State
In worker-process models — PHP-FPM, mod_php under Apache — internal state from request N can outlive the freeing of its backing memory. Request N+1, handled by the same worker, may read or write through that stale pointer before PHP reinitialises it. This is a use-after-free, and it also enables memory disclosure alongside code execution.
Both vulnerabilities trace back to code paths present since PHP 5.4.0, meaning a very long tail of unpatched installations is reachable by anyone who bothers to look. The PHP Foundation confirmed the CVSSv4.0 score is 9.2; an earlier score of 10.0 that circulated before the release was incorrect.
Who is affected
Every PHP installation that serves web requests is at risk:
- mod_php (Apache module) — highest exposure; the exploit fires before any application code runs
- PHP-FPM — affected
- php-cgi — affected
- FrankenPHP — affected
- LiteSpeed — affected
PHP versions below 8.2, including the still-common 7.4, 8.0, and 8.1 branches, did not receive an official patched release from the PHP project. Minimal source backports were published for those branches, but they are end-of-life upstream.
Fixed versions
The PHP security team released the following patches on 21 October 2026:
| Branch | Fixed version |
|---|---|
| 8.5.x | 8.5.12 |
| 8.4.x | 8.4.27 |
| 8.3.x | 8.3.36 |
| 8.2.x | 8.2.35 |
Major distributions — Debian, Ubuntu, RHEL, AlmaLinux, CloudLinux — received patches before the public disclosure. Check your distribution’s security advisory channel; the update may already be waiting in your package queue.
Plesk users: two separate updates required
Plesk ships its own PHP packages and runs an internal PHP engine (sw-engine / plesk-engine) for the panel
itself. Both need separate updates, and updating one does not patch the other.
For the PHP versions visible in the PHP selector, update through the Plesk installer to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. For the panel’s own engine, update to Plesk Obsidian 18.0.81 Update 4 or 18.0.80 Update 11, as detailed in Plesk’s advisory.
PHP 5.6, 7.2, and 7.3 on Plesk have no fix from the project. Plesk points those users toward paid TuxCare Extended Lifecycle Support for those branches. If you are running any of them, the honest answer is: migrate off, not patch.
What this means for kalfaoglu.net customers
All shared hosting accounts at kalfaoglu.net run PHP through PHP-FPM. We have already updated the system PHP
packages to the patched versions. However, if your application explicitly pins a PHP version — via .user.ini,
.htaccess, or the Plesk PHP version selector — verify that the pinned version is one of the four fixed releases
listed above, not an older minor version within the same branch.
If you are running PHP 8.1 or below, treat this advisory as a prompt to plan a migration. These branches are end-of-life upstream, and PHP2Shell is not going to be the last critical vulnerability for which no upstream patch appears. If you need help testing your application against a newer PHP branch before migrating, open a support ticket.