Critical Remote Code Execution in PHP (CVE-2026-109618 and CVE-2026-109619) – 20261021012

Severity	CRITICAL
Threat Category	Vulnerability – Remote Code Execution (unauthenticated)
Affected Platforms	PHP 8.2.x before 8.2.35, 8.3.x before 8.3.36, 8.4.x before 8.4.27, and 8.5.x before 8.5.12. End-of-life PHP branches (8.1 and earlier) are not assessed by the vendor
CVE	CVE-2026-109618 (RCE via OOM corruption) and CVE-2026-109619 (RCE via stale global state
CVSS	9.2 CRITICAL (v4.0) for each CVE

1. Overview

The PHP Group has released fixes for two critical, unauthenticated remote code execution (RCE) vulnerabilities in PHP, the programming language that powers a large share of the world’s websites. CVE-2026-109618 (“RCE via OOM corruption”) and CVE-2026-109619 (“RCE via stale global state”) were both disclosed on 21 October 2026, each rated 9.2 (Critical) on CVSS version 4.0, and both are fixed in the same set of PHP releases. They were reported by the same researchers and are closely related to memory-safety flaws in how PHP handles abnormal conditions, so they are addressed together in this advisory. Security researchers have published a combined exploit tool, referred to as “PHP2Shell”, that chains the two flaws into a single pre-authentication attack.

Both flaws allow an attacker who can send web requests to a vulnerable PHP server to execute arbitrary code with the privileges of the web server process, without any login or user interaction. The vendor has confirmed working, unauthenticated remote code execution over HTTP against the common Apache mod_php configuration using default settings

2. Who is Affected

Any organisation running a PHP-based website or application on an affected version is at risk. PHP underpins the majority of the web, including WordPress, Drupal, Joomla, Moodle and a large share of custom government and private portals in Bhutan. Palo Alto Networks reports that its telemetry identified more than 22.6 million PHP instances exposed to the Internet that are potentially vulnerable to these flaws.

The severity is assessed as CRITICAL for the following reasons:

• The vendor has confirmed unauthenticated remote code execution over HTTP against Apache mod_php using default input and memory limits. No credentials and no user interaction are required.
• Exploitation is being observed and is expected to grow. Cloudflare reported early attacks against PHP sites around the time of disclosure and deployed protective rules, and Sansec expects mass exploitation now that patches and technical write-ups are public.
• A combined exploit tool (“PHP2Shell”) that chains both flaws into one pre-authentication attack has been reported, which lowers the skill needed to exploit the issues.
• PHP is Internet-facing by design and extremely widespread, so the exposed attack surface is very large.
• The CVSS vector rates attack complexity as high and notes an attack requirement (the attacker must meet certain memory and timing conditions), which is why the score is 9.2 rather than higher. A confirmed exploit against a default configuration nonetheless keeps the practical risk Critical.

3. How the Vulnerability Works

1. Stage 1 – Root Cause

PHP web servers typically run persistent worker processes that handle many requests over their lifetime. When PHP runs out of memory or hits a fatal error, it abruptly aborts the current operation. In the affected versions this abrupt exit can leave a worker’s memory and internal global state in an inconsistent condition, either not fully initialised or still pointing at memory that has already been freed. These are memory-safety faults (use-after-free and access of uninitialised memory). The fixes replace the abrupt exit with a controlled shutdown that resets this state.

2. Stage 2 – Exploitation

CVE-2026-109618 (OOM corruption): An attacker sends crafted web requests, such as oversized or malformed multipart form uploads, that exhaust the worker’s memory while a request is still being set up. The out-of-memory abort then leaves request memory in an invalid state that later processing acts on, which can be steered into code execution.

CVE-2026-109619 (stale global state): An attacker first sends a request that triggers a fatal error or an out-of-memory condition, leaving stale internal state behind in the worker. A later request handled by the same worker reads that stale state before it is reset, producing a use-after-free. One reliable path uses PHP’s session upload progress feature, which is enabled by default and does not require the attacker to be logged in.

3. Stage 3 – Impact

Successful exploitation gives the attacker arbitrary code execution with the privileges of the web server process. From there an attacker can read and modify website files and databases, steal credentials and personal data, deface or disable the site, install web shells and backdoors for persistent access, and attempt to pivot to other systems in the same environment. For government and public-sector sites this also carries a risk of service disruption and loss of public trust.

4. Stage 4 – Fix and Disclosure

The PHP Group published advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp on 21 October 2026, with fixed releases PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The flaws were reported by researchers at Wiz and Calif.io and were discovered with involvement from OpenAI. Public exploit tooling appeared the same day, so the window between disclosure and exploitation is effectively zero.

4. Indicators to Watch For

• The server runs an affected PHP version. Check with: php -v and, for FPM, php-fpm -v. Vulnerable if below 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
• The server interface (SAPI) in use, since Apache mod_php is confirmed exploitable. Check with: apachectl -M | grep php, or review a phpinfo() page.
• Risky features left enabled. Check session.upload_progress.enabled and, on PHP 8.5, fatal_error_backtraces in your PHP configuration.
• Bursts of “Allowed memory size exhausted” messages or repeated fatal errors in the PHP error log, and segmentation faults in the Apache or FPM error log, which may indicate exploitation attempts.
• Multipart POST requests in web server access logs with a missing or incorrect Content-Length, or with an unusually large number of parts or headers per part, especially from unfamiliar IP addresses.
• New or unexpected PHP files appearing in web-writable directories (for example upload folders), which may indicate a planted web shell.

5. Recommendations

5.1. For organizations and government offices:

• Update PHP immediately to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 as matches your branch, then restart the web server and all PHP workers. Updating is the only complete fix for both CVEs.
• Set session.upload_progress.enabled=0 administratively and restart all workers. The vendor recommends disabling this feature even after patching if your application does not use it.
• On PHP 8.5, if you cannot patch immediately, set fatal_error_backtraces=0 administratively and restart workers as a partial interim measure.
• Enforce conservative request size limits at your reverse proxy or web server, and block multipart form uploads at the front end if your application does not need them.
• Do not attempt to mitigate by setting RLIMIT_AS or RLIMIT_DATA. The vendor warns these make memory allocation fail in a way that triggers the vulnerable path.
• If you run an end-of-life PHP version (8.1 or earlier), check your operating system distribution’s security announcements for a backported fix, and plan an upgrade to a supported branch. Many sites in Bhutan run distribution-packaged PHP rather than upstream builds.
• If your site is on shared or managed hosting, confirm with your provider which PHP version and server interface they run and when they will patch. Many site owners do not control their own PHP installation.
• Treat web application firewall or intrusion prevention signatures as partial, temporary protection only. They reduce exposure but do not remove the vulnerability, so patching remains essential.
• After patching, review logs and the indicators in Section 4 for signs of prior compromise. If evidence is found, treat the server as compromised: isolate it, rotate all credentials and keys, remove any web shells, and restore from a known-good backup.

6. Reporting

If you suspect your organization, device or account has been affected by this threat, or observe activity matching this pattern, please report it to BtCIRT at cirt@btcirt.bt

7. Sources and References

1. PHP Security Advisory GHSA-w8hw-w9fx-j79w – RCE via OOM corruption (CVE-2026-109618) (21 October 2026). https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
2. PHP Security Advisory GHSA-6wmf-4rv5-p3rp – RCE via stale global state (CVE-2026-109619) (21 October 2026). https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
3. CVE-2026-109618 – CVE Record (PHP Group) (21 October 2026). https://www.cve.org/CVERecord?id=CVE-2026-109618
4. CVE-2026-109619 – CVE Record (PHP Group) (21 October 2026). https://www.cve.org/CVERecord?id=CVE-2026-109619
5. Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 (Palo Alto Networks Unit 42) (21 October 2026). https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/
6. Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619 (Sansec) (21 October 2026). https://sansec.io/research/php2shell