CVE-2026-89161

What it actually does

PCRE2 before 10.48 mishandles a previously copied subject when it is supplied as match context to pcre2_jit_match, causing an incorrect free of heap memory. The result is memory corruption in the calling process (invalid/double free), which can terminate the process or, under constrained heap conditions and given the High CIA ratings, enable arbitrary code execution at the privileges of that process. The vector is local, attack complexity is high, and no privileges or user interaction are required.

Why it matters to the business

Any Red Hat-packaged workload that performs JIT regular-expression matching with PCRE2 can crash or, in a worst case, be fully compromised by a local attacker, disrupting services that depend on pattern matching. Exploit likelihood is currently very low: EPSS is ~0.13% and flat over 30 days, the issue is not in CISA KEV, it is not associated with ransomware, and no public exploit exists about 22 days after publication. Patching remains warranted because PCRE2 is a foundational library and a successful trigger yields high-impact process takeover.

How an attack unfolds

An attacker with local access to a host running an unpatched PCRE2 build arranges for a process that uses JIT matching to invoke pcre2_jit_match with a subject that was previously copied and then reused as context. The library performs an incorrect free, corrupting the heap. With no known in-the-wild campaigns, named threat actors, or public exploit code, the attacker would need to win a high-complexity memory-corruption race or layout and then convert the crash into code execution inside the victim process. There is no remote, unauthenticated path implied by the scoring.

How to fix it

Upgrade PCRE2 to 10.48 or later. On Red Hat, apply the pcre2-main fix in 10.48-0.1.hum1 via RHSA-2026:67534 and restart processes that dynamically load libpcre2 so they pick up the new library. Where an immediate package update is not possible, disable JIT matching in applications that allow it (forcing the interpreter path) and restrict local untrusted input to regex APIs until the patched package is installed. Rebuild and redeploy any statically linked binaries that vendor PCRE2 older than 10.48.

How to confirm the fix worked

Confirm installed PCRE2 is 10.48 or newer (Red Hat: pcre2-main 10.48-0.1.hum1 / RHSA-2026:67534 present). Inventory running processes and packages linked to libpcre2 and restart them after upgrade. Verify application or package configuration no longer enables JIT against the vulnerable library, and that statically linked artifacts were rebuilt. Absence of pcre2_jit_match-related aborts after the upgrade, plus package-manager evidence of the RHSA, indicates successful remediation.

Typical attack path

1. Obtain local access to a system that loads an unpatched PCRE2 library (before 10.48) with JIT matching enabled.
2. Identify or influence a process that calls pcre2_jit_match and reuses a previously copied subject as match context.
3. Trigger the incorrect free so the process heap is corrupted.
4. Turn the resulting memory corruption into denial of service (crash) or, if heap state allows, code execution in that process.
5. Operate with the compromised process’s privileges; no further library-specific lateral path is inherent to this flaw.

How to detect it

There are no public exploits, named actors, or ransomware associations, so look for crash evidence rather than campaign tooling. Review abort, coredump, ABRT/systemd-coredump, and kernel logs on hosts that load libpcre2 for stacks or messages naming pcre2_jit_match, invalid free, or double-free around regex-heavy processes. Check package and library version evidence (pcre2 < 10.48, missing RHSA-2026:67534) as exposure, not compromise. Sudden unexplained crashes of local regex-processing services shortly after untrusted local input, without a matching patch, warrant forensic collection of the core and the loaded libpcre2 build-id.

• pcre2_jit_match
• free(): invalid pointer
• double free or corruption
• libpcre2
• pcre2-10.4
• RHSA-2026:67534

What your security team should do

• Patch Red Hat pcre2-main to 10.48-0.1.hum1 (RHSA-2026:67534) and restart all processes that load libpcre2.
• Inventory JIT-enabled PCRE2 consumers, including statically linked binaries, and treat unpatched instances as exposed even though EPSS and KEV risk are low.
• If patching is delayed, disable PCRE2 JIT and limit local untrusted regex input as a temporary control.
• Hunt historical crash and core-dump telemetry for pcre2_jit_match / invalid-free artifacts, then close the ticket only after package and process-restart verification.
• Track this CVE as a library memory-corruption issue with no current mass-exploitation signal; reassess if EPSS, KEV, or exploit-maturity status changes.