PatchPHP

PHP2Shell

Two vulnerabilities allow unauthenticated remote code execution on PHP installations that serve web requests.

Severity
Critical
Published
21 October 2026
Added to CISA KEV
Not listed in catalog version 2026.10.21

Affected configurations

All PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers the risk highest for mod_php.

The PHP project considers the risk highest for Apache with mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

The two vulnerabilities

CVE-2026-109618: remote code execution via out-of-memory corruption
Out-of-memory handling can interrupt PHP while internal request data is only partly initialized. Request cleanup may then treat that invalid data as valid.
CVE-2026-109619: remote code execution via stale global state
Internal state owned by a request can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

Fixed versions

Upstream releases from the PHP project. Distribution and LTS packages carry their own version numbers.

BranchFixed in
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35
PHP 7.4, 8.0, 8.1Source backport only

How to update

  • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source and Windows downloads are on the php.net downloads page.
  • Linux distributions and LTS vendors received the patches in advance. Check your vendor for updated packages; their version numbers will not match the upstream ones.
  • PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes. Otherwise, upgrade to a supported branch.
  • For people building from source without an LTS vendor, the PHP security team published minimal source backports for PHP 7.4, 8.0 and 8.1.
  • The advisory asks users of the volunteer-maintained rpms.remirepo.net to switch to distribution packages or build from source, because that repository would not have updates on the day of release.

If you cannot update immediately

Interim measures from the PHP security advisory, paraphrased. Read the advisory itself before applying them.

Only updating is a complete fix. These measures reduce exposure to specific attack paths. They do not make an installation safe.

CVE-2026-109618: out-of-memory corruption

  • Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable memory-limit failure, but an underlying allocation failure can still reach the vulnerable code path.
  • Set a low post_max_size: 8M for applications that do not need file uploads, 32M where uploads are necessary. Keep upload_max_filesize below post_max_size.
  • Consider enforcing limits at the web server or proxy for decoded request size, input field count, multipart part count, header count and nesting depth. The limits must also cover requests without a usable Content-Length.
  • Use a container or cgroup memory limit as an availability boundary, preferably one that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA instead: they can cause the vulnerable allocation failure.

CVE-2026-109619: stale global state

  • Set session.upload_progress.enabled=0 and restart every worker. Apply it in php.ini, an FPM pool or server configuration that takes effect before request parsing, not with ini_set() or an FPM .user.ini. This blocks the confirmed session paths but not other variants.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
  • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
  • Fix fatal errors and execution timeouts that an attacker can reach, including failures in callbacks, upload or import processing and cleanup.

What to check

The free PHP2Shell response checklist turns these into steps you can track in your browser.

  1. List every environment that serves PHP over the web, including staging, containers and applications that embed PHP.
  2. For each site, identify the runtime that actually serves requests: the PHP-FPM pool, Apache module, CGI handler, FrankenPHP or LiteSpeed process. The php -v version belongs to the command-line binary only.
  3. Identify where that runtime comes from: distribution package, LTS vendor, third-party repository or source build. Confirm the fix against that vendor’s advisory.
  4. After updating, restart every PHP worker and confirm the processes serving traffic started after the update.
  5. Test business-critical journeys such as login, checkout and uploads.
  6. Patching does not undo an intrusion. Preserve relevant logs and review them for signs of compromise.

Need this checked across your servers? A PHP response assessment records the runtime serving each site and its patch status, in writing.

Sources

Reviewed 22 October 2026.