Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-11T17:19:17.123Z",
  "pubdate": "2026-08-11T17:19:17.123Z",
  "executiveSummary": "Browserslist prior to version 4.28.7 suffers from an unbounded caching vulnerability in its query processing logic, classified as a Denial of Service (DoS) vector resulting in resource exhaustion.\nThe vulnerability allows an attacker capable of influencing repeated browserslist() query values, including valid since <year>-<month>-<day> queries, to bypass the caller-controlled BROWSERSLIST_DISABLE_CACHE mitigation.\nBy continuously supplying distinct query inputs, an attacker forces the application to retain every distinct (queries, context) result and every parseQueries() AST in memory without any size cap, Time-To-Live (TTL), or eviction policy.\nThis behavior leads to linear memory growth and ultimately results in an out-of-memory (OOM) process crash, disrupting availability for applications relying on the affected component.\nNo authentication or special privileges are required for exploitation, provided the attacker can interact with endpoints or build processes that consume unvalidated or attacker-controlled browser query strings.",
  "technicalDetails": "The root cause of the vulnerability resides in the caching mechanisms implemented within index.js and associated parsing logic of the Browserslist package.\nSpecifically, the application retains every distinct (queries, context) result in cache and every parseQueries() Abstract Syntax Tree (AST) generated by parseCache without implementing a maximum size restriction, TTL expiration, or cache eviction algorithm.\nThe vulnerable component is identified as index.js within versions prior to 4.28.7.\nDuring standard operation, queries processed by the library are cached to optimize performance; however, the absence of memory bounds enables unbounded state accumulation.\nFurthermore, the caching logic fails to respect or can be used to bypass the caller-controlled BROWSERSLIST_DISABLE_CACHE mitigation when arbitrary or distinct query values are supplied repeatedly.\nThe attack flow proceeds as follows: 1) An attacker crafts a sequence of distinct and unique browserslist query values, which may include valid since <year>-<month>-<day> query constructs. 2) The attacker submits these queries to the target application or build pipeline that executes the browserslist() function. 3) The vulnerable index.js component parses each unique query string, generates a new parseQueries() AST, executes the query against the context, and stores both the AST and the execution result in the respective internal caches (parseCache and results cache). 4) Because the caches lack eviction policies or size caps, memory consumption grows linearly with each unique query submitted. 5) Sustained submission of unique payloads exhausts available heap memory allocated to the Node.js process. 6) The Node.js runtime encounters an unrecoverable allocation failure, resulting in an out-of-memory (OOM) process crash and terminating the service or build execution."
}