CVE-2026-89158

What it actually does

On 32-bit platforms, PCRE2 versions before 10.48 contain an integer overflow in pcre2_compile_32 that can produce an out-of-bounds write while compiling a regular expression. The result is process-memory corruption (integrity) and possible limited disruption of the compiling process (availability). Confidentiality is not directly impacted. Exploitation requires a 32-bit build and a pattern that hits the overflow during compilation, which is reflected in high attack complexity.

Why it matters to the business

Services that compile untrusted or attacker-influenced patterns with 32-bit PCRE2 can have application integrity broken—incorrect matching, corrupted state, or process instability—without a confidentiality breach. Exposure is limited to 32-bit deployments of pcre2-main. Exploit prediction is very low (EPSS ~0.0025, flat over 30 days), the issue is not in KEV, and no ransomware or named-actor use is indicated, so mass-outbreak risk is low. Patching remains warranted because integrity impact is high and a Red Hat fix is already published (RHSA-2026:67534).

How an attack unfolds

An attacker needs a 32-bit application that uses PCRE2 before 10.48 and compiles a regular expression from input they can influence (for example a filter, rule, or search pattern). They submit a pattern sized and structured so that integer arithmetic in pcre2_compile_32 wraps, causing a write past an allocated buffer. That write corrupts adjacent heap or compiler state. Because attack complexity is high and no public exploit maturity is reported, reliable control of the write is non-trivial; typical outcomes are altered matching behavior or a crash rather than straightforward remote code execution. No named threat actors or campaigns are associated with this CVE.

How to fix it

Upgrade pcre2-main to a fixed build: Red Hat packages are addressed in 10.48-0.1.hum1 via RHSA-2026:67534 (PCRE2 10.48 or later). Rebuild and redeploy any statically linked 32-bit binaries that vendor their own libpcre2. Where immediate upgrade is not possible, restrict 32-bit workloads from compiling untrusted patterns, run pattern compilation in a tightly sandboxed helper, or disable 32-bit PCRE2 usage in favor of 64-bit builds which are not described as affected. Inventory both dynamic libpcre2 consumers and statically linked products.

How to confirm the fix worked

Confirm installed PCRE2 is 10.48 or later (for Red Hat, 10.48-0.1.hum1 / RHSA-2026:67534). On 32-bit hosts, verify package NEVRA, shared-library soname, and that running processes have mapped the patched library (not a stale statically linked copy). Re-run compile-path tests with previously accepted pattern sizes and confirm no overflow or crash in pcre2_compile_32. Treat remaining 32-bit binaries that still export or call pcre2_compile_32 from pre-10.48 code as exposed. 64-bit-only estates should still be inventoried but are outside the stated flaw.

Typical attack path

1. Locate a 32-bit service or tool that compiles regular expressions with PCRE2 earlier than 10.48 from untrusted input.
2. Reach a network- or file-exposed interface that accepts a pattern (search, filter, ACL, or similar) without requiring authentication or user interaction.
3. Supply a pattern that triggers the integer overflow in pcre2_compile_32.
4. Cause an out-of-bounds write that corrupts compiler or process memory.
5. Abuse the corrupted state to change application behavior or induce instability; further privilege or persistence would require additional, unrelated weaknesses.

How to detect it

There are no public exploits, KEV listings, or named actors to key on. Hunt for evidence that a 32-bit process compiled a pattern and then crashed or aborted inside PCRE2. Review core dumps, systemd/journal and syslog fatal messages, language-runtime fatal logs, and EDR process-crash telemetry for pcre2_compile_32 or libpcre2 on 32-bit architectures around the time untrusted patterns were accepted. Compare on-disk and in-memory libpcre2 versions to 10.48. Network IOCs are not specific: look at application logs for unusual pattern-compile requests immediately before a crash, not for a universal packet signature. Absence of crashes does not prove the bug was not triggered.

• pcre2_compile_32
• libpcre2-8.so
• libpcre2-32.so
• pcre2-10.4
• pcre2-10.47
• RHSA-2026:67534

What your security team should do

• Patch 32-bit pcre2-main to 10.48-0.1.hum1 (RHSA-2026:67534) as the primary control; do not rely on the low EPSS score alone.
• Inventory every 32-bit binary that links libpcre2 or statically embeds PCRE2, including language runtimes, proxies, and security tools that compile patterns.
• Until patched, block or sandbox untrusted pattern compilation on 32-bit systems and prefer 64-bit builds.
• Watch for crashes or abort stacks in pcre2_compile_32 after untrusted input; there is no KEV deadline, but treat integrity-impacting memory corruption as a standard patch SLA item.
• Re-scan images and appliances after rebuild so nested copies of pre-10.48 PCRE2 are not left behind.