CVE-2026-89157

What it actually does

On 32-bit platforms, PCRE2 versions before 10.48 contain an out-of-bounds write in pcre2_pattern_convert when converting a sufficiently large regular-expression pattern. The write corrupts adjacent heap or conversion-buffer memory in the calling process, producing integrity loss of in-process data structures and a possible crash or abort. Confidentiality of process memory is not indicated; impact is integrity-primary with limited availability effects. Exploitation requires the high-complexity conditions of a 32-bit address space and a code path that invokes pattern conversion on attacker-influenced input.

Why it matters to the business

Any 32-bit application or service that compiles or converts untrusted regular expressions with PCRE2 can have its in-memory state silently altered or can crash, disrupting regex-heavy features such as search, validation, filtering, or log parsing. The issue is not listed in CISA KEV, is not associated with ransomware use, and has a low and flat EPSS (~0.0028 over 30 days), so mass remote compromise is unlikely; however an exploit is publicly available, so local or supply-chain abuse of 32-bit Red Hat pcre2-main packages remains a realistic integrity risk until hosts are upgraded. Organizations still running 32-bit userland or embedded/legacy images carry disproportionate exposure.

How an attack unfolds

An attacker who can already run code locally or who can feed an arbitrarily large pattern into a 32-bit process that calls PCRE2 pattern conversion supplies a crafted oversized pattern. The conversion routine writes past the allocated buffer, overwriting adjacent memory. Because attack complexity is high and the vector is local, this is typically chained after another foothold (unprivileged local user, compromised low-privilege service, or a product that accepts patterns from a less-trusted local component). Public exploit material exists, so a skilled operator can turn the write into process-integrity compromise or a crash without needing privileges or user interaction. Named threat-actor campaigns are not reported for this CVE.

How to fix it

Upgrade PCRE2 to 10.48 or later. On Red Hat pcre2-main, apply RHSA-2026:67534 and move to 10.48-0.1.hum1 (or the latest vendor build that includes that fix). Rebuild and redeploy any statically linked 32-bit binaries that vendor PCRE2 themselves. Where immediate upgrade is blocked, restrict 32-bit workloads, stop accepting untrusted or unbounded pattern strings, and prefer 64-bit packages which are outside this defect’s stated scope. Inventory nested dependents of libpcre2 and confirm they pick up the patched shared library after the package update.

How to confirm the fix worked

Confirm installed PCRE2 is 10.48+ (Red Hat: pcre2-main 10.48-0.1.hum1 or newer per RHSA-2026:67534). Verify architecture: only 32-bit runtimes were affected—document remaining i686/armhf/other 32-bit images. For dynamically linked software, check the resolved libpcre2 soname and package NEVRA on each host. For statically linked or bundled copies, rebuild against 10.48 and compare binary hashes/SBOMs. After patching, exercise legitimate pattern-conversion paths in staging; absence of conversion-time crashes or sanitizer hits on large-but-valid patterns indicates the bounded write is in place. Do not use weaponized patterns as a production test.

Typical attack path

1. Obtain a local execution or pattern-injection position on a 32-bit host or 32-bit userspace process that links PCRE2 before 10.48.
2. Identify a code path that calls pcre2_pattern_convert (or a wrapper that converts patterns) on input the attacker controls.
3. Submit a very large pattern that triggers the conversion out-of-bounds write.
4. Corrupt adjacent in-process memory to alter control or data integrity, or force a process crash.
5. Use the resulting integrity failure or denial of the regex-using service as a stepping stone; no remote unauthenticated entry is implied by the scoring.

How to detect it

This is a local memory-corruption bug with no network protocol, so look for process crashes and cores rather than inbound traffic. Search host and application logs, systemd-coredump/apport/abrtd archives, and debugger traces for crashes in pcre2_pattern_convert or libpcre2 on 32-bit processes shortly after unusually large regex input. Review package-manager history for pcre2-main older than 10.48-0.1.hum1 still running on i686 or other 32-bit userland. Audit application logs of products that accept user-supplied patterns for extremely long pattern strings preceding a crash. No named APT reporting is attached to this CVE; treat isolated local crashes in unpatched 32-bit PCRE2 as the primary historical signal, not C2 or ransomware artifacts.

• pcre2_pattern_convert
• libpcre2
• pcre2-main
• RHSA-2026:67534
• pcre2 < 10.48
• i686 libpcre2 crash
• 32-bit pcre2 core dump
• pattern_convert out-of-bounds
• SIGSEGV pcre2
• SIGABRT pcre2

What your security team should do

• Patch 32-bit PCRE2 immediately: Red Hat pcre2-main to 10.48-0.1.hum1 (RHSA-2026:67534) or upstream 10.48+.
• Inventory 32-bit hosts, containers, and statically linked binaries that ship libpcre2; treat unpatched 32-bit images as the only in-scope population.
• Disable or gate untrusted pattern conversion until those images are upgraded; prefer 64-bit replacements.
• Because a public exploit exists, prioritize patch verification over hunting, then review local crash and core-dump telemetry for historical pcre2_pattern_convert failures.
• Track RHSA-2026:67534 and downstream rebuilds so nested products inherit the fix; low EPSS and non-KEV status do not justify leaving 32-bit estates unpatched given exploit availability.