Go's http.Client follows redirects automatically but only strips three headers—Authorization, Cookie, and WWW-Authenticate—on cross-host redirects. Every other header, including custom credential headers, passes through verbatim to the redirect target. This is the vulnerability: there's no API mechanism to mark arbitrary headers as sensitive, and the documentation describes what gets stripped rather than what doesn't, creating a false implication of broader protection.
The affected code is a video surveillance management agent that transmits private keys for Hub authentication via custom HTTP headers during an upload operation. When the server responds with a redirect to a third-party host, the client's default redirect following forwards the custom credential header to that unintended destination. The private key—persistent infrastructure credentials with no expiration—now resides in logs or systems outside the deployer's control.
The fix is a custom CheckRedirect function that inspects the request before each redirect and returns an error (preventing the redirect) when credential headers are present. Approximately ten lines of code. But discovering this was necessary requires understanding three things the library doesn't communicate: that cross-host redirects happen, that custom headers aren't stripped, and that CheckRedirect is the mitigation. Most developers encounter this vulnerability only after it's been exploited—the documentation provides no signal that this threat surface exists.
This pattern—standard auth headers protected, custom ones exposed—recurs across HTTP client libraries in every major language. The design philosophy of stripping only known credentials creates a trap for applications using custom authentication schemes, which are common in infrastructure software like this surveillance agent. The remediation assumes an actively maintained project; the private fork structure in the advisory suggests the maintainer's attention may have lapsed, meaning deployed instances could remain vulnerable well beyond any published patch timeline. Treat the absence of a CheckRedirect implementation in any Go HTTP client handling custom credentials as a finding, regardless of what the rest of the security review concludes.