PHP versions from 5.4 onward can be considered vulnerable. Interestingly, the vulnerabilities were found with the help of AIs (Gemini 4 Argon + GPT-5.6 Sol), and the patch is more than 10 thousand lines of code.

What the vulnerability is

The attacker’s main goal is to trigger a fatal error, such as out-of-memory (OOM), at the right moment while the PHP interpreter is processing an incoming web request.

The CVEs are related to PHP potentially mistakenly treating a new data array that has not yet been initialized due to an OOM error as initialized. This means that an attacker, by spamming PHP memory with specially crafted requests, can cause the same memory region to be freed and allocated for different arrays.

As a result, due to the OOM error, the fields and pointers of a data array were not initialized in time, and they ended up containing data from previous requests controlled by the attacker. And when freeing memory after the error, PHP will call array cleanup functions at addresses controlled by the attacker. That is why exploiting these two vulnerabilities requires serious preparation and large HTTP requests.

Important: due to the ASLR address randomization mechanism, the attacker needs to achieve a memory leak in order to learn the address of a function, for example system().

How exactly exploitation occurs

Since the source of the vulnerability lies deep and is related to the memory free and allocation mechanisms in PHP, there are several ways to exploit it.

1. x-www-form-urlencoded forms

The amount of memory allocated during PHP processing here is achieved through the great nesting depth of form parameters (...[x]). PHP accounts for a new array element even before it is populated, and copying a long name while processing an HTTP request can exceed memory_limit, causing out-of-memory.

When cleaning up the array, PHP mistakes the planted bytes for a ready-made element. By placing a fake array in the right memory region and substituting a function address into it, the attacker can force PHP to call it during cleanup.

2. Tracking file uploads

During a multipart upload with upload progress tracking enabled via the PHP_SESSION_UPLOAD_PROGRESS parameter, PHP writes the upload status to the session — the visitor’s data store between requests. Many empty file fields with nested names also cause a huge amount of memory to be allocated and an OOM error.

After OOM, the memory may be freed but the pointer to it retained. The next request via upload progress may access it again — this is use-after-free (UAF). If the request lands in the same process that survived the crash, the memory may already contain the attacker’s data.

Important: since the attacker can directly influence the structure of the PHP session data, in one of the requests they manage to trigger a PHP memory leak via the Set-Cookie: PHPSESSID= header, which allows bringing the exploitation through to command execution.

3. Crash report in PHP 8.5.

When the fatal_error_backtraces flag is enabled (enabled by default), PHP saves the list of functions that were executing at the moment of the fatal error. After the request completes, the memory of the list is freed, but the pointer remains. The error message at the start of the next request causes PHP to access it again, triggering another use-after-free.

New reports and PoCs for these vulnerabilities appear every day, which makes creating detections for their exploitation even more difficult. However, to successfully exploit and execute malicious code, the attacker needs to learn the exact addresses of functions (for example, system).

A full exploit that executes malicious code is so far known only for the method using the PHP_SESSION_UPLOAD_PROGRESS parameter.

Network artifacts

The only known full attack chain so far has an obvious artifact — the PHP_SESSION_UPLOAD_PROGRESS parameter in the request body. Successful exploitation may be indicated by an unusually long PHPSESSID value in the response containing URL-encoded memory bytes.

Although the PHP_SESSION_UPLOAD_PROGRESS parameter itself can also be used in ordinary requests, in practice we have not encountered this parameter in network requests.

Important: there is no single mandatory network marker for all exploitation variants.

What is known about the attacks

Amazon specialists recorded attempted attacks as early as October 17. After the vulnerabilities were disclosed, the number of attack attempts in Cloudflare’s network grew to millions, according to the company’s head.

How to fix

Update PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12, or a newer fixed version of your branch.

Until you update, the following PHP settings will help reduce the risk:

• session.upload_progress.enabled=0 — blocks the known chains via upload progress;
• fatal_error_backtraces=0 — blocks the corresponding path on PHP 8.5;
• request size and complexity limits on the web server or reverse proxy.

The settings must take effect before the request is parsed: set them in php.ini or the server configuration.

For CVE-2026-109618, the PHP developers also suggest setting memory_limit=-1 with external memory limits at the container/cgroup level. This is a partial measure: a system-level memory allocation failure can still lead to the vulnerable path.

Only updating PHP fully fixes both vulnerabilities.

Suricata signatures

alert http any any -> any any (msg: "ATTACK [PTsecurity] Possible PHP RCE Exploitation attempt. PHP upload progress in multipart request (PHP2Shell, CVE-2026-109618, CVE-2026-109619)"; flow: established, to_server; http.content_type; content: "multipart/form-data"; startswith; nocase; http.request_body; content: "PHP_SESSION_UPLOAD_PROGRESS"; threshold: type limit, track by_src, count 1, seconds 300; reference: cve, 2026-109618; reference: cve, 2026-109619; reference: url, wiz.io/blog/php2shell-php-rce; classtype: attempted-admin; sid: 10018633; rev: 1;)

alert http any any -> any any (msg: "ATTACK [PTsecurity] Successful PHP RCE Exploitation. PHPSESSID memory leak (PHP2Shell, CVE-2026-109619)"; flow: established, to_client; http.header.raw; content: "Set-Cookie|3a|"; nocase; content: "PHPSESSID="; nocase; distance: 0; content: "%"; distance: 0; pcre: "/Set-Cookie\x3a[\x20\x09]*PHPSESSID\x3d(?:[^\x3b\x25\r\n\x20\x09]{0,64}\x25(?:[0189a-f][0-9a-f]|7f)){12}/im"; threshold: type limit, track by_dst, count 1, seconds 300; reference: cve, 2026-109619; reference: url, wiz.io/blog/php2shell-php-rce; classtype: successful-admin; sid: 10018632; rev: 3;)

#cve #php

@ptescalator