CVE-2026-73089 in Browserslist
Summary
by MITRE • 08/12/2026
Browserslist is a configuration tool for sharing target browsers and Node.js versions between front-end tools. Prior to 4.28.7, index.js retains every distinct `(queries, context)` result in cache and every parseQueries() AST in parseCache without a size cap, TTL, or eviction, allowing an attacker who can influence repeated browserslist() query values, including valid since `<year>-<month>-<day>` queries, to bypass the caller-controlled BROWSERSLIST_DISABLE_CACHE mitigation and cause linear memory growth followed by an out-of-memory process crash. This issue is fixed in version 4.28.7.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/12/2026
The browserslist library serves as a critical configuration tool that bridges front-end development tools with target browser specifications and Node.js versions, making it an essential component in modern web development workflows. The vulnerability resides in the caching mechanism of the index.js file where every distinct `(queries, context)` result is retained indefinitely in memory without any size limitations or time-based expiration policies. This fundamental flaw creates a persistent memory leak condition that becomes particularly dangerous when attackers can influence repeated browserslist() query values through controlled inputs.
The technical implementation of this vulnerability stems from the parseQueries() function which maintains an AST (Abstract Syntax Tree) cache within parseCache without implementing any eviction strategies or capacity constraints. When valid date-based queries such as `<year>-<month>-<day>` are repeatedly submitted by an attacker, the system accumulates cache entries exponentially, leading to linear memory consumption growth that eventually exhausts available process memory resources. This attack vector specifically exploits the absence of BROWSERSLIST_DISABLE_CACHE mitigation effectiveness when query values are under attacker control, rendering the intended protection mechanism ineffective.
The operational impact of this vulnerability manifests as predictable denial-of-service conditions where an attacker can systematically consume all available memory through carefully crafted browserslist queries, resulting in process crashes and service unavailability. The memory growth pattern follows a linear trajectory that makes it particularly insidious since the resource consumption increases proportionally with the number of malicious queries submitted. This vulnerability directly maps to CWE-400, which addresses unspecified resource exhaustion issues, and can be categorized under ATT&CK technique T1499.200 as a resource exhaustion attack targeting application memory.
Security mitigations for this vulnerability involve implementing proper cache size limits with time-based expiration policies or least recently used eviction strategies within the browserslist library. The fix released in version 4.28.7 addresses the core issue by introducing bounded caching mechanisms that prevent indefinite accumulation of query results and parse AST entries. Organizations should also implement input validation and rate limiting for browserslist query processing, while monitoring memory consumption patterns in applications that utilize this library. Additionally, developers should ensure proper configuration of environment variables and consider implementing custom cache management strategies when deploying browserslist in high-security or resource-constrained environments to prevent similar memory exhaustion scenarios from occurring in other components utilizing similar caching patterns.