CVE-2026-89162

What it actually does

In PCRE2 before 10.48, pcre2_serialize_encode can emit two extra bytes of process memory when encoding a compiled pattern. The disclosure is a narrow confidentiality leak (CVSS 2.9, C:L/I:N/A:N) with a local vector and high attack complexity; it does not corrupt patterns, crash the process, or yield a general memory-read primitive.

Why it matters to the business

Operational and business impact is low. The flaw is not in CISA KEV, is not tied to ransomware, and has a negligible, flat EPSS (~0.00156 over 30 days). A two-byte leak matters mainly in niche apps that serialize PCRE2 patterns and already expose that blob in an unsafe channel. Treat Red Hat pcre2-main upgrades as routine hygiene, not emergency change, unless the library is used to serialize patterns in a sensitive local context.

How an attack unfolds

An adversary who already has an unsafe vantage point on a process that calls pcre2_serialize_encode captures the serialized pattern blob and recovers two unintended adjacent bytes (leftover stack or heap contents). Public exploit maturity is reported as available, but the result is only a two-byte confidentiality leak: no remote entry, no privilege escalation, and no persistence by itself. The attacker typically combines those bytes with access they already have rather than using this bug as an initial foothold. No named threat actors are associated with this CVE.

How to fix it

Upgrade PCRE2 to 10.48 or later. On Red Hat, apply RHSA-2026:67534 and move pcre2-main to 10.48-0.1.hum1. Restart services dynamically linked to libpcre2 and rebuild any statically linked binaries. If applications never call the serialize/deserialize APIs, practical exposure is reduced, but the package update remains the correct fix.

How to confirm the fix worked

Inventory hosts and images for PCRE2 < 10.48 and confirm pcre2-main is at 10.48-0.1.hum1 (or newer) after RHSA-2026:67534. Identify binaries and containers linked to libpcre2 and any code paths that call pcre2_serialize_encode. After upgrade, confirm the installed library version and that consumers were restarted or rebuilt so they are not still loading the old shared object.

Typical attack path

1. Obtain local or otherwise unsafe access to a process or channel that serializes compiled PCRE2 patterns.
2. Cause or wait for the application to compile a pattern and invoke pcre2_serialize_encode.
3. Capture the serialized output from memory, IPC, a file, or another already-exposed channel.
4. Isolate the two extra bytes and attempt to interpret them as adjacent memory.
5. Use any recovered data only in combination with pre-existing access; this flaw does not expand control of the host.

How to detect it

Prior exploitation is unlikely to leave distinctive telemetry: there is no network protocol, implant, or privilege-change artifact. Review local access, process, and application logs around services that serialize PCRE2 patterns for unexpected readers of those blobs, and compare serialized payload sizes against the expected encoded length if such data is logged. Version evidence (PCRE2 < 10.48 still loaded) indicates exposure, not compromise. Absent other local-compromise indicators, treat hunting as low priority.

What your security team should do

• Apply RHSA-2026:67534 and upgrade Red Hat pcre2-main to 10.48-0.1.hum1 in the normal patch cycle; this is not a KEV-driven emergency.
• Inventory compile-time and runtime PCRE2 usage, especially serialize/deserialize callers and statically linked binaries.
• Restart or rebuild consumers so they load 10.48+ and verify no pre-10.48 copies remain.
• Do not open an incident solely on this CVE unless it coincides with other local-compromise evidence; EPSS is ~0.16% and stable.
• Note that exploit code is reported available, but the two-byte leak and local/high-complexity profile keep residual risk low.