< News
22/10/2026

PHP2Shell: critical PHP vulnerabilities, update now

Share:
Watercolour illustration: a giant patched-up elephant hides among overgrown server racks with red warning lights, while a young elf points at it and holds a companion's hand

Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, allow unauthenticated remote code execution on WordPress, Drupal, Magento and almost any other PHP site. What is affected, which versions fix it and what to do with PHP 7.

On 21 October 2026 the PHP project released security updates for two critical vulnerabilities, nicknamed PHP2Shell. Details leaked online the day before the coordinated disclosure, and security vendors report exploitation attempts in the wild. Treat any server that runs PHP to serve web requests as exposed until it is updated.

What PHP2Shell is

PHP2Shell is the name for two separate bugs in the PHP engine, both rated critical (CVSS v4.0 9.2). A single unauthenticated HTTP request can be enough to run code on the server with the privileges of the web worker, before any application code runs: no login, plugin or vulnerable application is needed.

  • • CVE-2026-109618: remote code execution through memory corruption when PHP runs out of memory while request data is only partly initialised.
  • • CVE-2026-109619: remote code execution through global state that survives after its memory has been freed; it can also leak memory from the PHP worker process.

Popular software affected

The flaw is in PHP itself, so every application running on a vulnerable PHP version is exposed. Researchers have reported unauthenticated code execution against:

  • • CMS: WordPress, Drupal, Joomla, MediaWiki
  • • E-commerce: Magento (Adobe Commerce)
  • • Collaboration and webmail: Nextcloud, Roundcube
  • • Administration and billing: phpMyAdmin, WHMCS
  • • Frameworks: Laravel, Symfony and the applications built on them

Updating WordPress, Drupal, Nextcloud or any other application does not fix the problem: PHP has to be updated on the server.

Affected setups

  • • Apache with mod_php, the most exposed setup
  • • PHP-FPM and php-cgi behind Nginx or Apache
  • • FrankenPHP and LiteSpeed

Fixed versions

Update PHP to one of these releases, or to the patched package from your Linux distribution:

  • • PHP 8.5.12
  • • PHP 8.4.27
  • • PHP 8.3.36
  • • PHP 8.2.35 (PHP 8.2 reaches end of life on 31 December 2026)

PHP 7.4, 8.0 and 8.1

These branches are end of life and will not get an official release. The PHP security team has still published minimal source backports of the fix, for those who build PHP from source:

If you use distribution packages, check your vendor's advisories or an extended support provider for patched builds. PHP 5.4 to 7.3 get no fix at all: the only way out is upgrading to a supported version.

If you cannot update right away

The PHP advisory lists temporary measures that reduce exposure. They do not make an unpatched server safe:

  • • Set session.upload_progress.enabled = 0 in php.ini or in the FPM pool (not with ini_set() or .user.ini) and restart every worker
  • • Lower post_max_size to 8M, or 32M if uploads are needed, keeping upload_max_filesize below it
  • • On PHP 8.5, set fatal_error_backtraces = 0
  • • Put WAF rules for the known exploit vectors in front of the site: Cloudflare has deployed them for all plans

Where an immediate update is not feasible, CERT-EU, the cybersecurity service of the EU institutions, recommends isolating internet-facing systems from public networks until the fix is applied and verified.

Sources and further reading