Go's net/http already strips the Authorization header when a redirect moves to a different host. Many teams stop there. It is a reasonable default and it does protect the common case. It has one gap, and the gap is where github-mcp-server was exposed.
The gap
The standard behavior covers headers set on the first request. The server used a transport called BearerAuthTransport that sets Authorization on every request it handles. A redirect creates a new request, the transport sees it, and it adds the token again. The header Go just stripped came back on the next hop.
A redirect that left the configured GitHub hosts would therefore have carried the token to the redirect target.
Why CheckRedirect is not the answer
The first idea is a CheckRedirect function that removes the header. It fails here for the same reason. Whatever it removes, the transport adds back before the request goes out. The decision about whether a host should receive the credential has to live in the transport, at the point where the header is set.
The change
Pull request #3056, merged on 18 August 2026, attaches the token only when the request host is one of the configured GitHub hosts: REST, GraphQL, upload and raw. A redirect to anywhere else travels without the credential. An empty AllowedHosts keeps the previous behavior, so existing setups are not broken. Tests cover the token reaching allowed hosts, being withheld from a non-allowed redirect target and from arbitrary hosts, and the empty default.
What this was, and was not
The PR says it directly: this is a hardening change, not a response to a known exploit. At the time, GitHub's own cross-host redirects, for release assets and archives, resolved to GitHub-owned hosts, so an attacker-controlled destination was not reachable. The patch removes a reliance on that fact. We think that is the right kind of fix to make before someone finds a way around the assumption.