PHP Group PHP ext-standard stream filters expose adjacent heap memory through an out-of-bounds read

The convert.base64-encode, convert.quoted-printable-encode and convert.quoted-printable-decode stream filters accept a line-break-chars option whose length is tracked separately from the string itself. The filter constructors duplicate the value with pestrdup(), which stops at the first NUL byte, while keeping the original length. When the filter later emits a line break it copies the recorded length out of the truncated allocation, reading past its end and placing adjacent heap bytes into the filter output.

• PHP Group PHP package ext-standard:
• The 8.2.* branch is affected below 8.2.34; the identified patched release is 8.2.34.
• The 8.3.* branch is affected below 8.3.35; the identified patched release is 8.3.35.
• The 8.4.* branch is affected below 8.4.26; the identified patched release is 8.4.26.
• The 8.5.* branch is affected below 8.5.11; the identified patched release is 8.5.11.

The record sets the default status to unaffected outside the listed ranges. Branches not listed have not been independently established as safe by these affected facts.

The flaw affects the convert.base64-encode, convert.quoted-printable-encode, and convert.quoted-printable-decode stream filters in ext-standard. The line-break-chars option tracks its length separately from the string data. The filter constructors use pestrdup(), which stops at the first NUL byte, while retaining the original length.

When a filter emits a line break, it copies the recorded number of bytes from the truncated allocation. That operation reads beyond the allocation and can place adjacent heap bytes into the filter output. Exploitation requires an application to pass attacker-controlled data to line-break-chars, with an embedded NUL byte, and to trigger line-break output. The PHP advisory states that the path can be reached over HTTP where an application forwards request data into filter options; the amount of exposed data depends on heap layout, and a crash is possible on some allocators or builds.

• Reachability: The issue can be reached over the network when an application passes attacker-controlled data into an affected filter option.
• Authentication and interaction: The supplied assessment describes no authentication requirement and no user interaction, but the target application must expose a path to the option.
• Complexity: High, because the input must contain an embedded NUL byte and must cause the filter to emit a line break.
• Status: The record marks public_exploit as false and does not establish real-world exploitation. The vendor advisory contains a proof-of-concept demonstration, but that does not establish abuse in the wild.

The flaw causes a filter to read beyond the allocation holding line-break-chars after an embedded NUL and place adjacent heap bytes into its output. The technical outcome is disclosure of process-memory data; the content and amount depend on the heap layout at the time of processing.

If the application returns the filter output to a requester, data read beyond the intended logical boundary of the request may be exposed. A crash is possible on some allocators or builds, but the record does not establish integrity modification, code execution, or privilege escalation.

The primary consequence is information disclosure: filter output may contain bytes adjacent to the line-break-chars allocation. If that output is returned to a requester, data held by the PHP process may be exposed, with sensitivity depending on heap layout and the data present in the process.

Some allocators or builds may crash when the vulnerable path is triggered, creating a service availability risk. The described behavior is not a demonstrated mechanism for data modification or privilege escalation; the established impact is focused on confidentiality and possible crashes.

1. Upgrade PHP Group PHP ext-standard to the patched release for the deployed branch: 8.2.34, 8.3.35, 8.4.26, or 8.5.11. Use the release for the matching branch and do not infer that a fix in one branch covers another branch.
2. If an update cannot be applied immediately, prevent untrusted data, especially data that may contain NUL bytes, from being passed directly to line-break-chars. This is a mechanism-based risk reduction measure, not a replacement for the vendor fix.
3. Review applications that use the three affected filters and remove direct forwarding of filter options from requests or other external sources.
4. After updating, verify the runtime and package actually serving requests on each server, container, or image rather than checking only source files or manifests.
5. For PHP supplied by an operating-system or image vendor, apply the vendor update containing the corresponding fixed release and recheck the active runtime.

1. Inventory PHP runtimes and the ext-standard package on servers, containers, and deployment images, then compare them with the fixed branches listed in remediation.
2. Search for code that creates convert.base64-encode, convert.quoted-printable-encode, or convert.quoted-printable-decode stream filters and supplies line-break-chars.
3. Review data flows to determine whether request parameters, HTTP input, or attacker-controlled binary data can reach this option.
4. In a test environment, exercising the relevant path with a memory sanitizer may produce an out-of-bounds heap-read report when the flaw is triggered.
5. As precautionary monitoring, inspect filter output for unexpected binary data or unexplained length changes. The absence of such evidence does not prove that a system is safe.