Re: pcre2 version 10.48 released with security fixes

PCRE2, the widely embedded Perl-compatible regular expression library, contains an out-of-bounds write in its pcre2_dfa_match function because the code path that reuses a cached workspace block skips the size check that a newly allocated block performs. Triggering the flaw requires either an attacker-controlled regular expression or a recursive pattern combined with a small heap limit set through the API, conditions that arise in applications that let users supply regex patterns or tune PCRE2's heap limit. A successful attacker can write beyond the workspace buffer, corrupting data (high integrity impact per CVSS 3.1) with only low availability impact; code execution is not documented. Any application, service, or language runtime bundling PCRE2 before 10.48 is affected, with real-world exposure concentrated in software that passes user-controlled regexes to the library. No public proof-of-concept or in-the-wild exploitation is known, EPSS puts the 30-day exploitation probability at 0.4%, and the flaw is fixed in PCRE2 10.48.

Do: Upgrade PCRE2 to 10.48 or later, and install vendor updates (new PHP packages, distribution packages, or application releases) that bundle the fixed library. Audit whether your applications expose user-supplied regular expressions or call pcre2 APIs with recursive patterns and a reduced heap limit, and restrict or validate such inputs until patched. No public PoC or in-the-wild exploitation is known, so no emergency action is required beyond normal patching.

PCRE2, the widely used Perl-compatible regular expression library, contains an out-of-bounds read (CWE-125) in pcre2_match that occurs when the JIT-compiled matcher falls back to the interpreter path and the caller supplies invalid UTF data. An attacker who can feed malformed UTF input into a matching operation can trigger a read past the end of the subject buffer, with the practical impact being a crash or limited availability loss, consistent with the low CVSS 3.1 score of 2.9 (local vector, high complexity). Because PCRE2 ships as a system library on virtually every Linux distribution and is embedded or linked into countless applications such as PHP and Git, any consumer that processes untrusted UTF input with pcre2_match and JIT enabled is potentially affected. The flaw is fixed in PCRE2 10.48. No public proof-of-concept is known, the issue is not in CISA KEV, and no exploitation has been reported in the wild.

Do: Upgrade PCRE2 to version 10.48 or later, or install distribution-provided patched libpcre2 packages, and restart or rebuild dependent applications (e.g., PHP builds) so they pick up the fixed library. Check the installed version with 'pcre2-config --version' or your package manager, and as an interim mitigation consider disabling JIT or validating/normalizing UTF-8 input before running matches on untrusted data.

PCRE2 before 10.48 contains an integer-overflow flaw (CWE-190) in the pcre2_pattern_convert function that leads to an out-of-bounds write, but only on 32-bit platforms and only when an attacker can supply a sufficiently large pattern. An application or service that compiles untrusted patterns on a 32-bit build is therefore exposed: successful corruption can modify memory outside the intended buffer, with the CVSS vector indicating high integrity impact and low availability impact but no confidentiality impact. Affected users are any products or deployments that ship or link a 32-bit build of PCRE2 older than 10.48 and pass attacker-controlled pattern data to the library; 64-bit deployments are not affected by this issue. No public proof-of-concept is known, the flaw is not in CISA's KEV catalog, and there are no confirmed reports of exploitation in the wild.

Do: Upgrade PCRE2 to version 10.48 or later, and rebuild or redeploy any application that statically or dynamically bundles an older 32-bit PCRE2 (check dependencies such as PHP, Exim, PostgreSQL or other software that embeds PCRE2 rather than relying on the system copy). Until patched, restrict or reject large attacker-supplied patterns on 32-bit builds to prevent the overflow condition. 64-bit deployments do not need immediate action for this flaw.

PCRE2, the widely embedded open-source regular-expression library, contains an integer overflow (CWE-190) in its pcre2_compile_32 function on 32-bit platforms, which can result in an out-of-bounds write. It is triggered when an application running a vulnerable PCRE2 build (before 10.48) on a 32-bit platform compiles a crafted regular expression meeting the specific memory-size conditions implied by the high attack complexity score. An attacker who can get such a pattern compiled gains memory corruption with high integrity impact and low availability impact per the CVSS score, meaning tampering or possible crashes rather than data disclosure. Anyone deploying PCRE2 before 10.48 on 32-bit builds is affected, including downstream distributions, language runtimes and appliances that bundle the library; 64-bit deployments are not described as affected. There is no public proof-of-concept, the flaw is not in CISA KEV, and no in-the-wild exploitation is known; the fix shipped with the PCRE2 10.48 release.

Do: Upgrade PCRE2 to 10.48 or later, or install a vendor/distribution package that backports the fix, and rebuild any statically linked or bundled copies. As mitigation, restrict or validate untrusted regular expressions compiled by 32-bit builds. Inventory 32-bit (i386 / 32-bit ARM) deployments and applications that expose regex compilation to untrusted input, since those are the only ones affected.

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.

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.

PCRE2, the widely embedded Perl-compatible regular-expression library, contains a memory-management flaw (CWE-590, multiple/incorrect frees of an allocation) in its JIT matching entry point pcre2_jit_match: when a match context carries a previously copied subject, the routine can perform an incorrect free operation on that memory. The bug is only reachable when an application calls pcre2_jit_match with such a copied-subject context, and the CVSS vector (AV:L/AC:H) indicates exploitation requires local or in-process access under specific conditions, making a straightforward remote exploit unlikely. An attacker who can steer a vulnerable application into this call path could corrupt the heap, potentially causing a crash (denial of service) and, per the high confidentiality/integrity/availability ratings, possibly memory disclosure or code execution. Any system running software built with PCRE2 versions before 10.48 that uses the affected JIT call pattern is potentially affected; the flaw is fixed in PCRE2 10.48. There is currently no public proof-of-concept, the issue is not listed in CISA's Known Exploited Vulnerabilities catalog, and no exploitation has been reported in the wild.

Do: Upgrade PCRE2 to 10.48 or later, or install your operating system or vendor's patched PCRE2 package, and ensure applications that bundle their own copy of the library are rebuilt or updated. Until patched, audit whether your code paths invoke pcre2_jit_match with a match context containing a previously copied subject, since that call pattern is required to reach the bug. With no known proof-of-concept or in-the-wild exploitation, routine patch timelines are reasonable, but monitor the PCRE2 project and downstream packagers for follow-up advisories.

PCRE2 before 10.48 contains an information-disclosure flaw in pcre2_serialize_encode, the API used to serialize compiled regular-expression patterns for storage or transfer between processes. When the function runs, it may disclose two bytes of memory to an adversary; the CVSS 2.9 score reflects a local attack vector with high attack complexity and only a low confidentiality impact (no integrity or availability effect). An attacker gains at most two bytes of memory contents, and the advisory itself notes the leak typically matters only in situations where the adversary already has an unsafe level of access to the application. PCRE2 is an extremely widely bundled regex library (shipped in PHP, nearly every Linux distribution, and countless applications), but only software that actually invokes the rarely used serialize/encode API can expose the leak. No public proof of concept is known, the issue is not in CISA's KEV, and no exploitation has been reported; the flaw is fixed in PCRE2 10.48.

Do: Upgrade PCRE2 to version 10.48 or later, or install the patched library package once your Linux distribution or PHP vendor ships it. Most deployments are not realistically affected because few applications call the serialize API; audit your software (or vendored copies of PCRE2) for use of pcre2_serialize_encode/pcre2_serialize_decode to determine whether the flaw is actually reachable in your environment.