express-rate-limit's range already admits the fix, so only the lock pin moves - #216
Merged
Merged
Conversation
…in moves (comms-oqwt) ip-address 10.2.0 is vulnerable to GHSA-mwp4-54f8-5fhr (HIGH). It reaches us transitively — @modelcontextprotocol/sdk depends on express-rate-limit, which declares `ip-address: ^10.2.0`. 10.3.1 already satisfies that range, so nothing needs to be declared, widened, or overridden: the lock pin was the only thing holding the tree on the vulnerable version. The lock entry is edited in place rather than refreshed by resolution. `bun update ip-address` promotes it to a direct dependency of the root package and leaves express-rate-limit's copy on 10.2.0 — a manifest change that does not fix the vulnerable copy. Dropping the entry and re-resolving does fix it, but carries nine unrelated packages with it, including a @parcel/watcher major that drops the win32-ia32 binary. bunfig.toml's minimumReleaseAge does not bite here: 10.3.1 was published 2026-07-25, so it is outside the seven-day window.
GraemeF
added a commit
that referenced
this pull request
Sep 3, 2026
Clears five HIGH advisories by moving `fast-uri` 4.1.1 -> 4.1.3 in `bun.lock`. One line, no manifest change. - GHSA-7p8r-x3mc-p8w7 — fixed in 4.1.2 - GHSA-5jgf-p345-68v8 — host confusion via skipped IDN canonicalisation - GHSA-f65p-4m7j-42xc — SSRF via malformed authority - GHSA-fph4-wmhf-6fwf — SSRF via repeated components - GHSA-jqff-g426-hqxp — host confusion via percent-encoded scheme The last four were published 2026-09-02 and are all fixed in 4.1.3, so the same one-line move that this branch already carried for the first one clears all five once the pin lands on 4.1.3 rather than 4.1.2. ## Why it's a lockfile-only change `fast-uri` is transitive. It arrives through `ajv`, which declares `fast-uri: ^3.0.1`, and `package.json`'s `overrides` block already raises that to `^4.1.1`. 4.1.3 satisfies the override, so the lock pin was the only thing holding the tree on the vulnerable version. The override also collapses `ajv` onto the single 4.x resolution, so `bun.lock` holds exactly one `fast-uri` entry and one pin move covers the tree — there is no 3.x copy left behind, and the 3.x line is vulnerable to all five. ## Why the entry is edited rather than re-resolved `bun update fast-uri` does not fix this. It reports `installed fast-uri@4.1.1`, leaves the lock entry unmoved, and adds `fast-uri` to the root `package.json` as a direct dependency pinned exactly — because `bunfig.toml` sets `exact = true`. The manifest changes and the vulnerable copy stays. PR #216 recorded the same behaviour for `ip-address`. Editing the single lock line keeps the diff to what the advisories require. `bun install --frozen-lockfile` accepts the result against a wiped `node_modules` — which is also what verifies the hand-written integrity hash, since bun checks the tarball against it — and the only copy in the tree is `node_modules/.bun/fast-uri@4.1.3`. ## Supply-chain gate `bunfig.toml` sets `minimumReleaseAge = 604800`. 4.1.3 published 2026-08-23, so it clears the seven-day window by 11 days. The gate was not lowered or bypassed. `fast-uri` 4.1.4 published 2026-09-02 and is inside the window until 2026-09-09. The override's caret admits it, so the gate is what holds this resolution at 4.1.3. No advisory here names 4.1.4. ## Not in this PR - **GHSA-v2hh-gcrm-f6hx** is fixed in `fast-uri` 4.1.1 and `main` is already there. No work. - **A release.** commy carries 27 commits unreleased since `commy-v0.22.0`, tracked as `comms-ngz0`. This merge fixes `main`, not the published npm bundle. Raised by nixos-config from osv-scanner findings; tracked as `comms-k9f9`.
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
1 participant
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.
Closes GHSA-mwp4-54f8-5fhr (HIGH) by moving
ip-address10.2.0 → 10.3.1 inbun.lock. One line, no manifest change.Why it's a lockfile-only change
ip-addressis transitive:@modelcontextprotocol/sdk→express-rate-limit8.6.0, which declaresip-address: ^10.2.0. 10.3.1 already satisfies that range, so the lock pin was the only thing holding the tree on the vulnerable version. Nothing needs declaring, widening, or overriding.Why the entry is edited rather than re-resolved
Two obvious routes were tried and rejected:
bun update ip-addresspromotesip-addressto a direct dependency of the rootpackage.jsonand leavesexpress-rate-limit/ip-addresspinned at 10.2.0. It's a manifest change that doesn't fix the vulnerable copy.@parcel/watcher2.5.6 → 2.6.0, which also drops thewatcher-win32-ia32binary.Editing the single lock line keeps the diff to what the advisory requires.
bun install --frozen-lockfileaccepts the result against a wipednode_modules, and the only copy in the tree isnode_modules/.bun/ip-address@10.3.1.Supply-chain gate
bunfig.toml'sminimumReleaseAge = 604800doesn't bite: 10.3.1 was published 2026-07-25, outside the seven-day window. The gate was not lowered or bypassed.Not in this PR
cryptography49.0.0 → 50.0.0 (GHSA-g6cj-pr64-35w5) — tracked ascomms-6g1n, deferred to 2026-08-07. Blocked byclients/hermes/pyproject.toml's[tool.uv] exclude-newer = "7 days": 50.0.0 was published 2026-07-31, so the gate clears on the 7th. Worth knowing, and the reason it needs its own bead rather than a retry:uv lock --upgrade-package cryptographydoes not fail on this. It resolves clean, exits 0, and silently keeps 49.0.0 — the hermes CI task on this very PR installscryptography==49.0.0without complaint. The bump has to be verified by diffing the lock, never by the command's exit code.ip-addressandcryptographyare both transitive, and Renovate's version-update path only tracks declared dependencies — so neither appeared on the dependency dashboard. Whether that gap needs a guard is filed ascomms-os6h.fast-uri4.1.1 → 4.1.2 is already queued asrenovate/fast-uri-4.x, held by the same seven-day gate. It's a patch, so it automerges on its own.Raised from osv-scanner findings; tracked as
comms-oqwt.