PHP2Shell: am I affected, and what to do

Two critical flaws in PHP itself were fixed on 21 October 2026. Here is how to tell whether your site is affected, and what to do on each PHP version.

As of 28 October 2026. This is moving quickly; every fact below links to its source.

In 30 seconds

What: two flaws in PHP's core, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on your server without logging in. Both are rated critical. CISA added both to its list of vulnerabilities known to be exploited on 26 October 2026.
Who: any site that serves web requests with a PHP version that hasn't been updated to a fixed release. That includes WordPress, WooCommerce, Magento, Drupal, Laravel and anything else built on PHP.
What to do: update PHP to the fixed release for your version (table below). PHP's own advisory is clear that "only an update is a complete solution".

1. Check which PHP version your site runs

Hosting control panel: most hosts show the PHP version per site, for example in cPanel's MultiPHP Manager or Plesk's PHP settings for the domain.
WordPress: Tools → Site Health → Info → Server shows the PHP version the site runs on.
Your own server: php -v shows the command-line PHP. The version that serves your website (PHP-FPM or the web server module) can be a different one, so check that too, for example with php-fpm -v (the binary is often versioned, such as php-fpm8.3) or your web server's configuration.
Linux distribution packages: distributions such as AlmaLinux, RHEL, Debian and Ubuntu often fix security issues without changing PHP's version number. If your PHP comes from your distribution, check its security notice for these two CVEs instead of the version number.

2. Is your version fixed?

PHP released fixes for every version it still supports on 21 October 2026:

You run	Update to (or newer)	Status
PHP 8.5	8.5.12	Supported
PHP 8.4	8.4.27	Supported
PHP 8.3	8.3.36	Security fixes only, until 31 December 2027
PHP 8.2	8.2.35	Security fixes only, until 31 December 2026
PHP 8.1	No fixed release	End of life since 31 December 2025
PHP 8.0	No fixed release	End of life since 26 November 2023
PHP 7.4	No fixed release	End of life since 28 November 2022

PHP 7.3 and older are also end of life and get nothing at all. If you're on any of the "no fixed release" versions, read section 4.

PHP 8.2 is fixed for now, but its security support ends on 31 December 2026: how to move from PHP 8.2 to 8.3 or 8.4.

3. Who has to update it

Shared hosting: your host updates PHP, but you often choose which version your site uses. Make sure it's set to a supported version, then ask your host: "Have you installed the PHP releases from 21 October 2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35) or your vendor's fix for CVE-2026-109618 and CVE-2026-109619 for the PHP version my site uses?"
Managed platforms (managed WordPress hosts, platform-as-a-service): usually patched by the provider. Check their status page or ask the same question.
Your own server or VPS: you (or your developer) update the PHP packages and then restart every PHP process: PHP-FPM, Apache with mod_php, or whatever runs PHP for your site. Until the restart, the old version keeps running.

4. On PHP 7.4, 8.0 or 8.1

These versions no longer get releases from the PHP project. For this incident the PHP security team did publish minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions and long-term-support vendors ship their own fixed packages. Both are a way to get through this week, not a place to stay: the next flaw may not get a backport at all.

The real fix is moving to a supported version, ideally PHP 8.3 or newer. For most sites the hard part isn't PHP itself but the plugins, themes and extensions on top of it that were never updated for PHP 8.

See what changed and what staying costs per version: PHP 7.4, PHP 8.0, PHP 8.1.
WordPress and WooCommerce: check every plugin and the theme for PHP 8.3 support before switching, and switch on a staging copy first.
Magento: each Magento release supports only specific PHP versions, so moving PHP usually means upgrading Magento too.

5. If you can't update today

PHP's advisory lists settings that reduce exposure to specific attack paths, and states plainly that they "do not make an installation safe". Use them only to bridge the time until you update:

; php.ini (applied before request parsing, then restart all workers)
memory_limit = -1
post_max_size = 8M        ; or 32M if uploads are required
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; PHP 8.5 only

Keep upload_max_filesize below post_max_size.
Set these in the main configuration or the FPM pool, and restart every worker. PHP's advisory says not to rely on ini_set() or FPM .user.ini files for this.

6. After updating

A regression in PHP 8.4.27 and 8.5.12 can crash PHP processes in some applications that use the SimpleXML extension ("zend_mm_heap corrupted" in the logs). It's fixed in PHP's source and will be in the next releases. If you see these crashes after updating, check php-src issue #24488 and watch for the next release rather than going back to an unfixed version.

PHP also recommends switching off session upload progress (session.upload_progress.enabled = 0) until its next regular release, to close an unlikely remaining path.

We Do Dev Work also wrote about what PHP2Shell means for your site.