Description

PCRE2 before 10.48 allows a pcre2_dfa_match out-of-bounds write because reuse of a cached workspace block, in a recursive DFA matching workspace, lacks a size check (even though a newly allocated block, for the same purpose, does have a size check). This outcome requires an attacker-controlled regular expression, or a recursive pattern in conjunction with a small heap limit (this can be set through the API).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-09-05T06:17:10.370Z",
  "pubdate": "2026-09-05T06:17:10.370Z",
  "executiveSummary": "PCRE2 versions prior to 10.48 are susceptible to an out-of-bounds write vulnerability within the pcre2_dfa_match function.\nThe vulnerability arises from an inconsistent validation check when reusing cached workspace memory blocks during recursive DFA matching operations.\nAn attacker can exploit this flaw by providing a crafted regular expression or by utilizing recursive patterns in environments where heap memory limits are constrained via the API.\nSuccessful exploitation may lead to memory corruption, potentially allowing arbitrary code execution or denial-of-service conditions, depending on the memory layout and application context.\nThe risk is elevated in applications that process untrusted regex patterns or expose DFA matching functionality to external inputs.\nThe primary requirement for exploitation involves influencing the DFA workspace allocation behavior through pattern structure or heap limit configurations.",
  "technicalDetails": "The vulnerability is localized within the pcre2_dfa_match function, specifically concerning the management of workspace blocks allocated for recursive DFA matching.\nIn PCRE2's architectural implementation, when a workspace block is newly allocated, the internal logic performs a mandatory size check to ensure the block is sufficient for the pending operation. However, when the system opts to reuse a cached workspace block for a recursive DFA match, this crucial bounds verification is omitted.\nThe root cause is an implementation inconsistency: the re-allocation logic fails to validate that the pre-existing, cached workspace memory provides adequate space for the recursion depth or internal state requirements demanded by the current operation.\nAn attacker can trigger this vulnerability by carefully constructing a regular expression or utilizing recursive patterns that force the DFA engine to exceed the buffer boundaries of the cached workspace block.\nThe exploit path is facilitated in scenarios where an application allows an attacker to set or manipulate heap limits via the PCRE2 API. By setting a small heap limit, an attacker increases the likelihood of forcing the engine into a state where it relies on smaller, cached workspace buffers that can be overrun.\nDuring execution, if the DFA engine enters a recursive state using a cached block, the lack of a size check leads to a heap-based out-of-bounds write. This allows the process to write data beyond the allocated buffer, potentially overwriting adjacent memory structures.\nThe impact of this overwrite depends heavily on the memory layout of the host application; it could result in the corruption of critical function pointers, heap metadata, or application-specific variables, leading to arbitrary code execution if controlled input is placed at the appropriate memory offset.\nAlternatively, if the out-of-bounds write targets sensitive structures, it can lead to an immediate crash, resulting in a denial-of-service (DoS) condition.\nThis vulnerability does not require authentication to trigger if the interface is exposed; however, the attacker needs the ability to influence the pattern compilation or execution parameters (e.g., heap limits) within the target application's implementation of the PCRE2 library."
}