Browserslist: Unbounded memory growth (no cache eviction) via distinct query results, leading to eventual OOM

Vulnerability Details

File: index.js Location: cache (browserslist()'s result cache, line ~402) and parseCache (parseQueries()'s AST cache)

Root Cause

var cache = {}
var parseCache = {}

function browserslist(queries, opts) {
  ...
  var cacheKey = JSON.stringify([queries, context])
  if (cache[cacheKey]) return cache[cacheKey]
  ...
  if (!env.env.BROWSERSLIST_DISABLE_CACHE) { cache[cacheKey] = result }
  return result
}

function parseQueries(queries) {
  var cacheKey = JSON.stringify(queries)
  if (cacheKey in parseCache) return parseCache[cacheKey]
  var result = parseWithoutCache(QUERIES, queries)
  if (!env.env.BROWSERSLIST_DISABLE_CACHE) { parseCache[cacheKey] = result }
  ...
}

Every distinct (queries, context) pair is cached forever — no size cap, TTL, or eviction. browserslist.clearCaches() never resets either object (it only resets node.js's own filesystem caches); the only opt-out is the BROWSERSLIST_DISABLE_CACHE env var, controlled by the calling application, not an attacker.

Some short, valid queries amplify this badly. The since <year>-<month>-<day> query type (/^since (\d+)-(\d+)-(\d+)$/i) accepts any digit combination — Date.UTC() normalizes rather than rejects out-of-range values — giving an effectively unbounded space of ~17-byte distinct cache keys, each of which resolves to (and caches) a result close to the full ~8.5 KB browser list for any sufficiently old year.

Measured Impact

20,000 distinct since <year>-<month>-<day> queries (~330 KB total input, --expose-gc before/after measurement to rule out uncollected garbage) retained over 50 MB of heap permanently — roughly 150x amplification, growing linearly with no cap observed up to 40,000 queries (52.3 MB).

Attack Scenario

Any long-running process (server, daemon, warm CI worker) that calls browserslist() with a query value that varies across requests/items and is influenced, even partially, by external input accumulates one cache entry per distinct value ever seen. An attacker who can influence that value across requests (this is a volumetric attack, unlike the single-request DoS findings from this same research pass) sends a stream of cheap, distinct queries (e.g. , , ...) until the process runs out of memory and crashes.