AI analysis
PCRE2 before 10.48 contains an out-of-bounds read (CWE-125) in the pcre2_match function when matching is performed with the PCRE2_MATCH_INVALID_UTF option and the subject string contains invalid UTF. An attacker who can feed a malformed, invalid-UTF subject string to an application using the affected library with that option can trigger the flaw, with the practical result being at most a low-impact availability problem (per the CVSS 3.1 score of 3.7, no confidentiality or integrity impact). Any application, service, or package that links PCRE2 and processes untrusted input as a match subject with PCRE2_MATCH_INVALID_UTF is affected, which given the library's ubiquity spans most Linux distributions, PHP-style runtimes, and many compiled applications. There is currently no known exploitation in the wild, no public proof-of-concept, and the issue is not listed in CISA's KEV catalog.
What to do: Upgrade to PCRE2 10.48 or later, or install the patched package once your distribution or vendor ships a backported fix, and rebuild dependent applications against the updated library. As a mitigation, avoid passing untrusted subject strings to pcre2_match with the PCRE2_MATCH_INVALID_UTF flag, or validate/strip invalid UTF-8 before matching. Audit which installed packages link libpcre2 and track vendor advisories, since most systems receive this via distribution updates rather than direct library installs.
Affected
| PCRE2 (Philip Hazel / pcre2 project) PCRE2 | all versions before 10.48 |
Estimated exposure
masshundreds of millions of systems (PCRE2 is bundled or linked in virtually every Linux distribution and countless applications) — PCRE2 is the default regex engine shipped with most Linux distributions and widely used runtimes, so effectively all servers, containers, and desktops running pre-10.48 builds carry the flaw, though only those exposing invalid-UTF subject…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.