On 9/4/26 16:25, Alan Coopersmith wrote: (Security fix for very specific API usage, GHSA-2p8c-ff85-vh9x) If pcre2jitcompile() is called with options for some match modes, and then pcre2match() is used to perform a match for a different match mode, an out-of-bounds read can occur if the match is attempted against invalid UTF input. This is now assigned CVE-2026-89156. (Security fix for pattern conversion, GHSA-q8g2-wprr-34m9) If pcre2convert() is called on untrusted input on platforms with 32-bit sizet, an out-of-bounds heap write can occur. This is now assigned CVE-2026-89157. (Security fix, GHSA-3r4p-g7gg-ppmf) Fixed an out-of-bounds write in DFA matching when using a heap limit; also fixed possible integer overflows which could cause under-allocation of the workspace. As Salvatore previously noted, this one got CVE-2026-86145. (Security fix, GHSA-fmgr-6ggq-9859) Added bounds checks for several integer overflows while compiling patterns on 32-bit CPUs, which could cause under-allocation followed by out-of-bounds writes. This is now assigned CVE-2026-89158. (Security fix, GHSA-9qww-pwc4-77qq) Applied lower buffer bound to prevent two out-of-bounds reads while scanning backwards through invalid UTF data with PCRE2MATCHINVALIDUTF. This is now assigned CVE-2026-89160. (Security fix for very specific API usage, #937) Fixed a leak and later invalid free when calling the fast-path pcre2jitmatch() function with a match data object previously used with pcre2match() and PCRE2COPYMATCHEDSUBJECT. This is now assigned CVE-2026-89161. (Low-severity security fix, GHSA-q7rw-r7qq-2hx6) Fixed exposure of two uninitialised bytes from malloc() via pcre2serializeencode(). This is now assigned CVE-2026-89162.

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

An out-of-bounds read vulnerability was discovered in the PCRE2 library in the compilexclassmatchingpath() function of the pcre2jitcompile.c file. This involves a unicode property matching issue in JIT-compiled regular expressions. The issue occurs because the character was not fully read in case-less matching within JIT.

PCRE 7.8 and 8.32 through 8.37, and PCRE2 10.10 mishandle group empty matches, which might allow remote attackers to cause a denial of service (stack-based buffer overflow) via a crafted regular expression, as demonstrated by /^(?:(?(1)\\.|([^\\\\W])?)+)+$/.

Heap-based buffer overflow in PCRE 8.34 through 8.37 and PCRE2 10.10 allows remote attackers to execute arbitrary code via a crafted regular expression, as demonstrated by /^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/, a different vulnerability than CVE-2015-8384.

The compilebranch function in pcrecompile.c in PCRE 8.x before 8.39 and pcre2compile.c in PCRE2 before 10.22 mishandles patterns containing an (ACCEPT) substring in conjunction with nested parentheses, which allows remote attackers to execute arbitrary code or cause a denial of service (stack-based buffer overflow) via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror, aka ZDI-CAN-3542.

pcre2test.c in PCRE2 10.23 allows remote attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact via a crafted regular expression.

PCRE2 before 10.30 has an out-of-bounds write caused by a stack-based buffer overflow in pcre2match.c, related to a "pattern with very many captures."

An out-of-bounds read vulnerability was discovered in the PCRE2 library in the getrecursedatalength() function of the pcre2jitcompile.c file. This issue affects recursions in JIT-compiled regular expressions caused by duplicate data transfers.