[v2] @modelcontextprotocol/server inlines fast-uri 3.1.0, which has 9 published advisories

What happened?

@modelcontextprotocol/server 2.2.0, 2.3.0, and 2.3.1 inline ajv 8.18.0 and fast-uri 3.1.0 into dist/ instead of declaring them as dependencies (their dependencies are only zod and @modelcontextprotocol/core; fast-uri is in dist/ajvProvider-*.mjs, under //#region ../../node_modules/.pnpm/fast-uri@3.1.0/...). pnpm-lock.yaml on main still resolves fast-uri@3.1.0.

fast-uri 3.1.0 is affected by these advisories, all fixed in 3.1.8. All 9 are already public, and #2036 asks for the same kind of bump in v1:
GHSA-4c8g-83qw-93j6, GHSA-7p8r-x3mc-p8w7, GHSA-f65p-4m7j-42xc, GHSA-hrr3-gc8f-f4qj, GHSA-jqff-g426-hqxp, GHSA-q3j6-qgpj-74h6, GHSA-qw65-cvwx-89v3, GHSA-v2hh-gcrm-f6hx, GHSA-v39h-62p7-jpjc.

Because the code is inlined, a consumer cannot raise it with overrides or resolutions, and the inlined versions do not appear in the consumer's lockfile, so tools that read the lockfile cannot report them. In our case, moving from @modelcontextprotocol/sdk 1.x (whose ajv resolved to fast-uri 3.1.8 in our lockfile) to v2 would ship an older fast-uri than before, so we are holding the migration.

We have not checked whether any of these advisories is reachable through the SDK's use of ajv.

What did you expect?

A release built with fast-uri 3.1.8 or later.
Optionally, a list of the packages and versions inlined in dist/ (in the README or package metadata), so consumers can keep their SBOMs and third-party notices accurate.

Code to reproduce

npm pack @modelcontextprotocol/server@2.3.1
tar xzf modelcontextprotocol-server-2.3.1.tgz
grep -ho '#region ../../node_modules/.pnpm/[^/]*/' package/dist/*.mjs | sort -u
# prints, among others, .pnpm/ajv@8.18.0/ and .pnpm/fast-uri@3.1.0/

SDK version

@modelcontextprotocol/server 2.2.0, 2.3.0, 2.3.1

Area

Server

chore(deps): pin fast-uri to 3.1.8 via resolutions (fixes modelcontex…

chore(deps): resolve fast-uri to 3.1.8 (fixes modelcontextprotocol#2966)

chore: add changeset for fast-uri 3.1.8 security bump (fixes modelcon…

Confirmed on current main: pnpm audit reports 9 fast-uri advisories, and packages/server/tsdown.config.ts:33 lists ajv/ajv-formats/core-internal as noExternal, so the transitive fast-uri@3.1.0 from pnpm-lock.yaml:5058 is baked into dist/ajvProvider-*.mjs. I built @modelcontextprotocol/server from main and the dist still shows #region ...fast-uri@3.1.0. A consumer override can't touch a bundled devDependency. I checked the fix locally: forcing fast-uri to 3.1.8 drops audit findings to 0, rebuilds the dist with fast-uri@3.1.8, and server/core-internal tests still pass (576 + 1525). A release just needs the lockfile override + rebuild.

I'd like to take this one. Verification on current main (b022522):

pnpm-lock.yaml:5058 resolves fast-uri@3.1.0; ajv@8.18.0 declares fast-uri: ^3.0.1, so the pinned resolution is what lands in the bundle.
packages/client/tsdown.config.ts and packages/server/tsdown.config.ts both list ajv/ajv-formats in noExternal, so the transitive fast-uri is inlined into dist/. Neither package declares it in dependencies, so consumer overrides/resolutions and lockfile scanners cannot reach the bundled copy.
fast-uri@3.1.8 (published 2026-09-15, past the 7-day minimumReleaseAge cooldown) fixes all nine advisories, and its URIComponent interface is field-for-field identical to 3.1.0's, so the dts shim in packages/core-internal/src/validators/fastUriShim.d.ts needs no change.

Proposed fix — the minimal one, per the security-vulnerability trigger in DEPENDENCY_POLICY.md and the "small changes" principle in CLAUDE.md: pin fast-uri to 3.1.8 in the root resolutions (the mechanism already used for strip-ansi), regenerate the lockfile, and ship a patch release of client and server with the rebuilt dist. The published dependency manifests stay unchanged, so this is a patch, not a major.

I'm deliberately not unbundling ajv into a declared dependency in this PR — DEPENDENCY_POLICY.md calls adding a runtime dependency a significant change that needs discussion first. Happy to do that as a follow-up if you'd prefer that direction, and happy to adjust if you want a different approach. Will open the PR shortly.

That matches what I found. With fast-uri pinned to 3.1.8 the advisory count for the ajv/fast-uri family drops to 0, and the client and server suites both pass against the rebuilt bundle (576 and 1525 tests). The one thing worth asserting in the PR is that the rebuilt dist actually inlines 3.1.8 — since fast-uri never reaches the published manifest, a lockfile-level check won't see which copy shipped either way. The resolutions route mirrors the strip-ansi pin, so it stays the minimal change.

fix(packaging): bundle fast-uri 3.1.8 in dist to clear nine advisories

Navigation Menu

Repository navigation

[v2] @modelcontextprotocol/server inlines fast-uri 3.1.0, which has 9 published advisories #2966

What happened?

What did you expect?

Code to reproduce

SDK version

Area

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[v2] @modelcontextprotocol/server inlines fast-uri 3.1.0, which has 9 published advisories #2966

Description

What happened?

What did you expect?

Code to reproduce

SDK version

Area

Activity

0xamlab commented on Oct 8, 2026

Andiii208 commented on Oct 9, 2026

0xamlab commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions