# PHP2Shell: two critical PHP code-execution flaws, fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35

CVE-2026-109618 and CVE-2026-109619 can let unauthenticated requests run code on PHP web servers, according to PHP, with mod_php most exposed. What to install, how to find every PHP build, and stopgaps.

By Synt World. Published: 2026-10-21T23:17:06+00:00. Updated: 2026-10-21T23:17:06+00:00.

## At a glance

- **Bottom line:** Every PHP build that serves web requests needs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the vendor package that carries the fix, and then a restart of every PHP worker. PHP says no configuration change fully closes either flaw.
- **Affected:** PHP 8.2 to 8.5 before those releases, under PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php the highest risk. PHP 8.1 and older get no official release, and the researchers trace affected code back to PHP 5.4.
- **Severity:** Not 10 out of 10. PHP, which assigned the CVEs, scores both 9.2 under CVSS v4.0; NVD scores both 9.8 under CVSS 3.1; Red Hat scores both 8.1. The 10.0 figure came from claims made before the official release.
- **Exploitation:** As of October 21, 23:00 UTC, neither CVE is in CISA's Known Exploited Vulnerabilities catalog. watchTowr, Cloudflare and Datadog report attacks or exploitation attempts; PHP and CISA have not confirmed exploitation.

## What happened

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two vulnerabilities that, in PHP's words, "can allow unauthenticated remote code execution", and asked all users to update immediately. The CVE records credit researchers at Calif, Wiz and OpenAI with the findings. The researchers call the pair PHP2Shell.

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), "RCE via OOM corruption": out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat that data as valid. CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), "RCE via stale global state": internal state that belongs to one request can outlive the memory behind it, and a later request on the same worker may use it before normal initialization resets it. Both bugs are in PHP itself, not in application code. Wiz reports unauthenticated code execution against the official wordpress, drupal and joomla container images, and says that even a simple "Hello World" application on an affected PHP version can be vulnerable.

## From report to patch

- 2026-08-11: Calif reports the first of the bugs to the PHP project (Calif).
- 2026-08-24: Wiz Research reports its findings to the PHP security team (Wiz).
- 2026-10-20: PHP announces a critical security release for October 21 at 14:00 UTC. watchTowr says details have leaked before the coordinated disclosure date (PHP, BleepingComputer).
- 2026-10-21: PHP publishes both GitHub advisories and the four fixed releases; the CVE records go live. Debian, Ubuntu and SUSE ship fixed packages and the official php container images are rebuilt the same day (PHP, CVE.org, vendors).
- 2026-10-21: Cloudflare pushes an emergency Managed Ruleset release with seven new block rules, which BleepingComputer reports is aimed at PHP2Shell (Cloudflare, BleepingComputer).

## Is it really 10 out of 10?

No. PHP is the CVE Numbering Authority for both records and scores each CVSS v4.0 9.2, critical, with the vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H: reachable over the network with no privileges and no user interaction, but with high attack complexity and attack requirements present. NVD added its own CVSS 3.1 score of 9.8 to both. Red Hat scores both 8.1 under CVSS 3.1 and rates them Important; Ubuntu gives both Critical priority. The 10.0 dates from before the release: watchTowr's CEO told BleepingComputer on October 20 that "Both of them are CVSS10", and a since-deleted Hacker News post made the same claim. watchTowr's own FAQ now lists 9.2, and Tenable, citing the PHP Foundation, calls the 10.0 figure incorrect.

![Bar chart of CVSS base scores published for CVE-2026-109618 and CVE-2026-109619. Pre-release claim: 10. NVD, CVSS 3.1: 9.8. PHP, CVSS 4.0: 9.2. Red Hat, CVSS 3.1: 8.1.](/assets/insights/php2shell-critical-php-rce-1.svg)

The same two bugs score between 8.1 and 9.8 depending on who scores them and with which CVSS version. No official scorer published 10.0.

