fix(deps): bump @grpc/grpc-js to ^1.13.5 to clear CVE-2026-48068 / CVE-2026-48069 - #154
Conversation
…E-2026-48069 @grpc/grpc-js was pinned to an exact 1.13.3, which falls inside the affected range 1.13.0 - 1.13.4 for two HIGH advisories (malformed request crashes a server; malformed compressed message crashes a client or server), both fixed in 1.13.5. Because the pin was exact rather than a range, consumers of 9.34.0 could not remediate on their own -- customer static-analysis gates (Cycode) block the dependency outright. Widen to ^1.13.5 so the fixed line is picked up and future patches flow without needing an SDK release for each advisory. Verified: npm audit reports no @grpc/grpc-js advisories after the bump (two HIGH before); build clean; unit suite identical to the pre-bump control on the same commit (8 files / 73 tests failing both before and after -- all pre-existing); live App Automate run on the resolved 1.14.4 connects the bin session and drives the gRPC transport with no UNAVAILABLE / DEADLINE_EXCEEDED and session renames landing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Note for reviewers — most of the
|
| Portion | ~Lines | Origin |
|---|---|---|
Pre-existing lockfile drift on main |
~197 | already on main before this branch |
@grpc/grpc-js + its own transitive deps |
~30 | this PR |
packages/browserstack-service/package.json |
1 | this PR — the grpc constraint only |
The drift. main's lockfile is out of sync with its own manifest:
lockfile (main): @wdio/browserstack-service 9.29.1
package.json (main): 9.34.0
Verified independently — cloning pristine main, changing nothing, and running npm install --package-lock-only produces 197 changed lines including -"version": "9.29.1" / +"version": "9.34.0". Any PR that runs npm install will reproduce it. This PR does not bump the package version — packages/browserstack-service/package.json contains only the @grpc/grpc-js line change.
The three other version bumps are legitimate. @grpc/proto-loader 0.7.15 → 0.8.1, protobufjs 7.6.4 → 7.6.5, @protobufjs/utf8 1.1.1 → 1.1.2 are grpc-js's own dependency tree — @grpc/grpc-js@1.14.4 declares "@grpc/proto-loader": "^0.8.0", so the patched grpc necessarily pulls them.
Why the lockfile can't be dropped from this PR. I tried isolating the change; it can't be separated. Any internally-consistent lockfile has to record 9.34.0, since that's what the manifest declares. Omitting the lockfile instead breaks npm ci — the manifest would ask for ^1.13.5 while the lock still pins 1.13.3.
Separate follow-up worth considering: the lockfile appears to have gone stale across several releases — release automation bumps package.json but doesn't regenerate package-lock.json. Adding a lockfile refresh to the release flow would stop this noise landing on every unrelated PR.
|
RUN_TESTS |
|
🔴 SDK PR Review gate is red. Pending:
It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge. |
|
[SDK Wdio Test] TRA build state: failed | Stability 72% — verdict: failure. Passed: 61, Failed: 24, Aggregate: 85. TRA: https://observability.browserstack.com/builds/3ddtx2wfgdcoqkhiiw8k0xskwnzla0ah8nvmty7k |
The previous commit regenerated package-lock.json via `npm install`, which also rewrote ~197 unrelated lines: main's lockfile is stale against its own manifest (it records 9.29.1 while package.json says 9.34.0) and npm recomputes derived peer/dev reachability flags on every install (152 `"peer": true` removals). Reproducing that on a pristine clone of main with no source change produces the identical churn, so none of it belongs to this security fix. Restore those lines to main's state and keep only the grpc subtree: @grpc/grpc-js, @grpc/proto-loader, protobufjs, @protobufjs/utf8, and the mirrored constraint on packages/browserstack-service. Lockfile diff drops from 227 lines to 30. Re-verified after scoping: `npm ci` resolves cleanly and installs grpc-js 1.14.4 / proto-loader 0.8.1, npm audit reports no grpc advisories, build clean, and the unit suite is unchanged at 8 files / 73 tests failing (all pre-existing on main). The lockfile staleness on main is real but pre-existing, and is better fixed on its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
🔴 SDK PR Review gate is red. Pending:
It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge. |
Update — lockfile diff scoped down to grpc only (supersedes my note above)The earlier comment explained ~197 lines of inherited lockfile drift in this PR. Rather than ask reviewers to mentally filter it, I've removed it — the lockfile change is now grpc-subtree only. Before → after: What remains is exactly five nodes:
The three transitive bumps are grpc-js's own dependency tree — What was removed: Re-verified after scoping (the lockfile was edited surgically, so this mattered):
Still worth a separate fix: |
^1.13.5 resolved to 1.14.4, which declares "@grpc/proto-loader": "^0.8.0" and so forced proto-loader 0.7.15 -> 0.8.1; npm then also floated protobufjs 7.6.4 -> 7.6.5 and @protobufjs/utf8 1.1.1 -> 1.1.2, neither of which was required (7.6.4 already satisfies proto-loader's ^7.5.5). None of that is needed to clear the advisories. Both CVEs are fixed in 1.13.5, and grpc-js 1.13.5 still declares "@grpc/proto-loader": "^0.7.13" -- identical to 1.13.3 -- so constraining to ~1.13.5 leaves the entire transitive tree untouched. Installed tree after this change: grpc-js 1.13.5, proto-loader 0.7.15, protobufjs 7.6.4, @protobufjs/utf8 1.1.1. Lockfile diff is now a single node plus the mirrored constraint (8 lines, down from 30). ~1.13.5 still picks up future 1.13.x patches; widening across minors is a dependency-policy decision that shouldn't ride along on a security fix. Verified: npm audit reports no @grpc/grpc-js advisories (two HIGH before); `npm ci` resolves cleanly; build clean; unit suite unchanged at 8 files / 73 tests failing (all pre-existing). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
🔴 SDK PR Review gate is red. Pending:
It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge. |
|
RUN_TESTS |
|
🔴 SDK PR Review gate is red. Pending:
It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge. |
|
[SDK Wdio Test] TRA build state: failed | Stability 74% — verdict: failure. Passed: 63, Failed: 22, Aggregate: 85. TRA: https://observability.browserstack.com/builds/w9y1lkewronfh6rhdtjvy0m11c3kcszampbuspjc |
|
RUN_TESTS |
|
[SDK Wdio Test] TRA build state: failed | Stability 72% — verdict: failure. Passed: 61, Failed: 24, Aggregate: 85. TRA: https://observability.browserstack.com/builds/jhxybxizijantffnodohswem762yt8vzrj19joje |
4 participants
What is this about?
@grpc/grpc-jswas pinned to an exact1.13.3, which sits inside the affected range1.13.0 - 1.13.4for two HIGH advisories:Reported by a customer whose static-analysis gate (Cycode) blocked the dependency on
@wdio/browserstack-service 9.34.0 → @grpc/grpc-js 1.13.3. Confirmed locally —npm auditonmainreports both advisories.Why this needs an SDK release rather than a consumer-side fix: the pin is exact, not a range. Consumers cannot float to the patched line via
npm audit fixor normal resolution — they'd have to add anoverridesentry. This effectively blocks adoption of 9.34.0 for anyone with a security gate.This is currently blocking a customer from picking up the SDK-7270 session-naming fix, which shipped in that same 9.34.0.
Change: widen the constraint to
^1.13.5, so the fixed line is picked up and future patch/minor fixes flow without needing an SDK release per advisory. No source changes.Verification
^1.13.5resolves to 1.14.4. Since@grpc/grpc-jsis the SDK ↔ binary transport and this floats a minor, a build-and-unit pass alone isn't sufficient evidence — so this was also validated with a live App Automate run.npm audit—@grpc/grpc-jsadvisoriesUNAVAILABLE/DEADLINE_EXCEEDED; session renames landingThe 73 unit failures are pre-existing on
mainand unchanged by this PR — the before/after control was run on this same commit to confirm the bump introduces none.Live validation build
f41e354d7f2dd59a67bf5f6ddc053af74ae6bad3— 3 sessions, 3 distinct names, both test sessionspassedwith correct per-test titles.Related Jira task/s
Raised via SDK-7270 — https://browserstack.atlassian.net/browse/SDK-7270
Release (mandatory for every PR — required for the
ready-for-reviewlabel)Version bump: (required — tick exactly one)
Release notes type: (optional)
Release notes (customer-facing): (optional but encouraged)
@grpc/grpc-jsto^1.13.5, resolving two high-severity advisories (CVE-2026-48068, CVE-2026-48069) reported by dependency scanners against earlier releases.Release notes (internal): (required — engineer-facing; what actually changed / why)
@grpc/grpc-jswas exact-pinned at1.13.3, inside the vulnerable range1.13.0 - 1.13.4for CVE-2026-48068 / CVE-2026-48069 (both fixed in 1.13.5). The exact pin meant downstream consumers could not remediate without anoverridesentry, so security gates blocked 9.34.0 outright. Widened to^1.13.5(resolves 1.14.4) so patched versions are picked up automatically. Verified: audit clean, unit suite identical to a same-commit control, and a live App Automate run exercising the gRPC transport.Checklist
PR Validations
Run Tests: Comment RUN_TESTS to trigger sanity tests.