CVE-2026-86145 in PCRE2
Summary
by MITRE • 09/05/2026
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).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The Perl Compatible Regular Expressions version 2 library contains a critical memory corruption vulnerability within its depth-first search matching engine. Specifically identified as CVE-2024-7264, this flaw resides in the pcre2_dfa_match function and stems from an improper handling of cached workspace blocks during recursive pattern evaluation. The PCRE2 library is widely deployed across numerous open-source projects and commercial applications for high-performance text processing, making vulnerabilities within its core matching logic particularly impactful to the broader software ecosystem.
The technical root cause involves a discrepancy in size validation between two code paths used for managing memory allocation during regex execution. When performing recursive DFA matching, the engine utilizes a workspace block to store intermediate states. If this workspace needs to be expanded or reused, the library attempts to reuse an existing cached block rather than allocating new memory. While newly allocated blocks undergo rigorous boundary checks to ensure they are large enough for the required data, the logic governing the reuse of these cached blocks omits this critical size verification step. Consequently, if a crafted regular expression triggers deep recursion that exceeds the capacity of the reused cache slot, the engine proceeds to write beyond the bounds of the allocated memory region without triggering an error or exception.
This out-of-bounds write condition allows for arbitrary memory modification under specific conditions. An attacker must supply a maliciously constructed regular expression designed to exploit this recursive depth limitation. The vulnerability is further exacerbated when the application has configured a small heap limit via the PCRE2 API, which restricts the available workspace size and makes it easier for the crafted input to overflow the cached buffer boundaries. This scenario transforms what might otherwise be a denial-of-service issue into a potential code execution vector, depending on how the surrounding memory layout is structured by the host application.
From an operational perspective, this vulnerability poses severe risks including remote code execution, privilege escalation, and service disruption. If the vulnerable PCRE2 library is integrated into a web server or network-facing application that processes user-supplied input as part of regular expression matching logic, an attacker can trigger the flaw remotely by sending specially crafted HTTP requests containing malicious regex patterns. The resulting memory corruption can lead to immediate application crashes causing denial of service, or more critically, allow attackers to overwrite function pointers and return addresses on the heap, thereby gaining control over program execution flow.
The vulnerability aligns with CWE-787 Out-of-bounds Write in the Common Weakness Enumeration taxonomy, reflecting the fundamental failure to validate memory access boundaries during buffer operations. In terms of tactical classification under MITRE ATT&CK, this flaw facilitates Initial Access and Execution techniques where attackers leverage software vulnerabilities to execute arbitrary code on targeted systems. The reliance on attacker-controlled regular expressions places it within the category of input validation failures that lead to memory safety violations.
Mitigation strategies primarily involve upgrading to PCRE2 version 10.48 or later, which includes patches for this specific logic error in the workspace reuse mechanism. Organizations relying on static analysis tools should ensure their scanners are updated to detect similar patterns of unchecked buffer reuse in C/C++ codebases. For applications where immediate patching is not feasible, implementing strict input sanitization to prevent complex recursive regex patterns from reaching the matching engine can provide a layer of defense-in-depth. Additionally, configuring heap limits appropriately and enabling Address Sanitizer during development phases can help identify such memory safety issues before deployment in production environments.