Updated 21 October 2026, 14:10 UTC: the fix is released. php.net: "PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately." This article was first written at 08:15 UTC, before the release; the sections below now reflect php.net's advisory.
Two points from php.net's advisory matter most for hosting. On who is most exposed: "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." And on stopgaps: "while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe." The advisory lists those measures, including setting memory_limit=-1 where applications cannot override it and setting session.upload_progress.enabled=0. Read the advisory on php.net before applying them, because they have side effects of their own.
On 21 October 2026 the security firm Sansec published an advisory about two critical remote code execution vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. According to Sansec, the PHP project "will release a fix for two critical vulnerabilities on Wednesday October 21 at 14:00 UTC (16:00 CEST, 10:00 EDT)", and "The PHP security team rated both CVSS v4.0 9.2." The release can come sooner: "PHP reserves the right to release earlier if details become public or attacks start."
Three things make this one urgent rather than routine. The bugs, Sansec writes, "affect all web servers running PHP 5.4 or later, which includes Magento, Shopware and WooCommerce stores." An exploit tool has already surfaced: "A screenshot of an exploit tool named PHP2Shell, credited to Calif.IO, leaked alongside the advisory." And Sansec's expectation for the release itself: "We expect mass attacks to start within 15 minutes of the release."
The fix is in PHP, not in your code
Sansec is direct about where the fix has to happen: "You need to fix PHP2Shell at the infrastructure level, by updating PHP on your servers. You cannot fix it from within your store codebase." A plugin update, a WordPress core update or a Laravel release will not help, because the attack targets the PHP runtime that runs underneath all of them.
That makes the first question simple: which PHP version is actually running your site? Not the version in your composer.json, and not the one on your laptop. Check the one serving your traffic:
# On the server, or inside the running container
php -v
# For a container image you deploy
docker run --rm your-image:tag php -v
# From your app, if you have no shell
<?php echo PHP_VERSION; ?>If you add the one-line check to your app, remove it afterwards. A public page that prints your PHP version is something an attacker will read too.
If you are on PHP 8.2 or newer
The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The work now is getting them running:
- Find every place PHP runs. That includes the web server, queue workers, cron containers, and any old staging copy that is still reachable from the internet.
- Know how your PHP gets updated. On a server you manage, that means your distribution's packages. In a container, it means rebuilding your image once the base image you use (for example
php:8.3-apacheorphp:8.3-fpm) has been published with the fixed version. Then redeploy it. A rebuilt image that is not running yet protects nothing. - Verify the version after you deploy. Run
php -vinside the running container and compare it with the fixed version php.net announces. - If someone else runs your stack, ask them today. Sansec's advice: "If you do not manage your web server stack, ask your hosting provider today to stand by and apply the PHP update as soon as it is released." php.net adds that "Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages."
If you are on PHP 8.1 or older
This is the part that will hurt. php.net: "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version." There is no 8.1 release. php.net does add: "Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor." That helps if you compile PHP yourself; for everyone else, the realistic paths are a vendor backport or moving to 8.2 or newer.
Moving off 8.1 is usually smaller than people fear, but it is not nothing:
- WordPress: recent WordPress releases run on PHP 8.2 and 8.3. The risk is in old plugins and themes. Update them first, then test the site on the newer PHP on a staging copy.
- Laravel: check which PHP versions your Laravel major version supports. Very old Laravel releases may need a framework upgrade before they run on 8.2.
- Custom code: deprecation warnings that were harmless on 8.1 can become visible on 8.2. Run your tests, or at least click through the important pages, on the new version before switching production.
If you cannot move today, ask whoever runs your PHP whether they will apply a backport. Plan the upgrade either way: 8.1 gets no further releases from the PHP project.
What not to rely on
A web application firewall rule may arrive, but Sansec warns against waiting for one, even its own: "From what we know so far, the attack targets PHP itself, before your store code and Shield run. Do not wait for a Shield rule to protect you." Updating PHP is the fix.
php.net names the two bugs as "RCE via OOM corruption" (CVE-2026-109618) and "RCE via stale global state" (CVE-2026-109619), and says the risk applies to "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." The useful work now is knowing exactly where PHP runs in your stack, which version each copy is, and replacing it.
Sources: php.net security advisory, 21 October 2026, read 21 October 2026 at 14:03 UTC; Sansec, "PHP2Shell", published 21 October 2026, read 21 October 2026. For a different kind of urgent update from this week, see eMudhra certificate compromise: what to check in your container image.