CVE-2026-73089

## Vulnerability Details **File**: `index.js` **Location**: `cache` (browserslist()'s result cache, line ~402) and `parseCache` (parseQueries()'s AST cache) ### Root Cause ```js 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 accumula