Browserslist (<= 4.28.6) - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/browserslist--4.28.6/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 01 Sep 2026 18:00:21 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgBrowserslist Unbounded Memory Growth via Cache Exhaustionhttps://feed.craftedsignal.io/briefs/2026-09-browserslist-oom/Tue, 01 Sep 2026 18:00:21 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-browserslist-oom/The Browserslist package is vulnerable to a volumetric denial-of-service attack due to a missing cache eviction policy in its internal query result storage, leading to unbounded heap growth and potential OOM crashes in long-running processes.The Browserslist package (up to and including v4.28.6) contains a memory management vulnerability in its internal query and parse caches. The application maintains two objects, cache and parseCache, which store results indexed by query keys generated via JSON.stringify(). These caches lack size constraints, time-to-live (TTL) policies, or eviction mechanisms, and are not cleared by the browserslist.clearCaches() function.

In long-running Node.js processes such as web servers or CI workers, an attacker who can influence the query strings passed to browserslist() can cause unbounded memory growth. Specifically, the since <year>-<month>-<day> query pattern allows for a large space of valid, distinct keys. By sending a high volume of unique requests, an attacker can force the accumulation of cache entries until the process exhausts available heap memory, resulting in an out-of-memory (OOM) crash. Analysis showed an approximately 150x memory amplification factor, where 20,000 distinct queries consumed over 50 MB of permanent heap space.

Attack Chain

  1. Attacker identifies a target application utilizing Browserslist in a long-running process (e.g., web server or CI pipeline) that accepts user-influenced input for browser queries.
  2. Attacker crafts a series of distinct, syntactically valid since <year>-<month>-<day> query strings.
  3. Attacker sends a high volume of requests to the target, each containing a unique date variation to ensure the cache key is novel.
  4. The target application passes these queries to the browserslist() function.
  5. The library generates a unique cacheKey using JSON.stringify() for each request.
  6. Browserslist stores the resulting data in the unbounded cache and parseCache objects.
  7. Memory usage of the process grows linearly with the number of unique queries.
  8. Upon reaching memory limits, the process crashes due to an OOM condition, resulting in a denial-of-service.

Impact

Successful exploitation results in a denial-of-service via process termination. This vulnerability impacts long-running Node.js applications that process external inputs influencing browser queries. The attack requires a sustained, high-volume request stream rather than a single malicious payload, which characterizes it as a volumetric DoS.

Recommendation

  1. Upgrade the browserslist package to a version that implements the bounded cache fix (e.g., > 4.28.6).
  2. If an immediate upgrade is not possible, review application code to identify if user input influences browserslist() calls and implement an application-layer cache proxy or query validation to restrict the variety of permitted query strings.
  3. Ensure that if BROWSERSLIST_DISABLE_CACHE is used as a workaround, the impact on performance is measured against the expected request load.
]]>lowadvisorydenial-of-servicememory-exhaustionjavascriptnodejsvulnerabilityprototype-pollutionsupply-chain