The difference between 9.2 and 10 does not change the priority. Every published vector agrees on the parts that matter in operations: network access, no privileges, no user interaction and high impact. PHP's advisories describe the result as code running with the privileges of the web server's PHP workers. The high complexity rating fits PHP's own note that exploit reliability depends on the PHP build, extensions, front end and memory allocator layout. High complexity does not by itself mean hard to exploit in practice. The reporters say they demonstrated working exploits against stock container images.

## Who is affected

The CVE records list PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. Those are the branches PHP still supports. Older branches are affected too: PHP 8.1 and older get no releases from the project, but PHP published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source, and Ubuntu ships fixes for releases as old as PHP 5.5. Wiz says every PHP version released in the last decade is affected by at least one of the bugs, and Calif dates the earliest affected code path to PHP 5.4.0. Red Hat states that the PHP versions in RHEL 7 and earlier are not affected. For anything older than 8.2, ask whoever builds your PHP rather than assume either way.

PHP says every installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php the highest risk, because the demonstrated exploit works from an unauthenticated request before any application code runs. For PHP-FPM, the advisories record a validated code-execution path for CVE-2026-109619 that depends on a suitable application operation, and judge FPM susceptible to CVE-2026-109618 from source analysis, without a complete FPM exploit so far. Red Hat, whose default RHEL setup uses PHP-FPM, calls remote code execution there difficult in practice. Patch FPM hosts as well, right after the mod_php ones.

Code execution is not the only risk. Wiz also demonstrated reading PHP worker memory without code execution. That memory can hold passwords, tokens and API keys from other requests. Products that embed PHP are in scope as well: NCSC-NL points to appliances, network devices and management interfaces where administrators cannot update PHP themselves, and keeps an inventory of affected products.

## Exploitation status

As of October 21, 23:00 UTC, the official record shows no confirmed exploitation. Neither CVE is in CISA's Known Exploited Vulnerabilities catalog (catalog version 2026.10.21). CISA's SSVC assessment in both CVE records, made at 14:34 UTC that day, reads exploitation "none", automatable "no", technical impact "total". PHP's advisory does not report attacks.

Security vendors report attacks, but PHP and CISA have not confirmed them. watchTowr says its honeypot network observed exploitation in the wild on October 21. According to BleepingComputer, Cloudflare's CTO said the same day that the company was seeing early attacks. Datadog Security Labs cites "multiple reports of active exploitation in the wild" and broad untargeted scanning. Tenable says code that claims to exploit the flaws is circulating publicly, but that it has not verified any of it. The researchers' detailed write-ups are now public, so treat every unpatched PHP server that faces the internet as exposed.

## What to install

Upstream, the fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with source and Windows builds on PHP's downloads page. For 8.3 and 8.2, the ChangeLog lists this fix and nothing else. 8.5.12 and 8.4.27 also carry routine bug fixes. PHP 8.2 reaches end of life on December 31, 2026. PHP says Linux distributions and LTS vendors received the patches in advance. Debian, Ubuntu and SUSE shipped fixed packages on release day, and Red Hat began to:

- Debian 13 (trixie): php8.4 8.4.27-1~deb13u1 (DSA-6574-1). Debian 12 (bookworm): php8.2 8.2.35-1~deb12u1 (DLA-4848-1, from Debian LTS).
- Ubuntu (USN-8948-1): 26.10 php8.5 8.5.9-0ubuntu2.1; 26.04 LTS php8.5 8.5.4-0ubuntu1.5; 24.04 LTS php8.3 8.3.6-0ubuntu0.24.04.13; 22.04 LTS php8.1 8.1.2-1ubuntu2.28. Ubuntu Pro has fixed builds of php7.4 on 20.04, php7.2 on 18.04, php7.0 on 16.04 and php5 on 14.04, the last two through the Legacy Support add-on.
- Red Hat Enterprise Linux 8, 9 and 10 (bulletin RHSB-2026-013): Red Hat says some updates are available and more are in progress. Rebuild containers when the RHEL and UBI base images update.
- SUSE Linux Enterprise 15 SP7: php8 8.3.36-150700.3.24.1, including apache2-mod_php8 and php8-fpm.
- Docker official php image: the image definitions moved to the fixed versions on October 21, and Docker Hub shows the php tags pushed again later that day. Pull, rebuild everything built FROM php, and redeploy. A running container does not change when its tag moves.
- FrankenPHP 1.13.2: its Docker images and static binaries are built with the fixed PHP versions. A static FrankenPHP binary carries its own PHP, so updating the system PHP does not fix it.
- Remi's RPM repository: on October 21, PHP warned that this volunteer-run repository would have no updates that day and urged its users to switch to distribution packages or build from source. At the time of writing, Remi's blog had no post about the fixed versions.
- Control panels: on cPanel, Plesk and CloudLinux servers, the PHP versions offered to sites come from the panel vendor, not from the operating system or the PHP project. Check that vendor's update channel. We could not confirm their status from the vendors' own pages at the time of writing.

Distribution builds keep their original version number. Ubuntu 24.04's fixed package still reports PHP 8.3.6, far below 8.3.36 but patched. Compare package versions with your vendor's advisory, not the output of php -v with the upstream release list. Scanners that read the X-Powered-By header or php -v will flag patched distribution builds as vulnerable.

The fix changes how PHP handles memory exhaustion. According to the advisory, a request that hits memory_limit now stops at the next safe point, and a process that crosses a second, higher threshold exits at once. After the upgrade, requests that run far past memory_limit may end with the worker process exiting instead of a normal fatal error. Do not mistake those exits for an attack.

## Find every PHP build you run

The php command on a host is often not the PHP that serves web traffic. Debian and Ubuntu package the CLI, FPM, CGI and Apache module separately, each with its own php.ini under /etc/php/<version>/, so php -i shows only the CLI settings. Hosts often carry several PHP versions side by side. Control panels install their own builds under /opt. The official php container images compile PHP from source, so it does not appear in the image's package database. FrankenPHP static binaries embed PHP. Inventory all of these, starting with internet-facing mod_php hosts. On a Linux host:

````
# 1. Installed PHP packages. Distribution builds keep their own version numbers:
#    compare them with your vendor's advisory, not with the upstream 8.x.y list.
dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null | grep '^ii'
rpm -qa --qf '%{NAME} %{VERSION}-%{RELEASE}\n' 2>/dev/null | grep -i php

# 2. PHP web binaries and Apache modules on disk, whoever installed them (can take a while)
find / \( -path /proc -o -path /sys \) -prune -o -type f \( -name 'php-fpm' -o -name 'php-fpm[0-9]*' \
  -o -name 'php-cgi' -o -name 'php-cgi[0-9]*' -o -name 'lsphp' -o -name 'frankenphp' -o -name 'libphp*.so' \) -print 2>/dev/null

# 3. What is serving requests right now, and since when
ps -eo pid,lstart,args | grep -E '[p]hp-fpm: master|[p]hp-cgi|[l]sphp|[f]rankenphp|[a]pache2|[h]ttpd'
apachectl -M 2>/dev/null | grep -i php

# 4. After the upgrade: PIDs still running a replaced PHP binary or module (run as root; should print nothing)
grep -l -E 'php.*\(deleted\)' /proc/[0-9]*/maps 2>/dev/null | cut -d/ -f3
````

For containers, check what runs, not what the Dockerfile says. If an image installs PHP from distribution packages instead of using the official php image, the version string follows the distribution rule above:

````
# PHP version inside each running container
docker ps --format '{{.ID}} {{.Image}}' | while read -r id image; do
  printf '%s %s\n' "$image" "$(docker exec "$id" php -r 'echo PHP_VERSION;' 2>/dev/null || echo 'no php CLI')"
done

# Images built on the official php image record the version in their environment
docker image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' my-app:latest | grep '^PHP_VERSION='
````

