- CVE-2026-92842: heap buffer overflow in the convert.* stream filters when line-break-chars contains a NUL byte (GHSA-88hq-2827-7pg6). The base64-encode, quoted-printable-encode and quoted-printable-decode filter constructors duplicated lbchars with the strlen-based pestrdup(), which truncates at the first NUL, while lbchars_len kept the caller's original length; the filter then copied lbchars_len bytes out of the shorter allocation. Duplicate with pestrndup(lbchars, lbchars_len, persistent) instead - CVE-2025-14181: integer overflow in ext/soap get_http_body() leading to a heap buffer overflow (GHSA-cj93-vc83-wgqv). The chunked-transfer accumulator was a signed int guarded by "http_buf_size + buf_size + 1 < 0", which is signed-overflow UB that the compiler removes, so an attacker-controlled chunk size could wrap the erealloc() size and the body was then written past the allocation. Make the accumulator size_t, bound every growth step against SOAP_HTTP_MAX_BODY_LEN ((size_t) INT_MAX - 1, the local stand-in for upstream's ZSTR_MAX_LEN) before the add is performed, read the chunk size into an unsigned int as %x requires, apply the same bound to the Content-Length and connection-close paths, and allocate the redirect path with safe_emalloc() - CVE-2026-6103: phar tar entry injection (GHSA-j3wh-g957-2m85). phar_tar_number() wrapped silently on an oversized octal size field and ignored trailing garbage and GNU base-256 sizes, and only entries of type '\0' and '0' had their data blocks skipped, so a crafted archive could leave the stream positioned on attacker data that was then parsed as a tar header - making PharData show entries no conforming tar reader sees. Parse the size with a strict phar_tar_size() that rejects anything it cannot represent, skip the data of every type that carries data via phar_tar_type_has_data(), refuse unsupported GNU long link ('K') records, and bound a ././@LongLink name by the archive size - CVE-2026-91765: unbounded recursion in ext/soap XML parsing and decoding (GHSA-rgrp-mwpx-f6rm). cleanup_xml_node() and get_node_with_attribute_recursive_ex() recursed once per document level, and master_to_zval_int() recursed once per href hop, so a deeply nested or href-chained SOAP message exhausted the stack and crashed the process. Both traversals become iterative, documents deeper than SOAP_MAX_XML_DEPTH (2048) are rejected at parse time on libxml2 below 2.13, and the decoder carries a decode_depth counter in the soap globals that is capped at SOAP_MAX_DECODE_DEPTH and reset by encode_reset_ns()/encode_finish()