The fix for PHP2Shell is out, and for most of the websites that need it, there is no button to press. The flaws live in PHP itself, the engine that runs every WordPress, Joomla and Drupal page, below the CMS, its plugins and its login screen. Updating WordPress does nothing to them. The patched interpreter has to come from whoever runs the server: the hosting company, the Linux distribution’s package, the container image. Until that happens, the site waits, whatever its owner does.

That is the part of the story the “patch now” headlines skip. The PHP team has done its job. Getting its work onto a given server depends on a delivery chain that moves at the speed of its slowest link, and the first day showed how far apart those links are. An owner who doesn’t know where their PHP comes from can’t tell how exposed they still are.

Why a WordPress update doesn’t fix it

Because the bugs sit in the interpreter, the PHP advisory puts every installation that serves web requests in scope, from PHP-FPM and Apache’s mod_php to php-cgi, FrankenPHP and LiteSpeed. The Hacker News notes that even a bare “Hello World” page on a vulnerable version can be attacked. The worst case is mod_php, where a single request from someone with no account can trigger the attack before any application code runs, so no security plugin or login screen ever sees it.

Wordfence, the WordPress security vendor, told site owners, as The Verge reported, that the fix cannot arrive through automatic updates and that they need to find out who is responsible for their PHP. Laravel Forge told its own customers the same about its servers: its automatic security updates do not patch PHP, and Ubuntu’s unattended upgrades only pull from Ubuntu’s own repository, not from the third-party packages Forge installs PHP from.

Those package sources did not move together. On release day, the site-management service mySites.guru reported that cPanel’s EasyApache 4 had fixed builds within minutes of the advisories, while Ondřej Surý’s PPA, the Ubuntu package source Laravel Forge itself relies on, and Remi’s repository had none yet. InMotion Hosting said its shared and WordPress servers were waiting on CloudLinux’s builds. Across the live sites mySites.guru monitors, 0.08% reported a fixed PHP version by 13:52 UTC.

The version number can mislead you

Checking is less obvious than reading a number. Ubuntu, Debian and Red Hat backport security fixes without changing the upstream version, so a patched Ubuntu 24.04 server still reports an 8.3.6 package. The Hacker News, citing Debian, says to look for the CVE in the package changelog rather than trust the version string. mySites.guru adds a second trap: the PHP binary that answers php -v on the command line is often not the one serving pages, so check the version the site itself reports.

Then the patch has to load. PHP’s advisory and Forge both stress restarting Apache, PHP-FPM and every long-running worker. Queue workers and similar background processes keep running the old interpreter until they are restarted, patched files on disk or not.

Who gets no official fix

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, covering CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. PHP 8.1 and older get nothing from the PHP project beyond minimal source backports for 7.4, 8.0 and 8.1, aimed at people who compile PHP themselves. Some vendors fill the gap: InMotion says cPanel backported fixes for its 7.4 to 8.1 packages and CloudLinux is patching every version it ships, while CentOS 7 gets no fix at all.

That tail is not small. On the day before the release, 22.7% of the live Joomla and WordPress sites mySites.guru monitors ran PHP 8.1 or older, and 16.6% were still on PHP 7 or earlier. The company traces part of that to WordPress itself, which recommends PHP 8.3 but still lists long-retired 7.4 as compatible. PHP 8.2 got this patch, yet its security support ends on December 31, 2026.

What the interim setting blocks

The workaround that circulated before the release, setting session.upload_progress.enabled=0, is real but partial. PHP says it blocks the confirmed session paths into CVE-2026-109619, not other variants, and must be set in php.ini or the server or pool configuration, then followed by a restart of every worker. On PHP 8.5, fatal_error_backtraces=0 closes one more confirmed path. Neither touches CVE-2026-109618, for which PHP suggests a non-overridable memory_limit=-1, a low post_max_size and request-size limits at the web server or proxy. Its own wording is that there are no complete mitigations. InMotion notes that WordPress, Joomla, Drupal, Magento and PrestaShop don’t use upload progress, so switching it off breaks nothing for them.

Cloudflare switched on firewall rules for all plans, which its chief technology officer, Dane Knecht, called a stopgap. As mySites.guru points out, they only help if the server behind them refuses traffic that goes around Cloudflare straight to its IP address.

Attacks so far

watchTowr says its honeypots recorded exploitation attempts against both flaws on release day, and Cloudflare saw attackers change their payloads to slip past its rules. No source has confirmed a successful break-in of a specific server. Some operators took no chances: The Hacker News reports that BambooHR took its service offline, and that Dutch public services including DigiD went dark as a precaution. The EU’s CERT and the UK’s National Cyber Security Centre told organizations that cannot patch to isolate exposed apps or take them offline.

The flaws were found by Wiz Research, Calif and OpenAI’s Codex Security team. According to the PHP Foundation, signs of the memory flaw surfaced in a 2024 audit, but a fix stalled for months, a delay it called “a structural failure.” The researchers say AI models helped turn the decade-old bugs into working exploits in about a week.

PHP needed an audit, months of deadlock and a leak to ship this fix. For a site on shared hosting, the last step is a support ticket.

Tags: Cloudflare, PHP, PHP2Shell, vulnerabilities, WordPress