* SECURITY UPDATE: heap buffer overflow in the convert.* stream filters when line-break-chars contains a NUL byte (GHSA-88hq-2827-7pg6) - debian/patches/php-5.4-CVE-2026-92842.patch: the base64-encode, quoted-printable-encode and quoted-printable-decode filter constructors in ext/standard/filters.c duplicated the caller's line-break-chars with pestrdup(), which is strlen-based and stops at the first NUL, while lbchars_len kept the original length; the filter later copied lbchars_len bytes out of the shorter allocation, reading past its end. Duplicate with pestrndup(lbchars, lbchars_len, persistent) instead, so the allocation always matches the length the filter uses - CVE-2026-92842 * SECURITY UPDATE: integer overflow in the ext/soap HTTP body reader leading to a heap buffer overflow (GHSA-cj93-vc83-wgqv) - debian/patches/php-5.4-CVE-2025-14181.patch: get_http_body() in ext/soap/php_http.c accumulated the chunked-transfer body length in a signed int and guarded the growth with "http_buf_size + buf_size + 1 < 0". That is signed-overflow undefined behaviour, which modern compilers delete, so a malicious server could pick chunk sizes that wrap the erealloc() size and have the body written past the allocation. Make the accumulator a 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 addition is performed, read the chunk size into an unsigned int as sscanf("%x") requires, apply the same bound to the Content-Length and connection-close paths, and build the redirect path with safe_emalloc() - CVE-2025-14181 * SECURITY UPDATE: phar tar entry injection (GHSA-j3wh-g957-2m85) - debian/patches/php-5.4-CVE-2026-6103.patch: phar_parse_tarfile() in ext/phar/tar.c read the entry size with phar_tar_number(), which wraps silently on an oversized octal field and ignores trailing garbage and GNU base-256 sizes, and it skipped the data blocks only of entries of type '\0' and '0'. Either way the stream could be left positioned on attacker-controlled data that was then parsed as a tar header, so PharData listed entries that 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 the unsupported GNU long link ('K') record instead of registering it, and bound a ././@LongLink name by the archive size - CVE-2026-6103 * SECURITY UPDATE: unbounded recursion in ext/soap XML parsing and decoding (GHSA-rgrp-mwpx-f6rm) - debian/patches/php-5.4-CVE-2026-91765.patch: cleanup_xml_node() and get_node_with_attribute_recursive_ex() in ext/soap/php_xml.c recursed once per document level, and master_to_zval_int() in ext/soap/php_encoding.c recursed once per href hop, so a deeply nested or href-chained SOAP message exhausted the stack and crashed the process. Both traversals are rewritten iteratively, documents deeper than SOAP_MAX_XML_DEPTH (2048) are rejected at parse time on libxml2 below 2.13, and the decoder now carries a decode_depth counter in the soap module globals that is capped at SOAP_MAX_DECODE_DEPTH and reset by encode_reset_ns()/encode_finish() - CVE-2026-91765