CVE-2026-87722: Regular Expression Denial of Service (ReDoS) in Search Query Predicates and REST Filter Endpoints in Gerrit Code Review
Uncontrolled Resource Consumption (CWE-400 / CWE-1333) in regex search query predicates (such as RegexProjectPredicate, RegexRefPredicate, RegexPathPredicate, and sibling predicates) and REST regex filter endpoints (RegexListSearcher /projects/?r= and RefFilter /projects/{project}/branches/?r=) in Gerrit Code Review versions 2.1.6 through 3.12.9, 3.13.0 through 3.13.8, and 3.14.0 through 3.14.2 allows an unauthenticated remote attacker (or an authenticated user if anonymous read access is disabled) to cause a denial of service (CPU starvation and JVM heap exhaustion / OutOfMemoryError) via crafted search queries or REST API requests containing regular expressions with large counted repetitions or exponential DFA determinization patterns. Because the user-supplied regular expression is compiled into an unbounded dk.brics.automaton instance (new RegExp(re).toAutomaton()) on the request thread prior to index evaluation or access control visibility filtering, trivial queries can exhaust JVM heap or pin request threads regardless of heap size. This issue is fixed in Gerrit Code Review versions 3.12.10, 3.13.9, and 3.14.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Gerrit Code Reviewto a version that resolves this vulnerability.Fixed in 3.12.10 - Upgrade
Upgrade
Gerrit Code Reviewto a version that resolves this vulnerability.Fixed in 3.13.9 - Upgrade
Upgrade
Gerrit Code Reviewto a version that resolves this vulnerability.Fixed in 3.14.3
Event History
Frequently Asked Questions
Who can exploit this issue in a typical deployment?
An unauthenticated remote attacker can exploit it when anonymous read access is enabled. If anonymous read access is disabled, an authenticated user can still trigger it.
Are requests limited to repositories or refs the attacker can access?
No. The supplied regular expression is compiled on the request thread before index evaluation and access-control visibility filtering, so resource exhaustion can occur regardless of whether the attacker can view matching projects, refs, or paths.
What request types should be monitored for exploitation attempts?
Monitor search queries using regex predicates, including project, ref, and path predicates, and REST requests to /projects/?r= and /projects/{project}/branches/?r=. Suspicious inputs include expressions with very large counted repetitions or patterns that cause exponential DFA determinization.
What versions remediate the issue?
Upgrade to Gerrit Code Review 3.12.10, 3.13.9, or 3.14.3. The affected ranges are 2.1.6 through 3.12.9, 3.13.0 through 3.13.8, and 3.14.0 through 3.14.2.