Where does the bug appear (feature/product)?
Cursor SDK
Describe the Bug
@cursor/[email protected] cannot produce an advisory-clean dependency graph, and no
version inside its declared ranges can fix it.
The chain:
@cursor/sdk 1.0.31
-> @connectrpc/connect-node ^1.6.1 (highest 1.x is 1.7.0)
-> undici ^5.28.4 (highest 5.x is 5.29.0)
undici currently carries 12 advisories that are unfixed at 5.29.0 — 3 high,
7 moderate, 2 low. Every one of them was first fixed in the 6.x line
(6.23.0, 6.24.0, 6.27.0, 6.28.0), which ^5.28.4 cannot resolve to. So this
isn’t a stale lockfile: a clean install today reproduces it, and there is no
version of @cursor/sdk or of its declared connect-node range that avoids it.
For anyone whose CI gates on transitive vulnerabilities, this makes the SDK
unshippable. The workarounds are all bad — a package override forces
connect-node onto a major it doesn’t support, and a waiver means signing off
on 3 highs including two WebSocket denial-of-service issues.
Steps to Reproduce
1. npm view @cursor/[email protected] dependencies
-> "@connectrpc/connect-node": "^1.6.1"
2. npm view @connectrpc/connect-node versions
-> highest 1.x is 1.7.0 (2.x exists, but is outside the declared range)
3. npm view @connectrpc/[email protected] dependencies
-> { "undici": "^5.28.4" }
4. npm view undici versions
-> highest 5.x is 5.29.0
5. Confirm the advisories are unfixed at that ceiling:
mkdir undici-check && cd undici-check && npm init -y
npm i [email protected] --package-lock-only
npm audit
-> 12 advisories, all with fixed ranges of <6.23.0 / <6.24.0 /
<6.27.0 / <6.28.0. None are satisfiable from 5.x.
6. Or reproduce end to end:
npm i @cursor/sdk && npm audit
Expected Behavior
Installing @cursor/sdk produces a dependency graph with no known-vulnerable
packages, without requiring consumer-side overrides or waivers.
Operating System
Linux
Version Information
@cursor/sdk: 1.0.31 (current latest)
npm: 10.2.4
Node: 20.11.1
Reproduced on macOS 26.6.2 and on Linux (node:20-slim container).
For AI issues: which model did you use?
N/A: This is a packaging defect, no inference involved.
For AI issues: add Request ID with privacy disabled
N/A: This is a packaging defect, no inference involved.
Additional Information
Scope note: Cursor the IDE is unaffected and we use it daily. This is a hard
block on the SDK specifically — we’ve removed it from our dependency graph
and disabled live authoring in a production orchestrator until it clears.
The fix is a coordinated move to the connectrpc 2.x line. All four have to
move together, because @connectrpc/[email protected] declares hard peers of
@connectrpc/connect 2.2.0 exactly and @bufbuild/protobuf ^2.7.0:
"@connectrpc/connect": "^1.6.1" -> "^2"
"@connectrpc/connect-node": "^1.6.1" -> "^2"
"@connectrpc/connect-web": "^1.6.1" -> "^2"
"@bufbuild/protobuf": "1.10.0" -> "^2.7.0"
Why this fixes it rather than patching it: connect-node 2.x uses the
platform’s native fetch and declares zero runtime dependencies, so undici
leaves the graph entirely. It removes a dependency rather than adding one.
I recognise protobuf-es 1.x → 2.x is a breaking major and a real migration
on your side, not a version nudge. Happy to test a prerelease against a
production workload if that helps — we have a container-hosted orchestrator
built on the SDK, currently running with the SDK removed and authoring
disabled until this clears.
This is metadata, not environment: the reproduction is pure npm view, so
OS and Node version don’t affect it.
Does this stop you from using Cursor
No - Cursor works, but with this issue