# @cursor/sdk pulls undici 5.x transitively — 12 open advisories, none reachable within its declared range

**URL:** <https://forum.cursor.com/t/cursor-sdk-pulls-undici-5-x-transitively-12-open-advisories-none-reachable-within-its-declared-range/171294>\
**Category:** Bug Reports\
**Tags:** cursor-sdk, security\
**Created:** [September 10, 2026, 10:00pm UTC](https://forum.cursor.com/t/cursor-sdk-pulls-undici-5-x-transitively-12-open-advisories-none-reachable-within-its-declared-range/171294 "2026-09-10T22:00:17Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jacob\_Tredwell](https://avatars.discourse-cdn.com/v4/letter/j/50afbb/32.png) [@Jacob\_Tredwell](https://forum.cursor.com/u/Jacob_Tredwell)\
**Post date:** [September 10, 2026, 10:00pm UTC](https://forum.cursor.com/t/cursor-sdk-pulls-undici-5-x-transitively-12-open-advisories-none-reachable-within-its-declared-range/171294/1 "2026-09-10T22:00:17Z")

</div>

### Where does the bug appear (feature/product)?

Cursor SDK

### Describe the Bug

`@cursor/sdk@1.0.31` cannot produce an advisory-clean dependency graph, and no  
version inside its declared ranges can fix it.

The chain:

```auto
@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

```auto
1. npm view @cursor/sdk@1.0.31 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/connect-node@1.7.0 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 undici@5.29.0 --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/connect-node@2.2.0` declares hard peers of  
`@connectrpc/connect` 2.2.0 exactly and `@bufbuild/protobuf` ^2.7.0:

```auto
"@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

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [September 11, 2026, 8:53am UTC](https://forum.cursor.com/t/cursor-sdk-pulls-undici-5-x-transitively-12-open-advisories-none-reachable-within-its-declared-range/171294/5 "2026-09-11T08:53:12Z")

</div>

Hey @Jacob_Tredwell, thanks for the detailed report!

You traced the chain correctly: 1.0.31 declares `@connectrpc/connect-node ^1.x`, and every `1.x` release pins `undici ^5`, so nothing within the SDK’s declared ranges can clear those advisories.

On actual exposure: the only place that chain touches undici is a Headers polyfill inside `connect-node`, and it runs only on Node versions below 18. `@cursor/sdk` requires Node 22.13 or newer, so none of the flagged undici code (fetch, WebSocket, cookie handling) is ever executed by the SDK. That is why this has not been treated as urgent, though I understand that is little help when CI gates on the audit result.

In any case, I’ll flag it for the team!

---

<div class="post-metadata">

**Author:** ![tove](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/tove/32/64182_2.png) [@tove](https://forum.cursor.com/u/tove)\
**Post date:** [September 29, 2026, 7:20am UTC](https://forum.cursor.com/t/cursor-sdk-pulls-undici-5-x-transitively-12-open-advisories-none-reachable-within-its-declared-range/171294/12 "2026-09-29T07:20:58Z")

</div>

+1 for this from me - our CI/CD blocks any deployments containing the Cursor CLI because of the `undici` package.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [October 20, 2026, 9:32am UTC](https://forum.cursor.com/t/cursor-sdk-pulls-undici-5-x-transitively-12-open-advisories-none-reachable-within-its-declared-range/171294/14 "2026-10-20T09:32:19Z")

</div>

Hey @Jacob_Tredwell,

The undici 5.x chain is gone from the SDK as of version 1.0.34. The SDK no longer declares `@connectrpc/connect-node` as a dependency, so a fresh install of the latest version (1.0.38 right now) has no undici in the graph and `npm audit` comes back clean, with no overrides needed.

Since you pulled the SDK from your orchestrator over this, updating to the latest version should let you bring it back. Let me know if your CI still flags anything after that.

cc @tove: if your pipeline is flagging the SDK, the same update applies. If it’s flagging the Cursor CLI itself, that’s packaged separately and isn’t covered by this change. Could you share which scanner you use and the exact path and version it reports? I’ll pass it along to the team.