<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 06 Nov 2026 13:23:43 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-111769</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-111769</link>
      <description>&lt;p&gt;The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. Prior to 1.32.0 in @modelcontextprotocol/sdk and from 2.0.0 until 2.3.0 in @modelcontextprotocol/client, the HTTP client transports and OAuth client requests followed redirects to a different origin while retaining custom request headers and, for HTTP 307 or 308 responses, request bodies. The affected surfaces are StreamableHTTPClientTransport, SSEClientTransport, and OAuth client functions such as auth(). The trigger is an HTTP redirect to another origin. Custom headers and mcp-session-id can be re-sent to the redirected origin. HTTP 307 and 308 redirects can also re-send the request body. OAuth request bodies can contain refresh_token and client_secret values. Current runtimes already strip the Authorization header across origins. stdio clients do not use the affected HTTP path. A malicious or compromised MCP or authorization server could therefore receive API keys, session identifiers, OAuth refresh tokens, or OAuth client secrets. Restoring unrestricted redirect following after upgrading restores the exposure. This issue is fixed in @modelcontextprotocol/sdk 1.32.0 and @modelcontextprotocol/client 2.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. Prior to 1.32.0 in @modelcontextprotocol/sdk and from 2.0.0 until 2.3.0 in @modelcontextprotocol/client, the HTTP client transports and OAuth client requests followed redirects to a different origin while retaining custom request headers and, for HTTP 307 or 308 responses, request bodies. The affected surfaces are StreamableHTTPClientTransport, SSEClientTransport, and OAuth client functions such as auth(). The trigger is an HTTP redirect to another origin. Custom headers and mcp-session-id can be re-sent to the redirected origin. HTTP 307 and 308 redirects can also re-send the request body. OAuth request bodies can contain refresh_token and client_secret values. Current runtimes already strip the Authorization header across origins. stdio clients do not use the affected HTTP path. A malicious or compromised MCP or authorization server could therefore receive API keys, session identifiers, OAuth refresh tokens, or OAuth client secrets. Restoring unrestricted redirect following after upgrading restores the exposure. This issue is fixed in @modelcontextprotocol/sdk 1.32.0 and @modelcontextprotocol/client 2.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-111769</guid>
    </item>
    <item>
      <title>GHSA-6prh-2h8m-c8cw — MCP TypeScript client SDK: HTTP client transports and OAuth requests followed cross-origin redirects and re-sent custom…</title>
      <link>https://db.gcve.eu/vuln/ghsa-6prh-2h8m-c8cw</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @modelcontextprotocol/sdk, npm: @modelcontextprotocol/client&lt;/p&gt;
&lt;p&gt;### Summary
In affected versions, the SDK&amp;#39;s HTTP client transports and OAuth requests followed redirects to any origin.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;On current runtimes `fetch` already drops the `Authorization` header across origins.&lt;/p&gt;
&lt;p&gt;### Am I affected?
Yes, if your application uses `StreamableHTTPClientTransport`, `SSEClientTransport`, or the SDK&amp;#39;s OAuth client functions such as `auth()`. stdio clients are not affected.&lt;/p&gt;
&lt;p&gt;Affected versions:&lt;/p&gt;
&lt;p&gt;- `@modelcontextprotocol/sdk` all versions through 1.31.0
- `@modelcontextprotocol/client` 2.0.0 through 2.2.0&lt;/p&gt;
&lt;p&gt;### Fix
Upgrade to:&lt;/p&gt;
&lt;p&gt;- 1.x: `@modelcontextprotocol/sdk` 1.32.0 or later
- 2.x: `@modelcontextprotocol/client` 2.3.0 or later&lt;/p&gt;
&lt;p&gt;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: &amp;#39;follow&amp;#39;` on a transport restores the old behaviour and the exposure.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, pass a `fetch` that refuses r…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @modelcontextprotocol/sdk, npm: @modelcontextprotocol/client&lt;/p&gt;
&lt;p&gt;### Summary
In affected versions, the SDK&amp;#39;s HTTP client transports and OAuth requests followed redirects to any origin.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;On current runtimes `fetch` already drops the `Authorization` header across origins.&lt;/p&gt;
&lt;p&gt;### Am I affected?
Yes, if your application uses `StreamableHTTPClientTransport`, `SSEClientTransport`, or the SDK&amp;#39;s OAuth client functions such as `auth()`. stdio clients are not affected.&lt;/p&gt;
&lt;p&gt;Affected versions:&lt;/p&gt;
&lt;p&gt;- `@modelcontextprotocol/sdk` all versions through 1.31.0
- `@modelcontextprotocol/client` 2.0.0 through 2.2.0&lt;/p&gt;
&lt;p&gt;### Fix
Upgrade to:&lt;/p&gt;
&lt;p&gt;- 1.x: `@modelcontextprotocol/sdk` 1.32.0 or later
- 2.x: `@modelcontextprotocol/client` 2.3.0 or later&lt;/p&gt;
&lt;p&gt;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: &amp;#39;follow&amp;#39;` on a transport restores the old behaviour and the exposure.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, pass a `fetch` that refuses r…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-6prh-2h8m-c8cw</guid>
    </item>
  </channel>
</rss>
