chore(deps): update dependency browserslist to v4.28.7 [security] - #244
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
4.28.6→4.28.7Browserslist: Uncaught crash / prototype write via untrusted browserslist-stats.json custom stats (normalizeStats)
CVE-2026-73088 / GHSA-73wf-gq98-2v4g
More information
Details
Vulnerability Details
File:
node.jsFunction:
normalizeStats()(line ~214), reached fromgetStat()(calledunconditionally on every
browserslist()call) andloadStat()Root Cause
statsis untrusted: it comes fromJSON.parse()-ing abrowserslist-stats.jsonfile — auto-discovered by walking up the directorytree from the project root on every
browserslist()call, regardless ofthe query (
env.getStat(opts, browserslist.data)runs unconditionallyinside
browserslist()) — or fromopts.statspassed programmatically /via the CLI's
--stats=flag.dataisbrowserslist.data, a plain objectpopulated only with real browser names.
Two independent bugs from the same root cause (unguarded
for...inoveruntrusted keys used with plain-object bracket access/assignment):
data[i]has nohasOwnPropertyguard. Ifstatscontains akey that also happens to be an inherited
Object.prototypemember name —"__proto__","toString","valueOf","constructor","hasOwnProperty","isPrototypeOf", etc. —data[i]resolves to thatinherited function/object (always truthy), and the code then does
data[i].versions.length→undefined.length→ uncaughtTypeError,for any such key whose JSON value has exactly one sub-key, e.g.:
{ "toString": { "onekey": 5 }, "chrome": { "100": 50 } }normalized[i] = ...on the freshnormalized = {}— ifiis exactly"__proto__"(andnormalizedhasno own property by that name yet), this computed assignment invokes the
real
Object.prototype.__proto__setter, changingnormalized's actual[[Prototype]]instead of creating a plain property.Because this runs on every
browserslist()call regardless of thequery, simply committing a poisoned
browserslist-stats.jsonanywhere in aproject's directory tree breaks every subsequent Browserslist call in that
project — including calls made by Autoprefixer, Babel
preset-env,Stylelint, or PostCSS internally, for completely unrelated queries.
Attack Scenario
browserslist-stats.jsonfile anywhere between the project root andfilesystem root, containing e.g.
{"toString": {"onekey": 5}, "chrome": {"100": 50}}.browserslist()internally, for any query.
TypeErroron the very first call.Measured Impact
Confirmed crash (real
browserslist()call, v4.28.6) withstatskeys:__proto__,toString,valueOf,hasOwnProperty,constructor,isPrototypeOf— each paired with a one-key JSON object — for any query,including
browserslist('defaults')which never mentions stats.Recommended Fix (implemented and verified)
normalizedusesObject.create(null)so a write to"__proto__"is anordinary property set, never a
[[Prototype]]change;data[i]is replacedwith an explicit
hasOwnPropertycheck so it never resolves to an inheritedObject.prototypemember.Verification:
NODE_ENV=test npx uvu test .test.js→ 301/301 pass unmodified(
test/custom.test.js,test/shareable-stats.test.js,test/cover.test.jsexercise the stats-handling paths).
without error.
browserslist-stats.json+ an unrelatedbrowserslist('defaults')call)now returns a normal result instead of crashing.
Impact
(directly or via Autoprefixer/Babel/Stylelint/PostCSS) in a directory tree
an attacker can place a file into (external PR, compromised dependency),
or any app that passes user-influenced data into
opts.stats.process on the first Browserslist call after the file is present, for any
query, no special syntax needed.
file to the project's directory tree, or influence
opts.stats.Verification Environment
browserslist @ HEAD (== v4.28.6, current latest stable release) under local
Node.js v20.19.5. Pure JS library — executed directly, no server needed.
Note
Found via a systematic review of prototype-pollution-adjacent patterns in
this codebase after confirming two unrelated algorithmic-complexity issues
(reported separately as GHSA-rrmg-cfrq-23vv and GHSA-g6p8-hj8g-x889) in the
same research pass. A similar
for...in+ bracket-write pattern inindex.js'scopyObject()(used bynormalizeAndroidData) was alreadyguarded against
__proto__/constructor/prototypekeys by a prior,unrelated commit — that guard was never applied to this function.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Browserslist: Unbounded memory growth (no cache eviction) via distinct query results, leading to eventual OOM
CVE-2026-73089 / GHSA-c83g-rgw3-j3cx
More information
Details
Vulnerability Details
File:
index.jsLocation:
cache(browserslist()'s result cache, line ~402) andparseCache(parseQueries()'s AST cache)Root Cause
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 theBROWSERSLIST_DISABLE_CACHEenv var, controlled by the callingapplication, not an attacker.
Some short, valid queries amplify this badly. The
since <year>-<month>-<day>query type (
/^since (\d+)-(\d+)-(\d+)$/i) accepts any digitcombination —
Date.UTC()normalizes rather than rejects out-of-rangevalues — 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-gcbefore/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 isinfluenced, even partially, by external input accumulates one cache entry
per distinct value ever seen. An attacker who can influence that value
across many 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.
since 1900-01-01,since 1900-01-02, ...)until the process runs out of memory and crashes.
Recommended Fix (implemented and verified)
Replace both plain-object caches with
Maps bounded to a fixed maximumentry count, evicting the oldest entry once the cap is reached (
Mappreserves insertion order, so
.keys().next().valueis always oldest):(read sites changed to
.has()/.get(), write sites toboundedCacheSet())Verification:
NODE_ENV=test npx uvu test .test.js→ 301/301 pass unmodified(
test/cache.test.jsexercisesclearCaches()/BROWSERSLIST_DISABLE_CACHEagainst
node.js's separate filesystem caches, unaffected here); confirmeda repeated identical call still returns the cached reference.
10,000, 20,000, and 40,000 distinct
since-date queries (was10.5 → 16.5 → 28.4 → 52.3 MB pre-fix).
Impact
browserslist()withquery values that vary across requests/items and are influenced by
external input.
sustained traffic over time (not a single small payload).
single request, hence Medium rather than High severity.
Verification Environment
browserslist @ HEAD (== v4.28.6, current latest stable release) under local
Node.js v20.19.5, run with
--expose-gcfor accurate heap measurement.Note
Found during a broader review of this codebase in the same research pass
that produced GHSA-rrmg-cfrq-23vv (parse.js algorithmic complexity),
GHSA-g6p8-hj8g-x889 (baseline regexp ReDoS), GHSA-73wf-gq98-2v4g
(normalizeStats crash/prototype write), and GHSA-h633-868p-5rfw
(SCOPED_CONFIG__PATTERN ReDoS) — all single-request DoS vectors. This one is
different in character (volumetric, not single-request) and is reported
separately/scored lower accordingly.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
browserslist/browserslist (browserslist)
v4.28.7Compare Source
Configuration
📅 Schedule: (in timezone Asia/Tokyo)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.