Amin Alemi

**Name of the Vulnerable Software and Affected Versions** Gerrit Code Review versions 2.0.19 through 3.12.9 Gerrit Code Review versions 3.13.0 through 3.13.8 Gerrit Code Review versions 3.14.0 through 3.14.2 **Description** Uncontrolled resource consumption in the ANTLR 3 search query parser (QueryParser / Query.g) allows an unauthenticated remote attacker or an authenticated user to cause a persistent denial of service. This occurs via crafted search queries containing deeply nested parentheses sent to the following endpoints: '/changes/?q=', '/accounts/?q=', '/groups/?query=', '/projects/?query=', '/Documentation/?q=', '/changes/{id}/query?expression=', or SSH gerrit query. The issue stems from syntactic predicates in `conditionOr` and `conditionAnd` that recurse via `conditionBase` without memoization—a technique used to store results of expensive function calls to avoid redundant computations—prior to capability or visibility checks. Because worker threads do not abort upon client disconnection, a small number of requests can exhaust the CPU and starve the HTTP worker thread pool, requiring a server restart. **Recommendations** Update Gerrit Code Review versions 2.0.19 through 3.12.9 to version 3.12.10. Update Gerrit Code Review versions 3.13.0 through 3.13.8 to version 3.13.9. Update Gerrit Code Review versions 3.14.0 through 3.14.2 to version 3.14.3.

**Name of the Vulnerable Software and Affected Versions** Gerrit Code Review versions 2.1.6 through 3.12.9 Gerrit Code Review versions 3.13.0 through 3.13.8 Gerrit Code Review versions 3.14.0 through 3.14.2 **Description** Uncontrolled resource consumption occurs in regex search query predicates, including `RegexProjectPredicate`, `RegexRefPredicate`, and `RegexPathPredicate`, as well as REST regex filter endpoints '/projects/?r=' and '/projects/{project}/branches/?r='. An unauthenticated remote attacker or an authenticated user can cause a denial of service resulting in CPU starvation and JVM heap exhaustion (OutOfMemoryError) by submitting crafted search queries or REST API requests. The issue arises because user-supplied regular expressions are compiled into an unbounded `dk.brics.automaton` instance via the `new RegExp(re).toAutomaton()` function on the request thread before index evaluation or access control filtering. This allows regular expressions with exponential DFA determinization patterns or large counted repetitions to exhaust the JVM heap or pin request threads. **Recommendations** Update Gerrit Code Review versions 2.1.6 through 3.12.9 to version 3.12.10. Update Gerrit Code Review versions 3.13.0 through 3.13.8 to version 3.13.9. Update Gerrit Code Review versions 3.14.0 through 3.14.2 to version 3.14.3.