X (Twitter) Facebook Pinterest LinkedIn E-mail

PHP released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026, fixing PHP2Shell, the name given to two critical vulnerabilities in the interpreter (CVE-2026-109618 and CVE-2026-109619) that allow unauthenticated remote code execution on the server. Hours later, major distributions and some hosting panels began shipping patched packages, though at very different paces. At the same time, several security firms reported exploitation attempts, so the window to update is short.

PHP2Shell and its patches in 30 seconds

PHP fixes PHP2Shell in 8.5.12, 8.4.27, 8.3.36, and 8.2.35; the 8.1 branch and older only get third-party backports.
Ubuntu, Debian 13, RHEL 9 (php:8.2), DirectAdmin, and Plesk on Linux already have patched packages.
AlmaLinux, CloudLinux, and cPanel were preparing theirs; Remi wouldn’t have them the same day.
Cloudflare, Patchstack, and watchTowr report attacks or exploitation attempts.
Temporary measures reduce the risk, but only updating eliminates it.

The flaws were discovered by Wiz Research, OpenAI Codex Security, and the firm Calif, and coordinated by the PHP security team and Google’s Gemini team. Wiz has set up its own site, php2shell.com, with a technical summary and recommendations. Its existence leaked on October 20, 2026, a day before the patch, and this group’s outlets have followed the story since: OpenSecurity explained how the two critical PHP vulnerabilities leaked before the patch, Administración de Sistemas published a quick guide for sysadmins, and WPDirecto covered what these flaws mean for WordPress. There is also an English-language version for administrators on SystemAdministration.net.

What PHP2Shell is and who it affects

Both vulnerabilities are in PHP itself, not in applications, so a well-maintained WordPress, Drupal, or online store can be vulnerable all the same. According to PHP’s advisory, CVE-2026-109618 occurs when out-of-memory handling interrupts PHP with partially initialized internal request data, and the subsequent cleanup treats it as valid. CVE-2026-109619 happens when internal state tied to a request survives the freeing of its memory and a later request in the same process reuses it. Both score 9.2 out of 10 on CVSS v4.0.

They affect every PHP setup that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP places the highest risk on mod_php, where there is a proven exploit in which an unauthenticated request triggers the attack before any application code runs. According to php2shell.com, researchers demonstrated pre-authentication remote code execution on WordPress, Drupal, and Joomla, and the site states that nearly every version since PHP 5.4 was affected by at least one of the flaws. Beyond executing code, an attacker could read process memory, including passwords, tokens, or API keys.

Red Hat gives a more measured assessment for its platform: it classifies the flaw as important, not critical, and says that standard Red Hat Enterprise Linux installations use PHP-FPM rather than mod_php, in which case remote execution is difficult in practice because it usually requires unusual application behavior.

Attacks: what Cloudflare, Patchstack, and watchTowr say

Cloudflare says it saw attack traffic against its customers after the leak and before a patch existed, with attackers modifying payloads to try to evade its rules. Patchstack reported confirmed active-exploitation incidents starting at 07:34 UTC on October 21, 2026, and watchTowr says it is observing exploitation attempts against both CVEs. Huntress, by contrast, had not detected exploitation across its customer base by mid-morning the same day. The UK’s National Cyber Security Centre (NCSC) went so far as to recommend disconnecting systems that couldn’t be protected. BleepingComputer cites a VirusTotal estimate of more than 5.1 million PHP servers exposed on the internet.

Linux distributions: who has already published patches

PHP distributed the patches in advance to distributions and extended-support vendors, but not everyone published them at the same time. The situation as this article went to press, on October 21, 2026, was as follows:

Ubuntu: advisory USN-8948-1 fixes PHP in Ubuntu 26.10, 26.04 LTS (PHP 8.5), 24.04 LTS (PHP 8.3), and 22.04 LTS (PHP 8.1). Ubuntu keeps the original version number and applies the fix as a patch, so you need to check the package revision (for example, 8.3.6-0ubuntu0.24.04.13 on 24.04), not what php -v shows.
Debian: advisory DSA-6574-1 updates php8.4 in Debian 13 (trixie) to 8.4.27-1~deb13u1. For Debian 12 (bookworm), with PHP 8.2, the fix wasn’t yet listed in the security tracker.
Ondřej Surý’s repository (packages.sury.org and its PPA, widely used on Debian and Ubuntu): has published patched versions from 8.2 to 8.5 and backports for older branches, from PHP 8.1 down to 5.6. It’s worth reading the changelog for those backports before deploying them.
Red Hat Enterprise Linux: advisory RHSA-2026:87072 updates RHEL 9’s php:8.2 module to PHP 8.2.35. No advisories had been published for the rest of PHP’s streams.
AlmaLinux: said it would push packages to its testing repository the same day, ahead of Red Hat, for the 7.4 and 8.2 streams on AlmaLinux 8, PHP 8.0, 8.2, and 8.3 on AlmaLinux 9, and PHP 8.3 and 8.4 on AlmaLinux 10.
Remi’s repository (RHEL, AlmaLinux, and Rocky): PHP’s own advisory warns that it won’t have updates on October 21, 2026, and advises switching to distribution packages or compiling from source.
CloudLinux: was preparing its alt-php packages and, in the meantime, published Imunify360 ruleset 8.83, which blocks the exploit’s current pattern and which the company itself presents as a virtual patch, not a fix.

