Signed integer overflow in PHP ext-soap can cause a heap buffer overflow

The SOAP HTTP client guards its response buffer growth with a check that relies on signed integer overflow, which is undefined behaviour and is not guaranteed to trigger. When the check is optimised away, a malicious SOAP server can make the client allocate a buffer far smaller than the data it then writes into it, producing a heap buffer overflow.

The PHP Group PHP package ext-soap is affected in these release branches:

• 8.2.*: versions less than 8.2.34 are affected; the fixed release is 8.2.34.
• 8.3.*: versions less than 8.3.35 are affected; the fixed release is 8.3.35.
• 8.4.*: versions less than 8.4.26 are affected; the fixed release is 8.4.26.
• 8.5.*: versions less than 8.5.11 are affected; the fixed release is 8.5.11.

The supplied data confirms only these branches and boundaries. Do not infer the status of another release branch without branch-specific evidence.

In PHP ext-soap, get_http_body() accumulates chunked SOAP response data and checks buffer growth with additions performed on int variables. The check depends on signed integer overflow, which is undefined behaviour in C and may be removed by the compiler. When that branch is removed, zend_string_realloc() can receive a wrapped length, allocate substantially less memory than the subsequent read loop writes, and trigger a heap buffer overflow.

The vulnerable component is the SOAP HTTP client, and the attacker-controlled input is the SOAP response. The advisory states that the fix changes the accumulated size to size_t, bounds each growth step before allocation, and uses zend_string_safe_realloc() to check multiplication and addition. The final result, such as a crash or memory corruption, depends on the heap layout and the compiler used to build PHP.

The issue is remotely reachable when a PHP SoapClient accepts a response from a malicious SOAP server. A man-in-the-middle on a plaintext SOAP connection can also provide an attacker-controlled response. The supplied metrics indicate that no authentication or user interaction is required, but exploitation has high complexity because the build must have the undefined signed-overflow check optimized away and the client must accept a multi-gigabyte response.

The record marks a public exploit as available, and the PHP advisory documents a proof of concept and regression test. The supplied evidence does not establish exploitation in the wild.

The direct technical outcome is an out-of-bounds heap write in the PHP process handling the SOAP response. Depending on the heap layout and compiler, this can cause a crash or memory corruption, affecting service availability and potentially the integrity of the process. The record does not establish a confidentiality impact and does not prove that the flaw consistently leads to code execution.

The affected security scope remains the PHP process using SoapClient. Exploitability is limited by the requirement that the compiler remove the undefined-overflow check and by the need for the client to accept a multi-gigabyte response; if memory_limit stops processing first, the advisory indicates that the process reaches out-of-memory before the overflow.

• A PHP application processing a malicious SOAP response may crash, run out of memory, or become unstable, causing service disruption.
• The heap buffer overflow can produce memory corruption; the actual result depends on the heap layout and compiler, so all builds should not be assumed to behave identically.
• Plaintext SOAP connections increase exposure because a man-in-the-middle can replace the response. The advisory does not establish that the flaw by itself causes data disclosure or arbitrary code execution.
• Systems that connect only to trusted SOAP servers should still be checked because the defect is in the client and depends on response size.

1. Upgrade PHP with ext-soap to the fixed release matching the deployed branch: 8.2.34, 8.3.35, 8.4.26, or 8.5.11. Use the exact fixed release for the relevant branch; the available evidence does not establish that every other branch is fixed.
2. If an immediate upgrade is not possible, restrict SOAP clients to trusted endpoints and prefer protected transport to reduce exposure to malicious servers or man-in-the-middle responses. This is temporary risk reduction, not a substitute for patching.
3. A low memory_limit can force an out-of-memory failure before the overflow is reached, according to the advisory's documented workaround. This may itself disrupt service and should not replace the fix.
4. After upgrading, verify that the running PHP process and ext-soap module use the intended version, including in container images, backported packages, and internally built runtimes.

• Inventory PHP installations with ext-soap installed and enabled, then compare each branch with the affected boundaries in affected_summary.
• Identify applications using SoapClient, their SOAP destinations, and whether those destinations can be changed, are untrusted, or use plaintext transport.
• Record the compiler and build toolchain used for PHP when triaging exposure, because the advisory identifies removal of the signed-overflow check as a condition relevant to manifestation.
• Review crash, out-of-memory, and memory-corruption telemetry involving SOAP clients, especially around chunked or unusually large responses. Treat these as investigation leads, not confirmed indicators of compromise.
• Check memory_limit. A low value can cause an out-of-memory failure before the overflow is reached, but it is not a replacement for applying the fix.