CVE-2026-77299: 
Grafana vulnerability analysis and mitigation

CVE-2026-77299 is a Denial of Service vulnerability in regexp2, a feature-rich RegExp engine for Go maintained by dlclark. When the library compiles and matches a pattern containing a large fixed-count quantifier applied to a zero-width subexpression (e.g., (?:){50000000}), the match engine pushes two integers onto the backtracking stack on every iteration without bound, enabling multi-gigabyte memory allocation from a sub-20-byte pattern. All versions prior to 2.3.0 are affected. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat).

The root cause (CWE-400, CWE-770) lies in how the bytecode writer initializes the loop counter for a counted loop X{m} to 1-m, while the runtime Branchcount handler only short-circuits an empty-body iteration once the counter climbs back to >= 0. For a zero-width subexpression, this means m-1 iterations each call trackPush1, writing two integers onto runtrack, which grows by doubling with no upper bound. The parser accepts repetition counts up to math.MaxInt32, so a pattern like (?:){2000000000} (18 bytes) can drive allocation past 60 GiB. The existing MatchTimeout mitigation is ineffective because tens of millions of empty-loop iterations — consuming hundreds of MiB — execute between consecutive 100 ms clock ticks, and the inflated runtrack slice is retained in the per-Regexp runner pool, compounding memory pressure across concurrent matches (GitHub Advisory, Red Hat Bugzilla).

Successful exploitation causes the target process to exhaust available memory and be OOM-killed, resulting in a complete denial of service. A pattern of fewer than 20 bytes matched against an empty input is sufficient — (?:){50000000} allocates approximately 2.5 GiB in ~3 seconds on a standard Linux/amd64 host, and larger values within math.MaxInt32 can exceed 60 GiB. Any application that accepts untrusted regular expression patterns (e.g., user-defined search filters, log-pipeline extraction rules, routing/rewrite rules, or config-file-populated *regexp2.Regexp fields) is at risk; applications that only compile hard-coded patterns and expose only the input string to attackers are not affected (GitHub Advisory).

There is no evidence of active in-the-wild exploitation or a publicly available weaponized exploit kit at this time. A proof-of-concept is included in the GitHub Security Advisory itself, demonstrating the attack with a minimal Go program using regexp2@v1.12.0. The vulnerability requires no authentication, no privileges, and no user interaction — an unauthenticated remote attacker who can supply a pattern string to an affected application can trigger the condition. No CISA KEV listing or threat actor attribution has been reported (GitHub Advisory, Feedly).

1. Identify a target: Find an application that uses github.com/dlclark/regexp2 versions prior to 2.3.0 and accepts user-supplied regular expression patterns (e.g., a search API, log filter configuration endpoint, or YAML/JSON config parser).
2. Craft a malicious pattern: Construct a short pattern using a large fixed-count quantifier on a zero-width subexpression, such as (?:){50000000} (14 bytes) or (?:){2000000000} (18 bytes). Equivalent variants include (){m}, (?:\b){m}, and (?:|){m}.
3. Submit the pattern: Send the crafted pattern to the target application via the relevant input channel (HTTP request body, query parameter, configuration file field, etc.).
4. Trigger memory exhaustion: The regexp2 engine begins executing the empty loop body, pushing two integers onto the backtracking stack per iteration. Memory grows unboundedly — (?:){50000000} allocates ~2.5 GiB in ~3 seconds — before any timeout can fire.
5. Achieve denial of service: The process is OOM-killed by the operating system, taking down the application (GitHub Advisory).

• Logs: Application crash logs or OS-level OOM killer messages (e.g., kernel: Out of memory: Kill process <pid>) coinciding with regexp compilation or matching operations.
• Process Behavior: Sudden spike in memory consumption by the Go application process immediately before termination; process restart events in service managers (systemd, Kubernetes pod restarts).
• Application Logs: Log entries showing receipt of unusually short regex pattern strings (under 20 bytes) containing high-count quantifiers such as {50000000} or similar large integers applied to zero-width groups like (?:), (), or (?:|).
• Network: HTTP requests or API calls containing pattern parameters with strings matching the form (?:){<large_integer>}, (){<large_integer>}, or (?:\b){<large_integer>} (GitHub Advisory).

Upgrade github.com/dlclark/regexp2 to version 2.3.0 or later, which introduces a default backtracking stack limit of 100,000 integer slots per match; patterns exceeding this limit return ErrBacktrackingStackLimit instead of allocating unbounded memory (GitHub Release, GitHub Commit). The limit can be tuned at compile time using regexp2.OptionMaxBacktrackingStackSize(n); a negative value restores the previous unbounded behavior. As a defense-in-depth measure, applications should validate and reject untrusted regex patterns before passing them to the engine, and implement application-level resource limits on pattern compilation. Note that MatchTimeout alone is not a sufficient workaround (GitHub Advisory).

The vulnerability was reported by researcher KrisKennawayDD and published by the library maintainer dlclark on July 11, 2026 via a GitHub Security Advisory. Red Hat tracked the issue in Bugzilla (Bug 2568017) with high priority and severity, with 65 users CC'd, indicating broad downstream concern across Red Hat products. Social media activity was observed on Mastodon (infosec.exchange) and Bluesky shortly after disclosure (GitHub Advisory, Red Hat Bugzilla).