Gerrit Code Review CVE-2026-87722

Exploitable by sending crafted regex search queries or REST API requests to Gerrit's regex filter endpoints - specifically RegexListSearcher (/projects/?r=) and RefFilter (/projects/{project}/branches/?r=) - or via regex search predicates (RegexProjectPredicate, RegexRefPredicate, RegexPathPredicate and siblings), using patterns with large counted repetitions or exponential DFA-determinization behavior. No special server configuration is needed beyond a reachable Gerrit instance running an affected version (2.1.6-3.12.9, 3.13.0-3.13.8, or 3.14.0-3.14.2). The key limiting factor is authentication posture: exploitation is fully unauthenticated ONLY when anonymous read access is enabled; if anonymous read is disabled, an authenticated user account is required. Because the malicious regex is compiled before access-control visibility filtering, no project-level read permission to specific repositories is needed for the resource-exhaustion to occur.

This is a genuinely high-priority DoS. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H, 8.7 HIGH) aligns cleanly with the description: a network-reachable, low-complexity, unauthenticated request produces high availability impact and no confidentiality/integrity impact - a textbook uncontrolled-resource-consumption/ReDoS profile. The mechanism is credible and severe because the user-supplied regex is compiled into an unbounded dk.brics.automaton (new RegExp(re).toAutomaton()) on the request thread BEFORE index evaluation or access-control visibility filtering, so a trivial crafted query can pin threads or trigger OutOfMemoryError regardless of heap sizing - this is why AC:L and VA:H are justified rather than inflated. Counterbalancing signals: no EPSS score, no CISA KEV listing, and no public exploit are present in the input, so there is no evidence of active exploitation - the priority derives from reachability and ease, not observed attacks. One conditional to note: PR:N (unauthenticated) holds only when anonymous read access is enabled; if anonymous read is disabled, an authenticated user is required, effectively raising the privilege bar to PR:L for those deployments - the vector does not capture this deployment split, so defenders should verify their anonymous-access configuration.

An unauthenticated attacker (against a Gerrit instance with anonymous read enabled) sends a single crafted REST request such as GET /projects/?r=<malicious-regex> or a search query using a regex predicate, embedding a pattern with large counted repetitions or exponential DFA-determinization behavior. Gerrit compiles the regex into an unbounded automaton on the request thread before any access-control check, exhausting JVM heap (OutOfMemoryError) or pinning CPU, taking the service down. No public exploit code is identified in the input, but the attack requires only trivial HTTP requests and no authentication in default anonymous-read setups.