CVE-2026-116795 in Re2js
Summary
by MITRE • 10/28/2026
RE2JS is the JavaScript port of RE2, a regular expression engine that provides linear time matching. From 2.2.0 until 2.8.7, enabling LOOKBEHINDS and using repeated matching through matcher().find(), matchAll(), split(), or matcher().replaceAll() can cause quadratic total work. Machine.match restarts lookbehind scanning from offset zero for each requested start position, while Matcher-based APIs request capture slots that prevent the early exit used for captureless matching. Dense matches therefore repeatedly rescan the input, allowing attacker-influenced text to monopolize a single-threaded worker and deny service. This issue is fixed in version 2.8.7.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified within RE2JS stems from an inefficient implementation of lookbehind assertions when combined with iterative matching operations such as find, matchAll, split, or replaceAll. RE2JS serves as the JavaScript port of Google's RE2 engine, which is designed to provide linear time complexity for regular expression matching by avoiding backtracking mechanisms common in traditional engines like PCRE. However, between versions 2.2.0 and 2.8.7, a specific flaw emerged when lookbehind assertions were enabled alongside repeated matching calls on the same input string with varying start positions or capture groups. This combination triggers a degradation from linear to quadratic time complexity relative to the length of the input text and the number of matches requested.
The technical root cause lies in how the engine handles state restoration during lookbehind scanning. When using Matcher-based APIs that request capture slots, the engine cannot utilize early exit optimizations available for captureless matching. Consequently, for each match attempt or start position specified by methods like matcher().find() or String.prototype.split(), the internal Machine.match function restarts the lookbehind scan from offset zero rather than leveraging previously computed states. This redundant rescanning means that dense matches result in repeated processing of identical input segments, effectively multiplying the computational work required for each subsequent match operation.
This behavior creates a significant Denial of Service risk when an attacker can influence or control the input text and the number of matching operations performed. By providing carefully crafted strings with high density of potential matches, an adversary can force the JavaScript engine to perform excessive computations on a single-threaded worker thread. Since JavaScript typically operates in a non-blocking but single-threaded manner for execution contexts, this quadratic workload monopolizes the event loop or worker resources, preventing other tasks from executing and leading to application unresponsiveness or complete service outage.
From an industry standard perspective, this vulnerability aligns with CWE-400: Uncontrolled Resource Consumption, specifically manifesting as a Regular Expression Denial of Service (ReDoS) scenario due to algorithmic complexity rather than backtracking loops. In the context of the MITRE ATT&CK framework, this exploitation technique falls under T1496: Resource Hijacking, where an attacker uses computing resources for their own purposes by causing excessive resource consumption that degrades service availability for legitimate users. The attack vector is primarily remote if the vulnerable regular expressions are applied to user-supplied data processed in a web server or client-side application context.
Mitigation strategies focus on upgrading to version 2.8.7 of RE2JS, which resolves this quadratic complexity issue by optimizing how lookbehind states are managed during iterative matching operations. For environments where immediate patching is not feasible, defensive coding practices should be employed to limit the length and complexity of regular expressions applied to untrusted input. Additionally, implementing timeouts or resource limits on regex execution can help mitigate the impact if vulnerable versions must remain in use temporarily. Developers should also audit codebases for patterns involving lookbehind assertions combined with global matching functions to identify potential exposure points before applying patches.