On October 21, 2026, the PHP project shipped an out-of-cycle fix for two critical,
unauthenticated remote code execution vulnerabilities, tracked as CVE-2026-109618 and
CVE-2026-109619 and rated 9.2 on the CVSS v4.0 scale. The researchers who found them nicknamed
the pair “PHP2Shell.” The fixed versions, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, became available
on October 22.
Two unauthenticated flaws, already under attack
Both vulnerabilities affect how exposed PHP installations process incoming requests, with
no authentication required. Cloudflare and security firm watchTowr report active exploitation
attempts within hours of disclosure, prompting the US CISA to publish an alert on October 21
urging immediate updates. One vendor estimates nearly two million PHP servers remain
potentially exposed.
No configuration workaround
The PHP project states that no configuration setting fully neutralizes either flaw: a
binary update is the only complete protection. PHP-FPM workers or the application server must
be restarted after installing the patch, or the old vulnerable code keeps running in memory.
| Branch | Fixed version | Patch status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Active branch, full fix |
| PHP 8.4 | 8.4.27 | Active branch, full fix |
| PHP 8.3 | 8.3.36 | Security-only branch, full fix |
| PHP 8.2 | 8.2.35 | Security-only branch, full fix |
| PHP 8.1 and earlier | No official release | End of life, source patches available from some vendors |
Updating a production server
On a Debian or Ubuntu box using the official PHP repositories, the fix boils down to a
package upgrade followed by a service restart:
php -v
sudo apt update
sudo apt install --only-upgrade php8.4 php8.4-fpm
sudo systemctl restart php8.4-fpm nginx
Shared hosts and panels such as Plesk have shipped their own patched builds; teams running a
self-hosted server
should confirm the version reported by php -v before calling the incident closed,
including on instances where PHP quietly runs behind a CMS.
No configuration workaround fully neutralizes either flaw: only a binary update, followed by a restart of the PHP processes, closes the exposure window.
A familiar pattern from the WordPress ecosystem
The speed of exploitation echoes a pattern already covered on this site: a
critical WordPress flaw under active attack five days after its patch.
Sites whose PHP foundation isn’t hardened remain the first targets once an exploit goes
public, regardless of which CMS sits on top; the basics of a
minimal WordPress hardening baseline
reduce the attack surface but don’t replace updating the interpreter itself.
Sites still running on them stay exposed until they migrate to a maintained branch.
Key takeaways
Two critical vulnerabilities, exploitable without authentication and already under active
attack, affect every maintained PHP branch. The fix requires updating to 8.5.12, 8.4.27, 8.3.36
or 8.2.35 depending on the branch in use, followed by a restart of the PHP processes. Versions
before 8.2, now end of life, have no official patch and should be treated as a priority
migration target.
On the engagements where I manage the infrastructure, this kind of out-of-cycle alert is
one of the rare cases where I pull the day’s deployment queue to apply the patch before
anything else. The pattern of lightning-fast exploitation on WordPress over the past few
months shows the gap between disclosure and automated attack is now measured in hours, not
days. A simple cron job checking the PHP version, paired with an alert, costs far less than a
compromised server on a Sunday night. — Simon Janvier
Further reading: the official PHP 8.x changelog.
