Affected: CleanStart: argo-workflows

Security vulnerability affects the argo-workflows package. Browserslist is a configuration tool for sharing target browsers and Node.

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.

Affected: npm: browserslist

## 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…

agama-web-ui-24+0.a836cced5-52.1 on GA media

fast-uri: Fast-uri: Security policy bypass due to URL parsing inconsistency baseline-browser-mapping: baseline-browser-mapping: Denial of Service via improper input handling DOMPurify: DOMPurify: Cross-Site Scripting via unsanitized DOM elements from different realms DOMPurify: DOMPurify: Cross-site scripting due to state leakage in sanitization. dompurify: DOMPurify: URI validation bypass leads to cross-site scripting dompurify: DOMPurify: Cross-Site Scripting (XSS) via prototype pollution in USE_PROFILES mode dompurify: DOMPurify: Cross-Site Scripting vulnerability allows arbitrary code execution browserslist: Browserslist: Prototype pollution leading to denial of service browserslist: Browserslist: Denial of Service via unbounded memory growth from distinct query results

Affected: Ubuntu:18.04:LTS: node-browserslist, Ubuntu:20.04:LTS: node-browserslist, Ubuntu:22.04:LTS: node-browserslist, Ubuntu:24.04:LTS: node-browserslist, Ubuntu:26.04:LTS: node-browserslist

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.

Ein Angreifer kann mehrere Schwachstellen in Atlassian Bamboo, Bitbucket, Confluence, Fisheye/Crucible, Jira Software und Jira Service Management ausnutzen, um beliebigen Programmcode auszuführen, Sicherheitsmaßnahmen zu umgehen, serverseitige Request-Forgery-Angriffe (SSRF) durchzuführen, Cross-Site-Scripting-Angriffe zu starten, sensible Informationen offenzulegen, Daten zu manipulieren oder Denial-of-Service-Zustände herbeizuführen.