🔒 Dependency Dashboard #2
Labels
No labels
dependabork
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Headscracher/review-gate#2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
🔒 Dependency Dashboard (20)
17 unknown · 2 high · 1 moderate
atk 0.18.2 — gtk-rs GTK3 bindings - no longer maintained
The gtk-rs GTK3 bindings are no longer maintained.
The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.
Please take a look at gtk4-rs instead.
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/atk-sys · https://rustsec.org/advisories/RUSTSEC-2024-0416.html · https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6
gdk 0.18.2 — gtk-rs GTK3 bindings - no longer maintained
The gtk-rs GTK3 bindings are no longer maintained.
The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.
Please take a look at gtk4-rs instead.
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/gdk-sys · https://rustsec.org/advisories/RUSTSEC-2024-0418.html · https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6
gdkwayland-sys 0.18.2 — gtk-rs GTK3 bindings - no longer maintained
The gtk-rs GTK3 bindings are no longer maintained.
The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.
Please take a look at gtk4-rs instead.
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/gdkx11 · https://rustsec.org/advisories/RUSTSEC-2024-0417.html · https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6
gdkx11-sys 0.18.2 — gtk-rs GTK3 bindings - no longer maintained
The gtk-rs GTK3 bindings are no longer maintained.
The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.
Please take a look at gtk4-rs instead.
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/gtk · https://rustsec.org/advisories/RUSTSEC-2024-0415.html · https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6
gtk-sys 0.18.2 — gtk-rs GTK3 bindings - no longer maintained
The gtk-rs GTK3 bindings are no longer maintained.
The maintainers have archived the repository, and added a note to the crate
description and its README.md that the crates are no longer maintained.
Please take a look at gtk4-rs instead.
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/gtk3-macros · https://rustsec.org/advisories/RUSTSEC-2024-0419.html · https://github.com/gtk-rs/gtk3-rs/commit/508a69b63a3c5bf73790e0e59101a955847f30d6
proc-macro-error 1.0.4 — proc-macro-error is unmaintained
proc-macro-error's maintainer seems to be unreachable, with no commits for 2 years, no releases pushed for 4 years, and no activity on the GitLab repo or response to email.
proc-macro-error also depends on
syn 1.x, which may be bringing duplicate dependencies into dependant build trees.Possible Alternative(s)
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/proc-macro-error · https://rustsec.org/advisories/RUSTSEC-2024-0370.html · https://gitlab.com/CreepySkeleton/proc-macro-error/-/issues/20
unic-char-property 0.9.0 — `unic-char-property` is unmaintained
All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.
Recommended alternatives
icu_propertiesaffected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/unic-char-property · https://rustsec.org/advisories/RUSTSEC-2025-0081.html · https://github.com/rustsec/advisory-db/issues/2414
unic-char-range 0.9.0 — `unic-char-range` is unmaintained
All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.
Recommended alternatives
charwithops::{Range, RangeFrom, RangeFull, RangeInclusive, RangeTo}to iterate over a range of codepoints.affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/unic-char-range · https://rustsec.org/advisories/RUSTSEC-2025-0075.html · https://github.com/rustsec/advisory-db/issues/2414
unic-common 0.9.0 — `unic-common` is unmaintained
All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/unic-common · https://rustsec.org/advisories/RUSTSEC-2025-0080.html · https://github.com/rustsec/advisory-db/issues/2414
unic-ucd-ident 0.9.0 — `unic-ucd-ident` is unmaintained
All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.
Recommended alternatives
icu_propertiesunicode-identaffected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/unic-ucd-ident · https://rustsec.org/advisories/RUSTSEC-2025-0100.html · https://github.com/rustsec/advisory-db/issues/2414
unic-ucd-version 0.9.0 — `unic-ucd-version` is unmaintained
All Unicode crates that are part of https://github.com/open-i18n/rust-unic are unmaintained.
affected
>=0.0.0-0· found insrc-tauri/Cargo.lockhttps://crates.io/crates/unic-ucd-version · https://rustsec.org/advisories/RUSTSEC-2025-0098.html · https://github.com/rustsec/advisory-db/issues/2414
browserslist 4.28.1 — Browserslist: Uncaught crash / prototype write via untrusted browserslist-stats.json custom stats (normalizeStats)
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.:
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.
CWE-1321, CWE-248 · affected
>=0 <4.28.7· found inpackage-lock.jsonhttps://github.com/browserslist/browserslist/security/advisories/GHSA-73wf-gq98-2v4g · https://nvd.nist.gov/vuln/detail/CVE-2026-73088 · https://github.com/browserslist/browserslist/commit/f9914ad9effc865ccc27d816255625890b31ca51 · https://github.com/browserslist/browserslist · https://github.com/browserslist/browserslist/releases/tag/4.28.7
browserslist 4.28.1 — Browserslist: Unbounded memory growth (no cache eviction) via distinct query results, leading to eventual OOM
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.
CWE-770 · affected
>=0 <4.28.7· found inpackage-lock.jsonhttps://github.com/browserslist/browserslist/security/advisories/GHSA-c83g-rgw3-j3cx · https://nvd.nist.gov/vuln/detail/CVE-2026-73089 · https://github.com/browserslist/browserslist/commit/f2931a3ff2a3a31abf84ef01a7400b270aad6405 · https://github.com/browserslist/browserslist · https://github.com/browserslist/browserslist/releases/tag/4.28.7
glib 0.18.5 — Unsoundness in `Iterator` and `DoubleEndedIterator` impls for `glib::VariantStrIter`
The
VariantStrIter::impl_getfunction (called internally by implementations of theIteratorandDoubleEndedIteratortraits for this type) was unsound, resulting in undefined behaviour.An immutable reference
&pto a*mut libc::c_charpointer initialized toNULLwas passed as an argument to a C function that that mutates the pointer behind&pin-place (i.e. as an out-argument), which was unsound. After changes in recent versions of the Rust compiler, these unsound writes through&pnow seem to be completely disregarded when building theglibcrate with optimizations.This subsequently caused all calls of
VariantStrIter::impl_getto violate the safety requirements of thestd::ffi::CStr::from_ptrfunction - which requires its argument to be a valid pointer to a C-style string - resulting in crashes due toNULLpointer dereferences.This was fixed by passing the out-argument pointer explitly as
&mut pinstead of&p.This issue has been present since this code was initially added in
glibv0.15.0. The mismatch in mutability was likely missed (and not raised as an error by the compiler) because the C function wrapped byVariantStrIter::impl_getis variadic (glib_sys::g_variant_get_child), and the pointer in question is one of the variadic arguments.affected
>=0.15.0 <0.20.0· found insrc-tauri/Cargo.lockhttps://github.com/gtk-rs/gtk-rs-core/pull/1343 · https://github.com/gtk-rs/gtk-rs-core · https://rustsec.org/advisories/RUSTSEC-2024-0429.html
Scanned 2 lockfile(s) · 2026-09-01 17:00 UTC · dependabork