Alluxi

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): what we're doing and what you should do today

Alluxi -

Published October 21, 2026. We'll update this post as the situation develops.

On October 21, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers call "PHP2Shell." Both are rated 9.2 (Critical) under CVSS v4.0. They let an unauthenticated attacker run code on a web server that runs PHP.

This is not a WordPress plugin bug or a framework misconfiguration. The flaws are in PHP itself, so a server can be vulnerable even when the application code on it is fine. The UK's NCSC, the US NSA and CERT-EU have all told organizations that can't patch right away to consider taking those systems offline. Several governments and large publishers did that today.

The short version

  • Affected: PHP 5.4 and later, in default configurations, under PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
  • Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
  • PHP 8.1 and older: the PHP project no longer issues official releases for these versions. Upgrade, or ask your Linux distribution or LTS vendor whether they've shipped a backport.
  • Exploitation: Cloudflare reported early attacks before the patch was released, and a public exploit tool exists. Assume unpatched servers are being scanned now.

Researchers showed unauthenticated remote code execution against current versions of WordPress, Drupal and Joomla. Calif, one of the teams that found the flaws, also reports working exploits against Magento, Laravel, Symfony, phpMyAdmin, Nextcloud and WHMCS, among others.

Is Alluxi affected?

Our own systems don't run PHP. alluxi.com and our internal tools are Next.js applications on Vercel, and our blog runs on Ghost, which is Node.js. None of them run PHP. Neither the website nor the forms on it are exposed.

Some of the systems we build and maintain for clients do run PHP, mostly Laravel applications. Those are where our team is focused today.

What we're doing

  1. Inventory. We're listing every client system we built or maintain that runs PHP. That covers production, staging, background workers, scheduled jobs and admin tools such as phpMyAdmin, which are easy to forget.
  2. Patching supported versions. On PHP 8.2 and newer, we're updating to the fixed release, rebuilding container images from patched base images, and restarting every PHP worker. A patch doesn't take effect until the running processes restart.
  3. Containing older versions. Systems on PHP 8.1 or older won't get an official fix. On those systems we're applying the interim mitigations PHP has published and adding edge filtering where the client's infrastructure allows it. Where the exposure warrants it, we're recommending a maintenance window until we can upgrade them.
  4. Checking for compromise. We're reviewing logs on affected systems for the warning signs listed below. Details leaked publicly on October 20, so we're starting from that date. If we see anything suspicious, we treat the server as compromised and rotate its credentials.
  5. Contacting you directly. If we maintain a PHP system for you, your project lead will contact you directly with its status and any decision we need from you. You don't need to open a ticket.

What we recommend, whether or not you work with us

1. Find every place PHP runs. This is the hard part. PHP often runs without anyone noticing: a WordPress marketing site, a WooCommerce or Magento store, shared hosting, a cPanel or Plesk panel, a vendor portal, or an appliance with PHP bundled inside. Check staging and old subdomains too.

2. Patch, then restart. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply your distribution's security update. On managed hosting, ask your provider to confirm in writing that they've patched. Then restart PHP-FPM or Apache so the fix loads.

3. If you can't patch today, reduce exposure or go offline. Following the official guidance, consider taking the system offline until it's patched. Your application's maintenance mode doesn't count, because the attack runs inside PHP before your application code. If staying online is essential, PHP's interim mitigations reduce the risk but don't remove it:

  • Set session.upload_progress.enabled = 0 in php.ini or the PHP-FPM pool config (not in .user.ini or ini_set()), then restart every worker.
  • Set memory_limit = -1 at the server level, and cap memory with a container or cgroup limit instead.
  • Keep post_max_size low (8M if the site takes no uploads, 32M if it does), and limit request size at your web server or proxy.
  • If you use Cloudflare, make sure its new WAF rules are active, and that your origin only accepts traffic from Cloudflare. Otherwise attackers can go around them.

4. Look for signs of a breach. Watch for unusual multipart/form-data requests followed by memory-limit errors or repeated HTTP 500s, unusually large or malformed PHPSESSID cookies, and PHP workers crashing and restarting for no clear reason. If you see these, assume the server is compromised. Rotate database passwords, API keys and any secrets stored on it.

5. Ask your vendors. If a SaaS tool, agency or hosting provider runs PHP on your behalf, ask them directly whether they've patched.

Need a hand?

If you're not sure whether you're exposed, or you're stuck on an older PHP version that can't be upgraded overnight, contact our team. We'll help you work out where PHP is running and what to do first.

Sources