MCP Redirect Vulnerability: mcp-go 1.5.0 Sent Our Refresh Token to Another Host

Updated November 10, 2026. Lab run on loopback only: mcp-go v1.5.0 and main 2f5b963, official Go SDK v1.8.0 and main 0e849cb, TypeScript SDK 1.32.2, Python SDK 2.3.0.

An MCP redirect vulnerability is still live in the latest release of mcp-go, the community Go library for the Model Context Protocol (MCP) with about 9,200 GitHub stars, more than the official Go SDK’s 5,300. The Go vulnerability database published GO-2026-6911 on November 5, 2026, and the fix merged on November 9 has not shipped in a release. The official MCP Go SDK has the same gap in its latest release, v1.8.0, with no advisory at all.

On November 10 we pointed each client at an MCP endpoint that answered with a 307 redirect to a second host we controlled. mcp-go v1.5.0 delivered our API key header, the JSON-RPC request, and, during an OAuth token refresh, the refresh token and client secret to that second host. The official TypeScript and Python SDKs refused the redirect by default, and Claude Code shipped its own fix for refresh tokens in version 2.1.321 on November 9. Go teams that connect to MCP servers they do not fully control should set a redirect policy on their HTTP client today.

What GO-2026-6911 Says About mcp-go Redirects

GO-2026-6911 says the mcp-go client follows any HTTP redirect an MCP server sends and carries the credentials it was configured with to the new host. NewStreamableHTTP builds an http.Client with no CheckRedirect policy, so the client goes wherever the Location header points, with its custom headers and, for subdomain targets, its OAuth bearer token.

An HTTP redirect is a 3xx response that tells the client to repeat the request at another URL. A 307 or 308 redirect also tells the client to keep the method and resend the body, which for an MCP client is the JSON-RPC message and for an OAuth client is the token request form. The Go team rates the report as reviewed, credits the researcher kanywst, and lists the affected range as all versions with no known fix.

The record has one bookkeeping error. Its references point to mcp-go issue 1164, which reports a different bug about case-insensitive JSON-RPC member names, so readers following the links will not find the redirect report there. The authoritative fix for GO-2026-6911 is mcp-go pull request 1192, not issue 1164.

Why CVE-2026-123272 Is a Different mcp-go Bug

CVE-2026-123272 is a separate mcp-go OAuth flaw that was fixed in v1.2.1 on October 9, 2026, and published as a CVE on November 5. It covers protected resource metadata: before v1.2.1, a malicious MCP server could name another server as its OAuth resource and get the authorization server to mint tokens for that other server.

Some vulnerability roundups published this week describe the redirect leak inside the CVE-2026-123272 summary. That framing is risky for anyone who upgraded to v1.2.1 or later and assumed the redirect problem went with it. Our lab ran v1.5.0, which includes the CVE-2026-123272 fix, and it still forwarded credentials across a redirect.

Identifier	What it covers	Affected	Fixed in	Score
GO-2026-6911	Streamable HTTP, SSE, and OAuth clients follow cross-origin redirects with headers, tokens, and bodies	All mcp-go releases through v1.5.0	PR 1192 merged November 9, 2026; no release	None assigned
CVE-2026-123272 (GHSA-h3x9-8c36-m89w)	Unvalidated resource in well-known protected resource metadata	mcp-go before v1.2.1	v1.2.1, October 9, 2026	CVSS 3.1 8.0 / CVSS 4.0 5.1
CVE-2026-123271 (ChatCLI)	MCP OAuth discovery and SSE endpoint events allow cross-origin token minting	ChatCLI before v1.215.2	v1.215.2	CVSS 3.1 8.0

What Our Lab Found Across Four MCP Client SDKs

Our lab found that the two Go libraries leak in their latest releases while the official TypeScript and Python SDKs do not. An MCP endpoint on 127.0.0.1 answered every request with a 307 to a recorder on localhost, a different host name, which logged what each client sent with its API key and bearer token.

mcp-go v1.5.0 sent the X-API-Key header to the second host on both the discovery request and initialize, along with the full JSON-RPC body. In the v1.5.0 source, mcp-go sets its headers on each request before sending, so net/http copies them to the redirected request but drops Authorization when the new host is not the old host or a subdomain of it. The mcp-go fix notes say Authorization survives a subdomain redirect, which we did not test.

The OAuth result matters more for most teams. We configured mcp-go’s OAuth handler with a token endpoint that redirected, then called RefreshToken. The recorder received this request body:

POST /token
client_id=lab-client&client_secret=lab-client-secret-CCCC3333&grant_type=refresh_token&refresh_token=lab-refresh-DDDD4444

A refresh token and client secret that reach another host give that host a long-lived way to mint new access tokens. The same refresh against mcp-go main at commit 2f5b963 failed with “refusing cross-origin redirect” and the recorder logged nothing. All values in our lab were dummy strings on loopback interfaces.

Is the Official MCP Go SDK Affected Too?

The official MCP Go SDK v1.8.0, released September 14, 2026, forwarded credentials in our test when they were added by a custom http.RoundTripper. Both the X-API-Key header and the Authorization bearer reached the second host. A fix restricting redirects to the same origin merged on October 23 as pull request 1440, but no release includes it.

The reason Authorization survived in the Go SDK test and not in the mcp-go test is where the header gets attached. Go’s net/http strips sensitive headers it copies to a new host, but a RoundTripper runs again on every hop and sets the header fresh. Wrapping the SDK client with golang.org/x/oauth2 transport works the same way, which is our inference from that package’s design rather than a separate test.

The SDK has no advisory for this behavior. Issue 1429 framed it as a security concern on October 21, and the repository’s published advisories do not include it. govulncheck reported no vulnerabilities for a program calling the Go SDK v1.8.0 transport, so a clean scan is not evidence that a Go MCP client is safe from redirect leaks.

How the TypeScript and Python SDKs and Claude Code Fixed It

The official TypeScript and Python SDKs fixed this MCP redirect vulnerability class in October 2026, and both now follow only same-origin redirects by default. CVE-2026-111769 covers @modelcontextprotocol/sdk through 1.31.0 and @modelcontextprotocol/client 2.0.0 to 2.2.0, and CVE-2026-116685 covers the Python mcp package before 1.30.0 and 2.2.0.

Both SDK advisories describe the exposure in the same terms as GO-2026-6911: custom headers, the session ID, and 307 or 308 bodies, including OAuth token requests with refresh_token and client_secret, could reach another origin. The TypeScript advisory adds that current fetch runtimes already drop Authorization across origins, which matches our result. Setting redirectPolicy: 'follow' on TypeScript SDK 1.32.2 brought the leak back in our lab.

Anthropic’s Claude Code 2.1.321, released November 9, 2026, lists a fix for MCP OAuth requests sending secrets such as refresh tokens to another host when a server redirected them. The changelog gives no version range or advisory, and we did not test Claude Code itself. Teams that use Claude Code with remote MCP servers that require OAuth should update to 2.1.321 or later.

What Go Teams Using MCP Clients Should Do Now

Go teams should give mcp-go and the official Go SDK their own HTTP client with an explicit redirect policy instead of waiting for releases. Both libraries keep a caller-supplied client’s CheckRedirect as it is, so the fix works on v1.5.0 and v1.8.0 today. Refusing redirects outright is the simplest policy.

This is the change we tested on mcp-go v1.5.0. With it, the same 307 produced an error and the recorder logged nothing:

noRedirects := &http.Client{
	CheckRedirect: func(req *http.Request, via []*http.Request) error {
		return http.ErrUseLastResponse
	},
}
t, _ := transport.NewStreamableHTTP(serverURL,
	transport.WithHTTPBasicClient(noRedirects),
	transport.WithHTTPHeaders(map[string]string{"X-API-Key": apiKey}))

1. Pass a client with CheckRedirect to every mcp-go transport through WithHTTPBasicClient, and to the OAuth handler through OAuthConfig.HTTPClient, because the handler builds its own client otherwise.
2. Set HTTPClient.CheckRedirect on the Go SDK’s StreamableClientTransport, or move to a release that includes pull request 1440 once one ships.
3. Upgrade the TypeScript SDK to 1.32.0 or later and the Python SDK to 1.30.0 or 2.2.0 or later, and remove any redirectPolicy: 'follow' setting.
4. Update Claude Code to 2.1.321 or later on machines that connect to OAuth protected MCP servers.
5. Rotate API keys, client secrets, and refresh tokens used against any MCP server you do not operate if a client on an affected version ever connected to it.

Choose the explicit CheckRedirect client now when your Go agent connects to third-party or user-supplied MCP servers, because a single malicious redirect is enough to move credentials. Waiting for the next mcp-go release is reasonable only when every server URL is yours and sits behind infrastructure you control. Neither path helps credentials already sent, so rotate first if an affected client talked to an untrusted server. Stdio MCP servers are outside this issue, since they never make HTTP requests.

Where Redirect Leaks Fit in MCP Client Security

Redirect leaks are a client-side MCP risk, and most MCP security coverage focuses on servers. A malicious or compromised MCP server sits in a position to send redirects to every client that connects, so client libraries have to treat server responses as untrusted input, the same lesson this year’s server-side advisories taught.

Our coverage of FastMCP security advisories tracked client code execution triggered by malicious servers, and the MCP Inspector 2.14.0 security fixes covered a debugging client that trusted server content too far. The AgentScope MCP workspace flaw showed the server-side mirror of the same trust problem.

For controls beyond any single SDK, our MCP gateways roundup covers gateways that pin server URLs and hold credentials centrally, and the MCP security tools guide and AI agent security tools guide cover scanning and policy enforcement. Teams still mapping their server inventory can start with our MCP servers guide and the MCP explainer.

mcp-go is not the only client this month that sent a credential to the wrong host. LLM 0.37.1 and earlier sent an OpenAI API key to a custom api_base when a named key was missing or a Responses model used -o chat_completions 1. Our LLM 0.37.2 OpenAI key leak test checks 13 configurations against the fix.

The same month, a gateway sent a credential to the wrong place for a related reason. IBM ContextForge MCP Gateway 1.0.11 and earlier posted an OAuth client registration to any endpoint an authorization server named, including internal hosts, until the 1.1.0 fix. Our ContextForge MCP Gateway SSRF analysis tests the leak and the fix.

FAQ