PHP2Shell (CVE-2026-109618/9): Check and Patch Your PHP Server

On October 21, 2026 the PHP project shipped emergency releases for two flaws in the PHP engine itself: CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell. Both are rated 9.2 on the CVSS v4.0 scale, and both can let an attacker who has no login run code on a web server.

Because the bugs sit in PHP and not in any one application, they reach almost every PHP website: WordPress and WooCommerce shops, Magento stores, Drupal and Joomla sites, Laravel and Symfony apps, admin tools such as phpMyAdmin. This post sums up what is known as of October 22, 2026 and what to do on each of your servers today.

What PHP2Shell is

Both flaws are memory-safety bugs in how PHP cleans up after a request fails part way through.

• CVE-2026-109618. When a request runs out of memory, PHP can stop with request data only half set up, and the cleanup step then treats that data as valid.
• CVE-2026-109619. Some state that belongs to one request can outlive the memory behind it, and a later request on the same PHP worker can use it.

An attacker can chain these into running their own code. Sansec also describes a path that leaks pieces of the server’s memory back in a PHPSESSID cookie, even on sites that never use PHP sessions. That memory can hold passwords, API keys and session tokens. Every trigger Sansec knows of is a multipart/form-data request, the kind a browser sends with a form upload, and default PHP settings are enough.

Researchers do not all describe the two CVEs the same way. Which mechanism belongs to which number differs between write-ups, so take the PHP security team’s advisory as the reference and treat both as one problem to fix together.

Who is affected

• Versions. Every PHP version from 5.4 up to and including 8.5.11, per Google Cloud’s write-up.
• Setups. Any PHP that answers web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team names mod_php as the highest risk.
• Applications. Researchers reported working attacks against current releases of WordPress, Drupal, Joomla and Magento. A clean, fully updated application does not protect you, because the flaw is underneath it. Maintenance mode does not help either.

If your shop runs on Shopify, Shopify runs the servers and you have nothing to patch for the store itself. You may still have PHP elsewhere: a WordPress blog on its own domain, a WooCommerce or Magento store for another market, a custom app or middleware someone built on a PHP framework, a supplier portal. Those are the servers to check.

Is it being exploited?

Reports differ, and they changed over the day:

• Amazon told Tenable its honeypots saw a first attempt on October 17, before the release, and attempts from several actors on October 21.
• Cloudflare said it was seeing early attacks, and watchTowr reported exploitation in its honeypot network.
• Patchstack heard of incidents from hosting partners, while its own data showed probing at the time.
• CISA and Huntress had not observed exploitation when they published.

Details of the bugs leaked before the release, and write-ups from the researchers are now public. Whether or not a given attempt works today, plan as if working attacks are coming.

What to do today

1. Find every PHP server. Websites, staging copies, old microsites, admin tools, the PHP behind a headless store. Old staging sites are often the forgotten ones.
2. Check the PHP version that serves the web. The PHP on the command line (php -v) is not always the one Apache or PHP-FPM runs, and a hosting panel can run a different version per site. Check in the panel, or in a page served by the site itself.
3. Update. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On a managed host, ask the host to confirm the update is in place for your site. On your own server, install the update from your distribution or package source. Linux distributions often backport the fix without changing the main version number, so read your distribution’s security notice rather than comparing version strings alone. Sansec noted that the Remi repository had no update on October 21.
4. Restart every PHP worker. PHP-FPM pools, Apache with mod_php, queue workers. A worker that was not restarted still runs the old code.
5. Plan the move off PHP 8.1 and older. The PHP project is not releasing fixes for 8.1 or earlier. The security team published source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some vendors offer their own backports, but there is no official release. CISA advises taking systems on unsupported PHP offline.

If you can’t update right away

The PHP team lists settings that reduce exposure. They are a stopgap, not a fix, and only the update fully protects a server.

• Set session.upload_progress.enabled=0 in php.ini, the PHP-FPM pool or the server configuration. Setting it from the application with ini_set() or a .user.ini file does not count.
• On PHP 8.5, also set fatal_error_backtraces=0.
• For the out-of-memory path, the advisory suggests memory_limit=-1, set so the application cannot override it (for example php_admin_value[memory_limit] = -1 in an FPM pool), with a sensible post_max_size and a memory limit on the container or service instead. A request with no memory limit can use up the whole server, so do this only with an outer limit in place.
• Restart every PHP worker after the change, and confirm the new value in a request served by the web server, not on the command line.

A firewall rule in front of the site helps for a few hours. Cloudflare and Google Cloud Armor published rules, and Cloudflare called its rules a stopgap. Blocking multipart/form-data requests at the web server stops the known triggers, but it also breaks every upload form, including product image uploads in a store’s admin.

Signs a server was hit

There are no confirmed file-based indicators yet. What researchers suggest watching:

• PHP worker processes (php-fpm, httpd, apache2) starting a shell or download tools such as curl or wget.
• Bursts of multipart requests followed by memory limit errors or repeated 500 responses.
• Unusually long or malformed PHPSESSID cookies in responses.
• PHP workers restarting with no clear reason.

None of these proves an attack on its own. If a server ran an affected version while attempts were going on, treat it as possibly compromised: look for new admin users and new PHP files, and change the secrets it holds, such as database passwords, API keys, payment gateway keys and the keys of any Shopify custom app it talks to.

For WordPress sites: a separate issue this week

Patchstack is also warning about attackers using stolen UpdraftCentral dashboard keys to install backdoors on connected WordPress sites. It is not part of PHP2Shell and updating PHP does not fix it. If you use UpdraftCentral, follow Patchstack’s alert and delete those keys.

Talk to us

The team behind StoreFleet, Shopify app developers since 2021, also works with WooCommerce and Magento stores. We can check your PHP servers for PHP2Shell: list every site and PHP worker, confirm the version each one actually serves, apply the update or the stopgap settings, restart the workers, look for the signs above and rotate the keys that need it. Sites on PHP 8.1 or older get an upgrade plan. If you want us to keep watching afterwards, we can run daily checks, like the ones in our store upkeep service. See hiring e-commerce developers for the platforms we cover, and send a short brief from our custom solutions page.