CVE-2026-86145

What it actually does

PCRE2 versions before 10.48 contain an out-of-bounds heap write in pcre2_dfa_match. When recursive DFA matching reuses a cached workspace block, the library omits the size check that a newly allocated block would receive, so a too-small reused buffer can be written past its bounds. The result is heap memory corruption. Confidentiality is not directly affected; integrity of process memory can be broken and the process can become unstable or crash. Trigger conditions are an attacker-controlled regular expression, or a recursive pattern combined with a small heap limit set through the PCRE2 API.

Why it matters to the business

Software that uses PCRE2 for regular-expression matching—including many Linux distributions and applications that accept patterns or apply recursive DFA matching under tight memory limits—can be crashed or have in-memory state corrupted. That can mean service outages, failed input processing, or integrity failures in products that treat match results as trusted. The issue is rated high (CVSS 8.2) but is not on CISA KEV, has no reported in-the-wild exploitation, and a low, flat EPSS (~0.0039 over 30 days), so mass opportunistic exploitation is not indicated; residual risk is still material because PCRE2 is a foundational library. Patch within normal high-severity windows, faster where untrusted regular expressions are accepted. Red Hat pcre2-main is addressed by RHSA-2026:67534.

How an attack unfolds

An unauthenticated attacker needs a path that causes PCRE2’s DFA matcher to run on a recursive pattern while a previously cached workspace block is reused. That path is typically an application that compiles or executes attacker-supplied regular expressions, or that applies recursive patterns under an API-imposed small heap limit. The matcher reuses the cached workspace without confirming it is large enough, writes past the buffer, and corrupts adjacent heap metadata or application data. Outcomes range from a reliable denial of service (process crash or abort) to integrity impact on the hosting process. No named threat actors, ransomware use, or public exploit maturity are associated with this issue.

How to fix it

Upgrade PCRE2 to 10.48 or later, which adds the missing size check on reused recursive DFA workspace blocks. For Red Hat pcre2-main, apply RHSA-2026:67534 and install pcre2 10.48-0.1.hum1 (or a later vendor build that includes that fix). Rebuild or restart applications statically linked against older libpcre2 so they pick up the patched library. Until patched, do not accept untrusted regular expressions, avoid pcre2_dfa_match on recursive patterns, and do not combine DFA matching with an unusually small PCRE2 heap limit. Inventory direct and transitive PCRE2 usage (packages, containers, language bindings, and embedded copies).

How to confirm the fix worked

Confirm the installed PCRE2 is 10.48 or newer (for Red Hat pcre2-main, package 10.48-0.1.hum1 or later from RHSA-2026:67534). On RPM systems, verify the package NVR and that no older libpcre2-8.so remains loaded. For statically linked binaries, rebuild against 10.48+ and confirm the binary no longer contains the pre-10.48 pcre2_dfa_match workspace-reuse path. After upgrade, exercise recursive DFA matching and any application features that compile user-supplied patterns and confirm they no longer crash under previously failing conditions. Search images and SBOM/package inventories for PCRE2 < 10.48.

Typical attack path

1. Locate a service or tool that links PCRE2 and either accepts untrusted regular expressions or performs recursive DFA matching with a constrained heap limit.
2. Reach pcre2_dfa_match with a recursive pattern so a cached DFA workspace block is reused.
3. Cause the reused workspace to be smaller than the write the matcher performs, producing an out-of-bounds heap write.
4. Force a crash (availability impact) or corrupt adjacent heap state (integrity impact) in the hosting process.
5. If the host process runs with elevated privileges or brokers sensitive operations, abuse the corrupted process state—this is not a demonstrated remote code-execution chain for this CVE.

How to detect it

There is no public exploit, named actor, or KEV activity to hunt for. Look for evidence of attempted abuse or of the bug being hit: unexpected crashes or coredumps in processes linked to libpcre2 whose stack includes pcre2_dfa_match; abort/segfault logs around regex-heavy services; and application logs showing compilation or execution of user-supplied or highly recursive patterns shortly before a crash. Review package and library load data for PCRE2 < 10.48 as exposure, not compromise. Network IOCs are not expected; this is an in-process memory-safety flaw. If a crash dump exists, inspect heap corruption near DFA workspace reuse rather than seeking a unique payload signature.

• pcre2_dfa_match
• libpcre2-8.so
• PCRE2 version strings below 10.48
• segfault/abort in processes linked to libpcre2 with recursive DFA matching
• package NVR pcre2 earlier than 10.48-0.1.hum1 on Red Hat pcre2-main

What your security team should do

• Patch PCRE2 to 10.48+ immediately on internet-facing or regex-accepting systems; apply RHSA-2026:67534 (pcre2 10.48-0.1.hum1) on Red Hat pcre2-main.
• Inventory all packages, containers, and statically linked binaries that ship libpcre2 and schedule rebuilds where a shared-library upgrade is not sufficient.
• Disable or gate features that compile or execute untrusted regular expressions until those components are patched.
• Treat this as high-severity library hardening rather than an active KEV/ransomware emergency: EPSS is low and exploit maturity is none, but do not defer patching of regex-accepting services.
• Watch for process crashes in services that call pcre2_dfa_match and feed those into vulnerability-driven incident review.