Nora Dossche

A use-after-free memory corruption issue exists in the PHP interpreter core, specifically within the `session.upload progress` component. The flaw occurs during request parsing when PHP records state as ready before all memory allocations are complete. If an allocation fails due to out-of-memory (OOM) errors, the `longjmp()` function is used to abort the request, but some contexts fail to properly roll back the incomplete state, leaving request memory uninitialized. Subsequent cleanup procedures may read or branch on this uninitialized memory. An unauthenticated remote attacker can exploit this by sending specially crafted HTTP POST requests to achieve remote code execution (RCE). Real-world exploitation has been observed against systems using Apache mod php, where attackers used a four-stage HTTP chain involving memory exhaustion and information disclosure via the `PHPSESSID` header to bypass ASLR and execute shell commands such as `/bin/sh`.

PHP contains a use-after-free flaw where global state, error handling, object, and extension state may not be correctly reset or may be repopulated after being reset. This occurs because some states point to memory owned by a single request; if a fatal error interrupts the cleanup phase or if the process uses `longjmp()` for out-of-memory (OOM) errors to abort request handling, the global state may refer to memory after it has been freed. Subsequent requests may then read or branch on this stale state before it is fully initialized. An unauthenticated remote attacker can exploit this condition, specifically through the `session.upload progress` component or by sending a specially crafted POST request, to achieve remote code execution (RCE). This issue affects mod php and conditionally affects FPM through application-stage paths.

The SOAP HTTP client contains a flaw in how it manages response buffer growth. The system uses a check based on signed integer overflow, which is considered undefined behavior and may be optimized away by the compiler. This allows a malicious SOAP server to force the client to allocate a buffer significantly smaller than the actual data being written, resulting in a heap buffer overflow. A heap buffer overflow occurs when data is written beyond the boundaries of a memory block allocated on the heap, potentially leading to crashes or arbitrary code execution.

The mysqlnd wire protocol parser reads fields from server packets without first verifying if the packet contains sufficient bytes. This allows a malicious or compromised MySQL server to send a truncated packet, causing the client to read beyond the packet buffer. This undefined behavior can lead to a process crash.

The `convert.base64-encode`, `convert.quoted-printable-encode`, and `convert.quoted-printable-decode` stream filters contain a memory handling issue. These filters use a `line-break-chars` option where the length is tracked independently of the actual string. The filter constructors use the `pestrdup()` function, which terminates the string at the first NUL byte but retains the original length. Consequently, when the filter generates a line break, it reads beyond the truncated memory allocation, resulting in the leakage of adjacent heap bytes into the filter output.

A use-after-free issue exists in the SOAP extension's object deduplication mechanism, specifically within the `soap add xml ref()` function. The mechanism stores pointers to PHP objects in a global map without incrementing their reference counts. When an apache:Map node contains duplicate keys, the second entry overwrites the first in the temporary result map, freeing the original PHP object while a stale pointer remains. A subsequent href reference to the freed node can copy this dangling pointer into the result. Since PHP string allocations can reclaim the freed memory region, a remote attacker controlling the SOAP request body can exploit this to achieve remote code execution.