PCRE2 CVE-2026-89161

Exploitation requires a PCRE2-consuming application (version <10.48) built with JIT support that uses a specific, uncommon API sequence: call pcre2_match with the PCRE2_COPY_MATCHED_SUBJECT option on a match_data block, then reuse that same block on the JIT fast path via pcre2_jit_match. Only that reuse triggers the incorrect free of the previously copied subject buffer. Limiting factors: the pattern must be JIT-compiled, the match_data block must be reused across the two calls (many applications create fresh match data per call), and the CVSS vector is local (AV:L) with low privileges (PR:L) - the trigger is a program-logic prerequisite of the host application, not directly attacker-selectable, which sharply narrows realistic exposure.

Signals converge on this being a genuine but low-priority memory-safety bug rather than an urgent threat. The CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) reflects local, low-privilege, high-impact memory corruption, and SSVC agrees the technical impact is 'total' - but SSVC also rates Exploitation as 'none' and Automatable as 'no', and EPSS is only 0.11% (1st percentile). There is no KEV listing and no public exploit identified at time of analysis. The most important nuance is that the 'high' impact is heavily gated by the trigger: the source diff (PR #937) shows the incorrect free only occurs when a match_data block previously used with PCRE2_COPY_MATCHED_SUBJECT is later reused via the JIT fast-path pcre2_jit_match, which did not release the copied subject and did not clear PCRE2_MD_COPIED_SUBJECT. This is a specific API-usage pattern the consuming application must exhibit, not an attacker-controllable condition - so while an incorrect/double free can in principle be steered toward corruption, most real deployments never hit the vulnerable path. Note also the CVSS AV:L: PCRE2 is a library, so the effective attack vector is inherited from the host application and could be remote if attacker-controlled subjects flow through this exact reuse pattern; verify against the specific consumer.

An application links PCRE2 <10.48 and, for performance, reuses a single match_data block: it first calls pcre2_match with PCRE2_COPY_MATCHED_SUBJECT (heap-copying the subject), then reuses that same block with the JIT fast path pcre2_jit_match on a new subject. The stale PCRE2_MD_COPIED_SUBJECT state leads to an incorrect free of the copied subject buffer, corrupting heap allocator state and potentially escalating from a crash toward memory corruption. No public exploit code is identified and the pattern is uncommon, so practical exploitation depends entirely on the host application's PCRE2 usage.