CVE-2026-89162: 
MariaDB Server vulnerability analysis and mitigation

CVE-2026-89162 is a low-severity uninitialized memory disclosure vulnerability in the PCRE2 regular expression library affecting versions 10.45 through before 10.48 (including 10.48-rc1). The flaw exists in the pcre2_serialize_encode() function, which may expose two bytes of uninitialized heap memory from prior allocations when serializing certain compiled regular expressions. It was published on September 11, 2026, with the fix included in PCRE2 10.48 released August 31, 2026. The CVSS v3.1 base score is 3.3 (Low) per Red Hat, and 2.9 (Low) per the GHSA advisory (Red Hat Advisory, GHSA Advisory).

The root cause is the use of uninitialized memory (CWE-908) combined with incorrect resource transfer between spheres (CWE-669) and an out-of-bounds read condition (CWE-125). During compilation of certain regular expressions — particularly those involving Unicode character classes (e.g., [\H] with PCRE2_UTF, or [z-\x{100}] with PCRE2_CASELESS | PCRE2_UTF) — two bytes within the compiled structure's char_lists region are left uninitialized by pcre2_compile_class.c. When pcre2_serialize_encode() subsequently copies the compiled structure into a serialized byte buffer, these two uninitialized bytes (detectable at a predictable offset, e.g., offset 1256 in the PoC) are included in the output. Debug and Valgrind builds explicitly initialize these bytes to 0x5555 and mark them inaccessible, but normal production builds do not, leaving the bytes populated with residual heap content (GHSA Advisory, PCRE2 Release).

Exploitation results in a limited confidentiality impact: an adversary may obtain two bytes of uninitialized heap memory that could contain residual sensitive data from prior allocations. There is no impact on integrity or availability. The PCRE2 advisory notes that the attacker's ability to control which two bytes are disclosed is "probably very hard," and that the scenario requires the serialized output to already be exposed to an untrusted actor — a condition that is itself considered unsafe since pcre2_serialize_decode() is not designed to accept untrusted data (GHSA Advisory).

A proof-of-concept C program (pcre2_bug.c) is publicly available in the PCRE2 security advisory, demonstrating the uninitialized memory disclosure via Valgrind. The PoC requires compiling a specific regex pattern and calling pcre2_serialize_encode(), then inspecting the output buffer for undefined bytes. There is no evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.105% (1st percentile), reflecting very low exploitation probability (GHSA Advisory, Github Advisory).

1. Identify a vulnerable target: Confirm the target application links against PCRE2 versions 10.45–10.47 and exposes serialized compiled regex output (e.g., via an API or file) to a potentially untrusted consumer.
2. Compile a triggering regex pattern: Call pcre2_compile_8() with a Unicode character class pattern such as [\H] and the PCRE2_UTF compile option, or [z-\x{100}] with PCRE2_CASELESS | PCRE2_UTF. These patterns cause two bytes in the compiled structure to remain uninitialized.
3. Serialize the compiled code: Call pcre2_serialize_encode_8() on the compiled code object to produce a serialized byte buffer. The uninitialized bytes from the heap are copied into this buffer.
4. Extract uninitialized bytes: Read the serialized buffer at the predictable offset (e.g., offset 1256 as shown in the PoC). The two bytes at this location contain residual heap content from prior memory allocations, potentially disclosing sensitive data.
5. Analyze disclosed bytes: Examine the two leaked bytes for sensitive content (e.g., fragments of keys, passwords, or other heap-resident data), noting that control over which specific bytes are disclosed is highly limited (GHSA Advisory).

The primary remediation is to upgrade PCRE2 to version 10.48 or later, which initializes the two previously uninitialized bytes in pcre2_compile_class.c for all build configurations (PCRE2 Release). As a workaround, restrict which local users or processes can invoke pcre2_serialize_encode() functionality, and avoid exposing serialized PCRE2 output to untrusted consumers, as pcre2_serialize_decode() is not designed to handle untrusted data. Organizations using Erlang/OTP should note that version 28.1 exposes an Erlang API to pcre2_serialize_encode(), though the Erlang/OTP team does not consider this a serious vulnerability for their users (GHSA Advisory, Red Hat Bugzilla).

The vulnerability was originally reported to the PCRE2 project by the Erlang/OTP team, who discovered it while implementing an Erlang API for pcre2_serialize_encode() in Erlang/OTP 28.1. The Erlang/OTP team explicitly stated they do not consider this a serious vulnerability for their users and indicated they would likely not file a separate CVE for Erlang/OTP. Red Hat triaged the issue at low severity, and the PCRE2 maintainers classified the fix as a "low-severity security fix" in the 10.48 release notes (GHSA Advisory, PCRE2 Release).