A host is fixed only when every web-serving process runs the new build. After the package upgrade, restart the PHP-FPM pools, and restart Apache where mod_php is loaded. Then confirm that step 4 prints nothing. In Kubernetes and other orchestrators, the fix is a rebuilt image rolled out to every replica. A node update does not fix the containers.

## If you cannot upgrade today

PHP lists measures that "reduce exposure to specific attack paths but do not make an installation safe". Apply them where applications cannot override them: php.ini, the FPM pool or the web server configuration. Then restart every worker. For the session setting, PHP warns that ini_set() and FPM .user.ini files are not enough.

````
; In the php.ini that the web SAPI reads (FPM or Apache), or as php_admin_value in the FPM pool.
; Restart every PHP worker afterwards. None of this replaces the update.

; CVE-2026-109619: blocks the confirmed session paths only
session.upload_progress.enabled = 0

; CVE-2026-109619, PHP 8.5 only: blocks the confirmed fatal-error backtrace path only
fatal_error_backtraces = 0

; CVE-2026-109618: 8M if the application takes no uploads, 32M if it does.
; Keep upload_max_filesize below post_max_size.
post_max_size = 8M
upload_max_filesize = 6M
````

- Set memory_limit = -1 with php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back (PHP). PHP says this removes the attacker-controllable failure, but an underlying allocation failure can still reach the vulnerable code. It also removes PHP's own per-request memory cap, so add a container or cgroup memory limit, preferably one that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA instead: PHP warns that they can cause the very allocation failure behind CVE-2026-109618.
- Enforce limits at the web server or proxy on decoded request size, input field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length (PHP). If an application never accepts multipart/form-data, block it at the front end (GHSA-w8hw-w9fx-j79w). Applications with forms or uploads need multipart, so blocking it there breaks them.
- Remove invalid or deprecated PHP settings applied per request: Apache php_value and php_flag lines in virtual hosts and .htaccess files, and PHP_VALUE or PHP_ADMIN_VALUE parameters sent by nginx or another FastCGI front end. Hiding the resulting warnings with error_reporting, display_errors or @ does not help (PHP).
- Fix fatal errors and execution timeouts that an attacker can trigger, including those in callbacks, upload or import processing and cleanup (PHP). As a last resort on FPM, pm.max_requests = 1 recycles each worker after a single request, at a large performance cost (GHSA-6wmf-4rv5-p3rp).
- Treat WAF rules as a way to gain time. They do not make a server safe. Cloudflare's emergency rules protect only traffic that passes through Cloudflare, and according to BleepingComputer, Cloudflare's CTO called them temporary.
- If you can neither update nor apply these measures quickly, the UK NCSC advises considering taking the system offline until it can be fully mitigated.

After the update, keep session.upload_progress.enabled = 0 if no application needs the feature. PHP's advisory suggests this, because it expects more attackers to probe this rarely used and little-tested feature.

## Look for signs of compromise

These bugs fire below the application, so application logs may show little. Wiz suggests watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained PHP worker churn. Datadog adds three concrete signals from its lab. The first is a PHP fatal "Allowed memory size ... exhausted" error reported "in Unknown on line 0", which means PHP failed before any script started. The second is Apache child crashes logged as "exit signal Segmentation fault (11)". The third is a shell started by a web worker, which Datadog calls the most direct evidence of successful exploitation.

PHP's advisory warns that a clean log does not prove a server is safe: a failure can happen before PHP writes a message, and older logs may have filtered out deprecations. If a server faced the internet unpatched after October 20, follow the NCSC's advice and check it for backdoors. On a PHP host, start with new or changed PHP files in web roots and upload directories, unexpected cron entries, and outbound connections from web worker accounts. If you find signs of compromise, rotate every secret the PHP workers could read, such as database passwords, API keys and session or signing keys. The memory-disclosure path exposes data from other requests, so an attacker may hold those secrets even without code execution.

