CVE-2026-89157: 
MariaDB Server 취약성 분석 및 완화

CVE-2026-89157 is an integer overflow leading to an out-of-bounds heap write in PCRE2's pcre2_pattern_convert() function, affecting 32-bit platforms. It impacts PCRE2 versions 10.30 through 10.47 (inclusive of 10.48-rc1); version 10.48 contains the fix. The vulnerability was reported by researcher "datauwu," published as a GitHub Security Advisory (GHSA-q8g2-wprr-34m9) on August 31, 2026, and assigned CVE-2026-89157 on September 11, 2026. The CVSS v3.1 base score is 7.4 (High) per Feedly/NVD, though the GitHub advisory rates it 5.7 (Moderate) using a local attack vector (GHSA Advisory, PCRE2 Release).

The root cause is a 32-bit integer overflow (CWE-190) in the automatic output allocation path of pcre2_pattern_convert(), which subsequently causes an out-of-bounds heap write (CWE-787). When the caller requests PCRE2-managed output allocation (buffptr != NULL && *buffptr == NULL), PCRE2 first runs the converter in dummy mode to compute the required output length, then calculates the allocation size as sizeof(pcre2_memctl) + (*bufflenptr + 1) * PCRE2_CODE_UNIT_WIDTH. The critical flaw is that PCRE2_CODE_UNIT_WIDTH is a bit width (e.g., 8 for libpcre2-8), not a byte count — on a 32-bit system, supplying a pattern of ~268 million bytes causes the multiplication 0x20000000 * 8 = 0x100000000 to wrap to zero, resulting in an allocation of only 12 bytes (the size of the internal pcre2_memctl header). The second conversion pass then writes 536,870,911 code units into this 12-byte buffer, causing the heap overflow. The fix in commit 8156b3989a82f2ddf9504d8248496e9b124be7f3 uses CU2BYTES() for byte sizing and rejects lengths that would overflow the complete allocation (GHSA Advisory).

Successful exploitation results in an out-of-bounds heap write, causing an immediate process crash (denial of service) and potential further memory corruption. In production environments without memory-safety instrumentation, the heap corruption could theoretically be leveraged for arbitrary code execution, though this has not been demonstrated beyond a reliable DoS. The vulnerability does not affect confidentiality directly, but integrity and availability are both impacted. Only applications running PCRE2 in a 32-bit process that accept large attacker-controlled patterns and pass them to pcre2_pattern_convert() with PCRE2-managed output allocation are at risk; regex compilation and matching are not involved (GHSA Advisory).

A public proof-of-concept (PoC) bash/C script is available in the GitHub Security Advisory, demonstrating the crash via AddressSanitizer on a 32-bit ASan-instrumented build of PCRE2. The PoC was published on August 31, 2026, and classified as a real exploit with high confidence by Feedly's analysis. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.00102 (~0.1%), reflecting low probability of near-term exploitation. Exploitation is rated non-automatable due to the high attack complexity (requiring a very large, specifically crafted pattern and a 32-bit target process) (GHSA Advisory, Feedly).

1. Identify a vulnerable target: Locate an application running on a 32-bit platform that links PCRE2 versions 10.30–10.47 and accepts attacker-controlled pattern input passed to pcre2_pattern_convert() with PCRE2-managed output allocation.
2. Construct the oversized pattern: Create a pattern of exactly 268,435,453 bytes — specifically 268,435,452 NUL bytes (0x10000000 - 4 bytes) followed by one Q byte (0x51). This size is chosen to trigger the integer wraparound in the 32-bit allocation calculation.
3. Submit the pattern to the target application: Supply the crafted pattern as input to the application so it is passed to pcre2_pattern_convert() with PCRE2_CONVERT_POSIX_BASIC (or another mode reaching the vulnerable allocation path) and with buffptr != NULL && *buffptr == NULL.
4. Trigger the integer overflow: PCRE2 internally computes the converted length as 536,870,911 code units (0x1fffffff). The allocation calculation (0x1fffffff + 1) * 8 = 0x100000000 wraps to zero on 32-bit, causing PCRE2 to allocate only 12 bytes.
5. Out-of-bounds write occurs: PCRE2's second conversion pass writes 536,870,911 code units into the 12-byte allocation, corrupting adjacent heap memory. In a production environment, this results in a process crash or, potentially, exploitable memory corruption (GHSA Advisory).

• Process Behavior: Unexpected crashes or segmentation faults in applications using PCRE2's pcre2_pattern_convert() API on 32-bit systems; crash dumps referencing pcre2_convert.c (specifically around line 172 in convert_posix) or pcre2_pattern_convert_8.
• Logs: Application error logs showing abnormal termination or memory access violations originating from PCRE2 library calls; ASan reports referencing SEGV on unknown address with write access in convert_posix.
• Network: Unusually large pattern data (hundreds of megabytes) submitted to application endpoints that perform regex pattern conversion; requests with payloads approaching or exceeding 268 MB in pattern fields.
• File System: Core dump files generated by PCRE2-linked 32-bit processes, potentially containing stack traces referencing pcre2_convert.c (GHSA Advisory).

Upgrade PCRE2 to version 10.48 or later, which contains the security fix in commit 8156b3989a82f2ddf9504d8248496e9b124be7f3. As an interim workaround, limit the size of untrusted patterns before passing them to pcre2_pattern_convert(), or avoid the automatic output allocation mode (i.e., provide a caller-managed output buffer instead of passing buffptr != NULL && *buffptr == NULL). Additionally, restricting access to applications that use pcre2_pattern_convert() to trusted users only, and running vulnerable 32-bit applications in sandboxed environments, can reduce risk until patching is complete. SUSE has also released a security update (SUSE-SU-2026:4201-1) for affected distributions (GHSA Advisory, PCRE2 Release).

The PCRE2 maintainer (NWilson) published the advisory and fix promptly, with the patched release (10.48) available on the same day as the advisory (August 31, 2026). Red Hat acknowledged the vulnerability via their security advisory portal. SUSE issued a security update (SUSE-SU-2026:4201-1) shortly after disclosure. The oss-security mailing list carried a notification, and the vulnerability was picked up by standard security tracking services (VulDB, CVEFeed, CIRCL). No significant social media controversy or high-profile researcher commentary beyond the official advisory has been observed (GHSA Advisory, Red Hat).