PHP2Shell: which PHP versions are safe and what to do now

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on a web server without logging in. The pair is widely known as PHP2Shell, the name of the exploit tool the researchers built from both bugs (Sansec’s summary). PHP’s advisory states that “only an update is a complete solution.”

Every vendor fact below was checked against the linked source on October 21, 2026.

Who is affected

According to the PHP announcement, the risk covers “all PHP installations serving web requests”, whichever way PHP is connected to the web server. That includes Magento, Mage-OS, WordPress, Drupal, Laravel and Symfony applications and any custom PHP code. Sansec reports that the researchers ran code without a login on Magento 2.4.9, WordPress, Drupal, Nextcloud and other applications. PHP processes the attacker’s request before the application sees it, so a store’s own code and extensions cannot block the attack.

The second vulnerability can also expose what the server holds in memory. A server that ran a vulnerable version while reachable from the internet may have leaked passwords, API keys or session data. Once it is updated, consider changing the credentials it uses.

Merchants on Shopify have no PHP installation of their own to update, because Shopify hosts the platform (Shopify’s FAQ). Custom apps written in PHP and hosted on your own servers are affected like any other PHP code.

Safe versions

The support dates come from PHP’s supported versions page. A system on PHP 8.2 needs this update now and a move to a newer branch before the end of the year, unless it runs Debian 12’s own PHP packages, which Debian’s long-term support team maintains (DLA-4848-1).

What to check on your servers

Installing the update is usually quick. Most of the risk is in believing it was installed when it was not. These are the questions to ask whoever runs your servers:

• Which PHP version does the web server actually run? It can differ from the version shown on the command line, and one server can run several PHP versions side by side.
• Does the version number prove the fix? Ubuntu, for example, adds the fix to its older PHP package, so a patched Ubuntu 24.04 server still reports PHP 8.3.6 (Ubuntu’s notice). There, the package version is what has to match the vendor’s notice.
• Was PHP restarted after the update? A running PHP process keeps the old code in memory until it is restarted.
• Were the Docker images rebuilt? A running container does not update itself. The official PHP images on Docker Hub were rebuilt with the fixed versions later on October 21, so an image built from them before that still contains a vulnerable version.
• Is the hosting provider handling it? On Adobe Commerce on Cloud, Adobe’s PHP settings page does not say when the PHP patch release is updated, and we found no Adobe notice about these vulnerabilities on October 21. Check the version after the next deployment, and ask Adobe Support if it is still below the safe release.

Magento stores on older versions

Magento limits which PHP a store can run, per Adobe’s system requirements. Stores on 2.4.8 and 2.4.9 can move to a safe release today. A store on 2.4.7 can run PHP 8.3, which is a better target than 8.2.

The latest patches of 2.4.4 and 2.4.5 support only PHP 8.1, which no longer receives fixes from the PHP project, and these lines are past the end of Adobe’s security support (lifecycle policy). Such a store depends on a fix from its operating system vendor (next section) until the Magento upgrade is done.

PHP 8.1 and older

The PHP project no longer releases versions 8.1 or older. It published minimal fixes as source code for 8.1, 8.0 and 7.4 and points users to their vendors. Some vendors have already shipped them:

• Ubuntu fixed PHP 8.1 on Ubuntu 22.04 in its regular updates (USN-8948-1), and older PHP versions on older Ubuntu releases for Ubuntu Pro customers (USN-8948-2).
• Ondřej Surý’s repositories, a common source of PHP on Debian and Ubuntu, published fixed builds of PHP 5.6 to 8.1 (PPA).
• Red Hat had fixed the PHP 7.4 packages on RHEL 8 and had no fix yet for the other PHP versions on RHEL 8, 9 and 10 (Red Hat’s data).

The PHP project describes these fixes as a “Minimal mitigation for EOL version.” They close the known attack paths on a version that receives no other security fixes. The upgrade to a supported PHP version is still required.

If the update has to wait

PHP lists configuration changes that lower the risk, and states that they “reduce exposure to specific attack paths but do not make an installation safe.” They include turning off session upload progress and lowering the maximum request size, and the full list is in the PHP announcement. Cloudflare has also deployed firewall rules for these vulnerabilities. Both lower the risk until the update is installed.

Blocking multipart requests, the format browsers use for file uploads, is sometimes suggested as a stopgap. On a Magento store it also blocks product image uploads in the Admin and, on some stores, the cart or checkout, per Sansec’s analysis. Place a test order after any such change.

Exploitation status

Cloudflare reports that the details leaked before the release and that it “observed attack traffic targeting our customers” (Cloudflare’s post). When we checked on October 21, neither CVE was yet in CISA’s Known Exploited Vulnerabilities catalog.

If you are not sure which PHP version your servers run, or whether the update reached every one of them, we can check and update them for you. Keeping the PHP runtime current is part of our ongoing care retainer. For a one-off update, send us a message.