## What this means for PHP hosting

PHP2Shell is a runtime bug. Application patches, Composer audits and CMS plugin updates do not touch it. Closing it in a day takes a list of the PHP builds that actually serve traffic, knowledge of where the CLI and web configurations differ, and the ability to rebuild and roll out every image at once. For hosting providers, a sensible order is shared hosting and mod_php fleets first; then PHP-FPM, php-cgi, LiteSpeed and FrankenPHP; then appliances and products that bundle PHP. Note which of these steps took longest this week, and fix that before the next PHP release.

## Sources

- [PHP: Security advisory: Critical remote code execution vulnerabilities, update now (October 21, 2026)](https://www.php.net/archive/2026.php#2026-10-21-5)
- [PHP: Upcoming Critical PHP Security Release (October 20, 2026)](https://www.php.net/archive/2026.php#2026-10-20-1)
- [PHP 8 ChangeLog (8.5.12, 8.4.27, 8.3.36, 8.2.35)](https://www.php.net/ChangeLog-8.php)
- [PHP downloads](https://www.php.net/downloads.php)
- [GitHub Security Advisory GHSA-w8hw-w9fx-j79w (php/php-src): RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
- [GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (php/php-src): RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [CVE.org: CVE-2026-109618](https://www.cve.org/CVERecord?id=CVE-2026-109618)
- [CVE.org: CVE-2026-109619](https://www.cve.org/CVERecord?id=CVE-2026-109619)
- [NVD: CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618)
- [NVD: CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619)
- [CISA Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [php-src: minimal source backport for PHP 7.4](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619)
- [php-src: minimal source backport for PHP 8.0](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619)
- [php-src: minimal source backport for PHP 8.1](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619)
- [Wiz Research: PHP2Shell](https://www.wiz.io/blog/php2shell-php-rce)
- [Calif: php2shell write-up](https://calif.io/php2shell/)
- [watchTowr: PHP RCE FAQ, PHP2Shell CVE-2026-109618 and CVE-2026-109619](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)
- [UK NCSC: Critical security issue affecting PHP (October 21, 2026)](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php)
- [NCSC-NL: php2shell operational information and affected-product inventory](https://github.com/NCSC-NL/php2shell)
- [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Red Hat: CVE-2026-109619](https://access.redhat.com/security/cve/CVE-2026-109619)
- [Debian security tracker: CVE-2026-109618](https://security-tracker.debian.org/tracker/CVE-2026-109618)
- [Ubuntu USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1)
- [Ubuntu: CVE-2026-109618](https://ubuntu.com/security/CVE-2026-109618)
- [SUSE: CVE-2026-109618](https://www.suse.com/security/cve/CVE-2026-109618.html)
- [docker-library/php: [security] Update to 8.5.12, 8.4.27, 8.3.36, 8.2.35](https://github.com/docker-library/php/commit/f6048b5f6e3c2202ee082665a4ccc0d90de291a3)
- [Docker Hub: php official image](https://hub.docker.com/_/php)
- [FrankenPHP 1.13.2 release](https://github.com/php/frankenphp/releases/tag/v1.13.2)
- [Cloudflare: WAF Release 2026-10-21, Emergency, Cloudflare Managed Ruleset](https://developers.cloudflare.com/changelog/post/2026-10-21-emergency-waf-release-cfmr/)
- [Datadog Security Labs: PHP2Shell detection, analysis and remediation](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/)
- [Tenable: PHP2Shell frequently asked questions](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)
- [Remi's RPM repository blog](https://blog.remirepo.net/)
- [BleepingComputer: PHP warns admins of two critical flaws, emergency patches coming tomorrow](https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/)
- [National Vulnerability Database](https://nvd.nist.gov): This product uses the NVD API but is not endorsed or certified by the NVD.
- [GitHub Advisory Database](https://github.com/advisories): Contains data from the GitHub Advisory Database, licensed CC-BY 4.0.