For those compiling PHP from source without a support vendor, the PHP team has published minimal backports for 7.4, 8.0, and 8.1, branches that no longer receive official updates. The advisory also notes that PHP 8.2 reaches end of support on December 31, 2026.

Hosting panels and managed platforms

Plesk: on Linux it is already distributing PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 through its regular update system; the Windows builds and the 7.4, 8.0, and 8.1 builds were still in development. The panel’s own PHP engine (sw-engine) is affected too, and Plesk expects to fix it with hotfixes 18.0.80#11 and 18.0.81#4.
DirectAdmin: has published a build on its current and stable channels that updates PHP 8.2 to 8.5 and adds patches for 8.1, 8.0, and 7.4. It installs with da update and da build php if CustomBuild’s automatic update isn’t enabled. Its team acknowledges PHP 8.1 doesn’t compile cleanly on some systems with the patch, and that 5.6 through 7.3 still have no patches.
cPanel: according to Precursor Security’s live tracker, it was preparing updates from ea-php74 to ea-php85, and older versions could be covered by CloudLinux’s backports.
LiteSpeed and OpenLiteSpeed: PHP lists LiteSpeed among the affected environments. Its lsphp packages are updated from LiteSpeed’s repository, after which the lsphp processes need restarting. As this article went to press, there was no public statement from the company with fixed versions.
RunCloud: as of this writing there was no public advisory either. Users should check which PHP version each server is running in the panel and apply updates as soon as they appear.
Google Cloud: App Engine standard with PHP 8.2 or later updated itself automatically, as did Cloud Run and Cloud Run functions if automatic base-image updates are enabled. App Engine flexible, GKE, and custom containers require a rebuild and redeploy.
Docker images: restarting a container doesn’t help; you need to pull the patched image or rebuild with docker build --pull and redeploy.

In every case, the step most often forgotten is restarting: PHP-FPM, Apache with mod_php, or lsphp processes that were already running keep using the vulnerable binary until they’re restarted.

How to mitigate while you update

PHP’s advisory and php2shell.com propose several measures for those who can’t update right away, with one clear warning: they reduce exposure, but they don’t make the install safe.

For CVE-2026-109618: set memory_limit=-1, preferably with php_admin_value in the PHP-FPM pool or Apache configuration, and make sure nothing re-imposes a limit. Since the process is no longer limited, it’s worth containing it with a container or cgroup v2 limit (memory.max). Don’t use RLIMIT_AS or RLIMIT_DATA, which can trigger the very flaw being mitigated.
Lower post_max_size to 8M if the site doesn’t receive file uploads, or 32M if it does, with upload_max_filesize set lower still, and limit request size and the number of fields and multipart parts at the web server or proxy level.
For CVE-2026-109619: disable session.upload_progress.enabled in php.ini, in the FPM pool, or in the server configuration, and restart every process. Doing it with ini_set() or .user.ini doesn’t work.
On PHP 8.5, set fatal_error_backtraces=0. Hiding errors with display_errors, error_reporting, or @ doesn’t help.
Turn on web application firewall rules. Cloudflare has been applying them since 03:02 UTC on October 21, 2026, across all its plans, including the free tier, with the “Generic Rules – Anomalous Execution” rules and a default block rule for high-confidence signatures; on paid plans, check that the managed ruleset is set to block mode.

; Temporary measures (php.ini or PHP-FPM pool)
session.upload_progress.enabled = 0
post_max_size = 8M
; In the pool: php_admin_value[memory_limit] = -1
; PHP 8.5 only:
fatal_error_backtraces = 0

To detect a possible compromise, Huntress recommends watching for suspicious child processes spawned by PHP-FPM, php-cgi, or Apache, such as shells, curl, wget, or reconnaissance commands like whoami or uname, as well as new files in the web root, cron jobs, and recently created accounts. watchTowr advises preserving logs and configurations before touching anything if there’s suspicion of compromise.

Frequently Asked Questions

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, released on October 21, 2026. The 8.1 branch and older only have backports from distributions, extended-support vendors, or minimal patches for compiling from source.

Is Ubuntu patched against PHP2Shell?

Yes. Advisory USN-8948-1 fixes PHP in Ubuntu 26.10, 26.04 LTS, 24.04 LTS, and 22.04 LTS. Ubuntu keeps the version number, so you need to check the package revision, not php -v.

Do Plesk and DirectAdmin already have PHP fixed?

Plesk ships versions 8.2.35 through 8.5.12 on Linux and is preparing the Windows and older-branch builds. DirectAdmin has published a build with PHP 8.2 through 8.5 updated and patches for 8.1, 8.0, and 7.4.

Is disabling session.upload_progress enough?

No. It only blocks one of the confirmed paths for CVE-2026-109619. PHP insists that updating is the only complete fix, and that every PHP process needs restarting afterward.

Sources: