[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@modelcontextprotocol/sdk (source)	1.30.0 → 1.32.0

---

MCP TypeScript SDK: Experimental tasks were not tied to the session that created them

CVE-2026-111767 / GHSA-22jm-h49p-29qw

More information

Details

Summary

In affected versions, the experimental tasks feature (taskStore) did not check which session created a task. Clients sharing one InMemoryTaskStore could list, read and cancel each other's tasks.

Experimental tasks are deprecated. The 2026-07-28 specification replaced them with a redesigned extension. The best course of action is to stop using them.

Am I affected?

Only if your HTTP server passes taskStore to McpServer or Server. If grep -ri taskstore --exclude-dir=node_modules . finds nothing, you are not affected.

Affected versions: @modelcontextprotocol/sdk 1.24.0 through 1.31.0. The 2.x packages are not affected.

Fix

Upgrade to @modelcontextprotocol/sdk 1.32.0 or later. Each task is now tied to the session that created it, so a client that starts a new session can no longer reach its earlier tasks.

If you cannot upgrade yet, remove taskStore, or create one InMemoryTaskStore per session.

Severity

• CVSS Score: 8.6 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

References

• https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-22jm-h49p-29qw
• https://github.com/modelcontextprotocol/typescript-sdk/pull/2925
• https://github.com/modelcontextprotocol/typescript-sdk/commit/727075b5bbeb77fbea22041b36b72a73042160fa
• https://github.com/advisories/GHSA-22jm-h49p-29qw

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server

CVE-2026-104850 / GHSA-6qxp-vccf-f47h

More information

Details

Summary

In affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to.

A malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it:

• the refresh_token and client_secret stored from an earlier sign-in
• the client_secret or signed assertion configured on a bundled provider

Am I affected?

Yes, if both of these hold:

• your application uses the SDK's OAuth client over HTTP, through any of:
  • an authProvider on a transport
  • the withOAuth() middleware
  • direct calls to auth() or fetchToken()
• it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server

Affected versions:

• @modelcontextprotocol/sdk 1.12.0 through 1.30.1
• @modelcontextprotocol/client 2.0.0 through 2.1.0, only for:
  • bundled providers without expectedIssuer
  • credentials stored or supplied without issuer
  • direct calls to fetchToken()
  • providers that read storage back through OAuthTokensSchema or OAuthClientInformationSchema

Not affected:

• MCP servers built with the SDK
• stdio clients

Fix

Upgrade to:

• 1.x: @modelcontextprotocol/sdk 1.31.0 or later
• 2.x: @modelcontextprotocol/client 2.2.0 or later, and @modelcontextprotocol/core 2.2.0 or later if you import it directly

The client now records the authorization server as issuer on saved credentials and does not send them to a different one. The user signs in again, or the call throws.

In the following cases, upgrading to the patched version is not enough. You also need to make a change:

• Bundled providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider): pass expectedIssuer, for example expectedIssuer: 'https://auth.example.com'. Without it they still use whichever authorization server the MCP server names.
• Credentials saved without issuer: tokens and client information your OAuthClientProvider persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add issuer to them, or clear them so users sign in again.
• Your own OAuthClientProvider: save exactly what saveTokens() and saveClientInformation() are given, including issuer. For pre-registered credentials, include issuer in what clientInformation() returns.

Not covered by this fix:

• a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust.
• refreshAuthorization() and exchangeAuthorization() called directly
• 2.x with skipIssuerMetadataValidation: true

If an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.

If you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept expectedIssuer.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-6qxp-vccf-f47h
• https://github.com/modelcontextprotocol/typescript-sdk/pull/2887
• https://github.com/modelcontextprotocol/typescript-sdk/commit/edd12e282620ebf770d67316f19cf91d4112a1bd
• https://github.com/modelcontextprotocol/typescript-sdk
• https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/v2.2.0

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

MCP TypeScript SDK: Experimental tasks were not tied to the session that created them

CVE-2026-111767 / GHSA-22jm-h49p-29qw

More information

Details

Summary

In affected versions, the experimental tasks feature (taskStore) did not check which session created a task. Clients sharing one InMemoryTaskStore could list, read and cancel each other's tasks.

Experimental tasks are deprecated. The 2026-07-28 specification replaced them with a redesigned extension. The best course of action is to stop using them.

Am I affected?

Only if your HTTP server passes taskStore to McpServer or Server. If grep -ri taskstore --exclude-dir=node_modules . finds nothing, you are not affected.

Affected versions: @modelcontextprotocol/sdk 1.24.0 through 1.31.0. The 2.x packages are not affected.

Fix

Upgrade to @modelcontextprotocol/sdk 1.32.0 or later. Each task is now tied to the session that created it, so a client that starts a new session can no longer reach its earlier tasks.

If you cannot upgrade yet, remove taskStore, or create one InMemoryTaskStore per session.

Severity

• CVSS Score: 8.6 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

References

• https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-22jm-h49p-29qw
• https://github.com/modelcontextprotocol/typescript-sdk/pull/2925
• https://github.com/modelcontextprotocol/typescript-sdk/commit/727075b5bbeb77fbea22041b36b72a73042160fa
• https://github.com/modelcontextprotocol/typescript-sdk

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

MCP TypeScript SDK: One HTTP request within the default size limit could exhaust server memory during validation

CVE-2026-111768 / GHSA-46jr-4wx8-v453

More information

Details

Summary

In affected versions, servers put no limit on how many array elements and object keys they validated in one request. One HTTP request within the default 4 MiB size limit could exhaust the server's memory, and the process aborted with JavaScript heap out of memory.

No credentials are needed, unless you authenticate requests before they reach the SDK.

Am I affected?

Yes, if clients you do not fully trust can reach your server over HTTP. The risk is highest for McpServer tools whose input contains an array or a record. stdio-only servers are not affected.

Affected versions:

• @modelcontextprotocol/sdk 1.3.0 through 1.31.0
• @modelcontextprotocol/server 2.0.0 through 2.2.0

Fix

Upgrade to:

• 1.x: @modelcontextprotocol/sdk 1.32.0 or later
• 2.x: @modelcontextprotocol/server 2.3.0 or later

Upgrading alone changes nothing. The patched versions add an McpServer option, maxToolInputElements, that is off by default. Make both of these changes:

1. Set maxToolInputElements just above the largest input your tools need, for example new McpServer(info, { maxToolInputElements: 10_000 }). It counts array elements and object keys in a call's arguments. A call over the limit gets an isError: true result.
2. Lower the request size limit to what your tools need. The option covers tool arguments only, and the size limit covers everything else. Set maxRequestBodySize on the transport or createMcpHandler(). If you parse the body yourself, for example with express.json() or Fastify, set that parser's limit.

If you cannot upgrade yet, make the second change. maxRequestBodySize needs @modelcontextprotocol/sdk 1.30.1 or @modelcontextprotocol/server 2.1.0. Below that, use a reverse proxy.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-46jr-4wx8-v453
• https://github.com/modelcontextprotocol/typescript-sdk/pull/2926
• https://github.com/modelcontextprotocol/typescript-sdk/pull/2927
• https://github.com/modelcontextprotocol/typescript-sdk/commit/6d8dbc6cb590edf766fcb66b636ca6b654e99c37
• https://github.com/modelcontextprotocol/typescript-sdk/commit/fd26801b3b387742fe24a90ed4b275dd6072209f
• https://github.com/modelcontextprotocol/typescript-sdk

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

MCP TypeScript client SDK: HTTP client transports and OAuth requests followed cross-origin redirects and re-sent custom headers and request bodies

CVE-2026-111769 / GHSA-6prh-2h8m-c8cw

More information

Details

Summary

In affected versions, the SDK's HTTP client transports and OAuth requests followed redirects to any origin.

If an MCP server or authorization server redirected a request to another origin, that origin received custom request headers (such as an X-API-Key set in requestInit.headers) and the mcp-session-id header. On a 307 or 308 it also received the request body, including OAuth token requests with their refresh_token and client_secret.

On current runtimes fetch already drops the Authorization header across origins.

Am I affected?

Yes, if your application uses StreamableHTTPClientTransport, SSEClientTransport, or the SDK's OAuth client functions such as auth(). stdio clients are not affected.

Affected versions:

• @modelcontextprotocol/sdk all versions through 1.31.0
• @modelcontextprotocol/client 2.0.0 through 2.2.0

Fix

Upgrade to:

• 1.x: @modelcontextprotocol/sdk 1.32.0 or later
• 2.x: @modelcontextprotocol/client 2.3.0 or later

Redirects are now followed only within the same origin, and not at all in browsers. If your MCP server or authorization server redirects to another origin on purpose, configure the final URL instead. Setting redirectPolicy: 'follow' on a transport restores the old behaviour and the exposure.

If a redirect may have reached a host you do not control, rotate the API keys and client_secret your application held and revoke its tokens.

If you cannot upgrade yet, pass a fetch that refuses redirects, for example (url, init) => fetch(url, { ...init, redirect: 'error' }).

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

References

• https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-6prh-2h8m-c8cw
• https://github.com/modelcontextprotocol/typescript-sdk/pull/2901
• https://github.com/modelcontextprotocol/typescript-sdk/pull/2902
• https://github.com/modelcontextprotocol/typescript-sdk/commit/30bfe5139f4b0825c90cd725f9a7e3f9af5e120d
• https://github.com/modelcontextprotocol/typescript-sdk/commit/433eb413dc305ebeb93b8ebcde0095a8fc0d5fa0
• https://github.com/modelcontextprotocol/typescript-sdk

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

MCP TypeScript SDK: Server bearer authentication accepted tokens issued for another service

CVE-2026-111771 / GHSA-rvq5-wwqv-78pq

More information

Details

Summary

In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.

Am I affected?

Yes, if your HTTP server uses requireBearerAuth() or verifyBearerToken(), its authorization server also issues tokens for other services, and your verifyAccessToken() does not check the token's audience (aud) itself.

Affected versions:

• @modelcontextprotocol/sdk 1.6.0 through 1.31.0
• @modelcontextprotocol/server 2.0.0 through 2.2.0
• @modelcontextprotocol/express 2.0.0 through 2.0.1
• @modelcontextprotocol/server-legacy 2.0.0 through 2.3.0

Fix

Upgrade to:

• 1.x: @modelcontextprotocol/sdk 1.32.0 or later
• 2.x: @modelcontextprotocol/server 2.3.0 or later, together with @modelcontextprotocol/express 2.0.2 or later if you use it
• @modelcontextprotocol/server-legacy 2.3.1 or later

Upgrading alone changes nothing. The patched versions add an expectedResource setting that is off by default. To turn the check on, make both of these changes together:

1. Pass the audience your authorization server puts in tokens for your server: requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') }).
2. Return the token's audience from verifyAccessToken() as AuthInfo.resource, also a URL.

A token for another service then gets 401. With only the first change, every request gets 401.

If you cannot upgrade yet, reject any token whose aud does not include your server inside verifyAccessToken(). That closes the issue on every version.

Severity

• CVSS Score: 6.8 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

References

• https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-rvq5-wwqv-78pq
• https://github.com/modelcontextprotocol/typescript-sdk/commit/40f8f4e229d963cd7fd2890bda2aeebe7005299a
• https://github.com/modelcontextprotocol/typescript-sdk/commit/5a0724d14cf34a27a3b070224d2996cdd611df9f
• https://github.com/modelcontextprotocol/typescript-sdk/commit/5a1867390b91b8836f49af76c45427279f513325
• https://github.com/modelcontextprotocol/typescript-sdk

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

modelcontextprotocol/typescript-sdk (@​modelcontextprotocol/sdk)

v1.32.0

Compare Source

Upgrade notes

• Redirects: the HTTP client transports now follow a redirect only when it stays on the same origin (same scheme, host and port; http to https on the same host is allowed). A deployment whose endpoint redirects to another host or port either configures the final URL or sets redirectPolicy: 'follow' on StreamableHTTPClientTransport or SSEClientTransport. In browsers, a redirected request fails unless that option is set.
• New options, both off unless you set them: maxToolInputElements on McpServer limits the number of array elements and object members in a tool call's arguments. expectedResource on requireBearerAuth accepts only tokens issued for this server (the token's audience).

What's Changed

• [v1.x] fix(client): follow redirects only within the endpoint's origin by @​claude[bot] in #​2902
• docs: point SECURITY.md at GitHub Security Advisories (v1.x) by @​claude[bot] in #​2910
• [v1.x] examples: close idle sessions and cap the session map by @​maxisbey in #​2914
• [v1.x] fix(tasks): keep tasks of the in-memory task store within the session that created them by @​claude[bot] in #​2925
• [v1.x] feat(server): add maxToolInputElements option to limit the number of elements in tool-call arguments by @​claude[bot] in #​2927
• [v1.x] fix(server): accept tools/call and prompts/get requests that omit arguments by @​raashish1601 in #​2045
• [v1.x] feat(auth): add expectedResource to requireBearerAuth by @​claude[bot] in #​2930
• [v1.x] test(e2e): cover tools/call and prompts/get without arguments by @​claude[bot] in #​2931
• chore: bump version to 1.32.0 by @​claude[bot] in #​2935

New Contributors

• @​raashish1601 made their first contribution in #​2045

Full Changelog: modelcontextprotocol/typescript-sdk@1.31.0...1.32.0

v1.31.0

Compare Source

Upgrade notes

• Stored OAuth tokens and client information now include an issuer field. Storage that rejects unknown fields needs to allow it.
• Pass expectedIssuer when constructing ClientCredentialsProvider, PrivateKeyJwtProvider or StaticPrivateKeyJwtProvider. Constructing them without it is deprecated.

What's Changed

• [v1.x] Bind stored OAuth credentials to the authorization server that issued them by @​maxisbey in #​2888
• chore: bump version to 1.31.0 by @​claude[bot] in #​2890

Full Changelog: modelcontextprotocol/typescript-sdk@1.30.1...1.31.0

v1.30.1

Compare Source

What's Changed

• [v1.x] fix(server): read HTTP request bodies with a size limit and bound JSON-RPC batch length by @​maxisbey in #​2717
• fix(auth): preserve resource URI without trailing slash (#​1968) by @​MukundaKatta in #​1972
• chore: bump version to 1.30.1 by @​claude[bot] in #​2848

New Contributors

• @​MukundaKatta made their first contribution in #​1972

Full Changelog: modelcontextprotocol/typescript-sdk@1.30.0...1.30.1

---

Configuration

📅 Schedule: (in timezone Australia/Sydney)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!