CVE-2026-73089: 
Grafana vulnerability analysis and mitigation

CVE-2026-73089 is an unbounded memory growth (no cache eviction) vulnerability in Browserslist, a widely used npm configuration tool for sharing target browser and Node.js version settings between front-end tools. Prior to version 4.28.7, index.js retains every distinct (queries, context) result in an unbounded cache object and every parseQueries() AST in an unbounded parseCache object, with no size cap, TTL, or eviction policy. An unauthenticated attacker who can influence repeated browserslist() query values — including valid since <year>-<month>-<day> queries — can cause linear memory growth leading to an out-of-memory (OOM) process crash. All versions up to and including 4.28.6 are affected; the issue was disclosed on August 11, 2026, and fixed in version 4.28.7 released July 21, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). In index.js, both cache (a plain object storing browserslist() results keyed by JSON.stringify([queries, context])) and parseCache (storing parseQueries() ASTs) grow without bound — there is no maximum entry count, TTL, or eviction mechanism. The browserslist.clearCaches() function only resets Node.js filesystem caches, not these in-memory objects, and the only opt-out (BROWSERSLIST_DISABLE_CACHE) is caller-controlled, not attacker-controlled. The since <year>-<month>-<day> query type is particularly effective for exploitation because Date.UTC() normalizes rather than rejects out-of-range values, providing an effectively unbounded space of ~17-byte distinct cache keys, each resolving to and caching a ~8.5 KB browser list result — measured at roughly 150x amplification (20,000 distinct queries retained over 50 MB of heap permanently) (GitHub Advisory, Fix Commit).

Successful exploitation results in a Denial of Service (DoS) via an out-of-memory process crash, affecting availability with no impact on confidentiality or integrity. Any long-running process — such as a server, daemon, or warm CI worker — that calls browserslist() with query values influenced by external input is at risk of accumulating unbounded heap memory until the Node.js process is killed by the OS OOM killer. The attack is volumetric in nature (requiring sustained traffic rather than a single request), but the low per-request cost and high amplification ratio (~150x) make it practical for an unauthenticated remote attacker to achieve service disruption (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is automatable (NVD SSVC: automatable=yes) and requires no authentication or user interaction, lowering the barrier for exploitation. The EPSS score is approximately 0.0036 (0.36%), reflecting low but non-zero probability of exploitation in the near term. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Identify a target: Locate a long-running Node.js server, daemon, or CI worker that calls browserslist() with query values that are partially or fully influenced by external input (e.g., a build service or API that accepts browser target configurations).
2. Craft distinct since queries: Prepare a large set of distinct, valid since <year>-<month>-<day> queries (e.g., since 1900-01-01, since 1900-01-02, ..., since 1900-01-N). Each query is ~17 bytes and resolves to a unique cache key.
3. Send repeated requests: Continuously submit these distinct queries to the target service over the network. Each unique query causes a new ~8.5 KB browser list result to be permanently retained in the in-memory cache and/or parseCache objects.
4. Exhaust memory: After approximately 20,000–40,000 distinct queries (~330 KB of total input), the process heap grows by 50+ MB with no eviction. Continue until the Node.js process is terminated by the OS OOM killer, causing a service crash (GitHub Advisory).

• Network: High volume of repeated HTTP requests to endpoints that accept browser target query parameters; requests containing since <year>-<month>-<day> patterns with incrementing or randomized date values.
• Process: Steadily increasing Node.js process heap memory usage over time with no corresponding increase in legitimate workload; eventual OOM kill signal (SIGKILL) or process crash logged by the process manager (e.g., PM2, systemd).
• Logs: Application logs showing a large number of distinct browserslist() invocations with varied since-style query strings; Node.js heap dump or --expose-gc measurements showing unbounded retained objects in cache or parseCache.
• System: OS-level OOM killer events in /var/log/kern.log or dmesg referencing the Node.js process; unexpected service restarts logged by the process supervisor.

The primary remediation is to upgrade Browserslist to version 4.28.7 or later, which replaces the unbounded plain-object caches with Map-based caches capped at 500 entries using an LRU-style eviction policy (GitHub Release, Fix Commit). As a short-term workaround prior to upgrading, applications can set the BROWSERSLIST_DISABLE_CACHE=1 environment variable to prevent caching entirely, at the cost of increased CPU usage for repeated queries. Additionally, implementing input validation to restrict the diversity of accepted browserslist() query values and applying network-level rate limiting can reduce exposure (GitHub Advisory).

Red Hat tracked the vulnerability as a high-severity issue in their Bugzilla system (Bug 2514195) and issued security advisories RHSA-2026:54517 and RHSA-2026:54518 for affected Red Hat products (Red Hat Bugzilla, Red Hat). The vulnerability was discovered and reported by researcher iaohkut-from-NightWolf-Team as part of a broader security review of the Browserslist codebase that also identified several other DoS vectors in the same research pass (GitHub Advisory). Tenable published a Nessus plugin (ID 334635) for detection, and AUSCERT issued bulletin ESB-2026.9567 covering the vulnerability.