Browserslist EUVD-2026-56600

Exploitation requires that an attacker can supply or influence the query string arguments passed to the browserslist() function within a running Node.js process at runtime - for example, through an HTTP API parameter, a WebSocket message, or any other externally-reachable code path that forwards input into browserslist() without sanitization. The since <year>-<month>-<day> date-based query format is specifically exploitable because it generates an effectively unbounded key space from syntactically valid queries. Exploitation is categorically NOT possible when browserslist is invoked exclusively at build time with static configuration strings (e.g., .browserslistrc files read during a webpack or Babel compilation step), which is the dominant usage pattern across the npm ecosystem. Defenders who set BROWSERSLIST_DISABLE_CACHE=true believing it fully disables caching remain exposed to the parseCache growth vector. Authentication is not required per CVSS PR:N in deployments where the vulnerable code path is externally reachable without credentials.

The NVD-assigned CVSS of 7.5 (AV:N/AC:L/PR:N/UI:N/A:H) reflects the maximum theoretical risk surface and overstates real-world exploitability for most deployments. Browserslist is overwhelmingly consumed as a build-time dependency with static configuration strings - a deployment pattern that provides zero attack surface because no external input ever reaches browserslist() at runtime. The actual risk is concentrated in the narrow subset of applications that invoke browserslist() at runtime with externally-controlled query arguments (e.g., an HTTP API that accepts per-request browser targeting). The BROWSERSLIST_DISABLE_CACHE bypass is a secondary risk signal: organizations that deployed this environment variable as a compensating control believing it disabled all caching remain exposed to parseCache growth. No CISA KEV listing exists, no public exploit has been identified, and EPSS data was not provided - collectively these signals suggest this has not seen active exploitation and likely requires targeted abuse of a specific application architecture rather than broad opportunistic scanning. This is a genuine priority for runtime-exposure deployments but effectively negligible for build-only usage.

An attacker who discovers an HTTP API endpoint that accepts browser targeting parameters and passes them to browserslist() at runtime sends thousands of requests with unique since 1990-01-<incrementing-day> query strings, each generating a distinct cache key that causes both the result cache and parseCache to grow. With no eviction boundary in versions before 4.28.7, Node.js heap grows linearly with each unique query until the process is terminated by the operating system or Node.js runtime with an out-of-memory error, resulting in service unavailability. No public proof-of-concept code has been identified, but the attack is mechanically trivial to construct from the public advisory description alone.