fix(deps): clear the two unremediated HIGHs in sdk-typescript/pnpm-lock.yaml (postcss + vite) - #51
fix(deps): clear the two unremediated HIGHs in sdk-typescript/pnpm-lock.yaml (postcss + vite)#51yakimoto wants to merge 2 commits into
Conversation
|
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_2afcbf60-4127-42ae-91a2-6835d74f032d) |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 18 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
…h-pf6j-xcff vite 8.0.14 was reachable only as an auto-installed PEER of vitest/@vitest/mocker, which declare vite: ^6.0.0 || ^7.0.0 || ^8.0.0. That range already admits the patched 8.0.16, so nothing was blocking the fix except a sticky lockfile resolution. Four levers were measured and every one was a no-op: pnpm update vite --depth Infinity -r -> vite unchanged at 8.0.14 pnpm update vitest -r -> vitest 4.1.7 -> 4.1.10, vite unchanged, and it rewrote 48 package.json files pnpm.overrides { vite: ^8.0.16 } -> override written into the lockfile, and in the SAME run pnpm reported "unmet peer vite@^8.0.16: found 8.0.14" pnpm dedupe -> vite unchanged pnpm overrides do not govern auto-installed peers. A concrete declaration does: one workspace-root devDependency re-resolves vite for all 48 packages to a single 8.1.5, with zero references left at 8.0.14. Clears GHSA-fx2h-pf6j-xcff (high, server.fs.deny bypass via Windows alternate paths) and GHSA-v6wh-96g9-6wx3 (moderate, launch-editor NTLMv2 hash disclosure over UNC paths). Both are patched in 8.0.16; both are Windows-specific, so our Linux CI was never the exposure - consumers building on Windows were. Measured with NODE_ENV=development so dev scope is not silently omitted: before high 4 moderate 9 low 2 (vite high + vite moderate present) after high 3 moderate 8 low 2 (no vite entry of any severity) Consumer proof, not an audit read - vitest drives vite for every transform: pnpm -r build && pnpm -r --no-bail test 48 packages, 52 test files, 143 tests, 0 failures, on vite 8.1.5 CI could not run this: the org is under a GitHub billing lock (plan=free, locked=yes), so all of the above is local measurement only.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
yakimoto
changed the title
1 participant
Clears two HIGHs that Dependabot is not reporting or not fixable by the obvious route on this repo, as two separate commits in the same file.
Companion to wave-av/sdk#54, which does the same postcss bump on the other repo carrying it. Tracked in wave-av/claude-workstation#564.
Note
Scope changed after this PR was opened. It was postcss-only and manifest-free. The second commit adds three lines to
sdk-typescript/package.json(a workspace-rootdevDependencies.vite) because — as measured below — a lockfile-only fix for vite is not possible with pnpm 9.15. Where this description below says "no manifest touched", that is true of the postcss commit and no longer true of the PR as a whole. Both commits are separately revertable.Kept as one PR rather than a fourth: #48, #50 and #51 already rewrite
sdk-typescript/pnpm-lock.yaml, and a separate vite PR would conflict with this one by construction.Commit 2 — vite: the fix was available the whole time, and four tools refused to apply it
GHSA-fx2h-pf6j-xcff — vite:
server.fs.denybypass via Windows alternate paths. HIGH · range>= 8.0.0, <= 8.0.15· first patched 8.0.16.GHSA-v6wh-96g9-6wx3 — launch-editor: NTLMv2 hash disclosure via UNC path handling on Windows. MODERATE · same range, same fix.
viteappears in nopackage.jsonin this workspace. It was reachable only as an auto-installed peer ofvitest/@vitest/mocker@4.1.7, which declare:That range already admits the patched
8.0.16. So there was no parent constraint to break, no upstream to wait on, and no compatibility question — the only thing holding8.0.14in place was a sticky peer resolution in the lockfile.8.0.14satisfies the range, so nothing ever forced it forward.Four levers, all measured, all no-ops
pnpm update vite --depth Infinity -rpnpm update vitest -rpackage.jsonfilespnpm.overrides { vite: ^8.0.16 }+install --force✕ unmet peer vite@^8.0.16: found 8.0.14pnpm dedupeThe third row is the useful one to remember: pnpm records the override in
pnpm-lock.yaml, then declines to apply it, and reports the resulting inconsistency about itself.pnpm.overridesdoes not govern auto-installed peer dependencies. A lockfile that containsoverrides: vite: ^8.0.16while resolvingvite@8.0.14looks, to a reader or a scanner, like the fix landed.The
pnpm update vitest -rrow is worth flagging separately: it rewrote every manifest in the workspace as a side effect while achieving nothing — the same class of silent 48-file churn as claude-workstation#555. It was reverted, not committed.What actually works
A concrete declaration governs the peer where an override does not. One workspace-root devDependency:
re-resolves vite for all 48 packages to a single
8.1.5, with zero references left at8.0.14:I verified the same mechanism from a single package (
packages/core) first — it also hoists workspace-wide — and chose the workspace root because that is where a shared test-runner peer belongs, not inside one arbitrary package.Exposure, stated plainly
Both advisories are Windows-specific path handling. CI and the publish path are Linux, so this was never an exposure in our own pipeline; contributors building on Windows were the real surface.
viteis dev/test tooling and does not enter the published dependency graph of any@wave-av/*package. It is still a HIGH sitting in the build path with a one-line fix available.Verification — measured with
NODE_ENV=developmentDev scope must be forced on, or
pnpm auditinheritsomit=devfrom the environment and silently drops every dev-scope entry — which would have hidden this advisory completely.The remaining 3 highs are
hono×1 andfast-uri×2, which #48 addresses.Consumer proof, not an audit read.
npm/pnpm auditcompares version strings and never loads the module; vitest drives vite for every transform, so the test suite is the real exercise:An earlier run before building showed failures in
packages/adk(Failed to resolve entry for package "@wave-av/kernel"). That is unbuiltworkspace:*links, not a vite regression — it clears entirely oncepnpm -r buildhas run.Commit 1 — postcss
Clears a HIGH that Dependabot is not reporting on this repo. Lockfile only — no manifest touched by this commit.
The advisory, and why there's no alert for it
GHSA-r28c-9q8g-f849 — PostCSS: Path Traversal in Previous Source Map Auto-Loading (
sourceMappingURL) leads to Arbitrary.mapFile Disclosure. HIGH · range<= 8.5.17· first patched 8.5.18 · published 2026-07-24.It's in the GitHub Advisory Database, but this repo's Dependabot alert list doesn't contain it. I found it by running an audit while measuring a different baseline, not by reading alerts.
I checked that the silence isn't just "no postcss here." Read from
origin/mainrefs:postcssonorigin/mainsdk-typescript/pnpm-lock.yaml)The two repos with no postcss correctly report nothing, and alerts are demonstrably working here otherwise. So it's a detection gap, not absence — which means an empty alert list isn't evidence of a clean tree. That's the part worth carrying beyond this PR.
Still true 4 days later. Re-checked on 2026-07-28: this repo's open alerts are
fast-uri×2,hono,viteand friends — no postcss entry. GitHub's own push output on this branch reports15 vulnerabilities (4 high, 9 moderate, 2 low), which matches the local dev-scope audit of the pre-fix tree exactly — and neither number contains postcss.Scope
Dev-only, and off the exercised path.
postcssarrives through the build toolchain (vite,tsup) and never enters the published dependency graph of any@wave-av/*package. The exploit needs a malicioussourceMappingURLcomment in CSS the toolchain processes; this workspace ships no CSS. Low practical exposure — but it's a HIGH in the build path and the fix is a lockfile bump.Landing on
8.5.24(current latest) rather than the minimum8.5.18, since the resolver picks the newest in-range and the intermediate releases are patch-level.About the diff size — read this before assuming churn
142 insertions / 122 deletions is more than two packages' worth, and that deserves an explanation rather than a shrug. What actually moved:
nanoidmoves because postcss 8.5.24 declaresnanoid: ^3.3.16. Thelightningcssminor and the two added packages are pnpm re-resolvingvite's optional/transitive tree within its already-declared ranges — not a forced upgrade of anything, and all dev-scope.I tried to narrow it. Running without
--depth Infinityproduces the byte-identical result, because pnpm resolves the workspace as a whole. The only way to get a two-package diff would be hand-editing the lockfile, which is the thing I've been telling reviewers on #48/#50 not to do — a hand-merged or hand-trimmed pnpm lockfile installs a tree that matches nobody's intent. So this is the honest output of the tool, described rather than trimmed.This is not the churn from claude-workstation#555. That was
pnpm update --recursive --lockfile-onlysilently reformatting all 48package.jsonfiles and unescaping—into literal em-dashes inside publisheddescriptionfields. The postcss commit touched zero manifests.Merge order
#48, #50 and #51 all rewrite
sdk-typescript/pnpm-lock.yaml. Whichever lands last must re-run its own update command and force-push — never hand-merge a pnpm lockfile. A hand-resolved conflict in this file produces a tree no resolver would ever generate.Verification caveat
CI has run on none of this. Actions are refusing every job org-wide on an account-level billing lock (
plan=free,locked=yes, re-confirmed live today), so every number above is local measurement. Do not read a green-lookingmergeStateStatuson this PR as CI approval — during this outage GitHub creates no Actions check-run at all, so there is no red to see.