Go net http Redirect Bug Leaks Sensitive Headers CVE-2024-45336

A subtle bug in the Go standard library’s net/http client can restore and transmit sensitive headers after a specific sequence of redirects, potentially leaking Authorization tokens and other credentials to unintended targets—security teams and Go developers must treat this as a material risk and apply fixes immediately.

Background​

The Go standard library’s net/http package implements an HTTP client used widely across cloud services, command-line tools, and server-side applications. A core safety rule in many HTTP clients is that sensitive headers—notably Authorization, Cookie, and similar credentials—should not be forwarded when a request is redirected across domains. That rule prevents a token intended for one service from being leaked to a different host that may be untrusted or attacker-controlled.
A bug discovered in net/http breaks that expectation in a narrowly-defined but practical scenario. When an initial request with sensitive headers follows a cross-domain redirect, net/http correctly drops those headers for the cross-domain hop. However, if the redirection chain then continues with a same-domain redirect on the new host, the client can restore the previously dropped sensitive headers and send them to the final same-domain destination. In other words, a.com → b.com/1 → b.com/2 may cause Authorization headers to be sent to b.com/2 even when they were rightfully dropped when the client first moved from a.com to b.com.
This behavior is tracked as CVE-2024-45336 and has been fixed in the Go release branches after discovery. The bug was reported by a security researcher and patched in the Go project; vendor advisories and package-vulnerability feeds list the issue and the versions affected.

---

What happened: a technical summary​

• The net/http client attempts to be conservative with sensitive headers when redirecting across domains: when the destination host differs from the origin, headers like Authorization and Cookie are removed to avoid credential leakage.
• A bug in the redirect handling logic causes the client to reconstitute those dropped headers if a later redirect occurs within the same host that received the prior cross-domain redirect.
• The result: a token that should not have been sent to the second domain in a redirect chain can end up transmitted to a later same-domain endpoint, exposing secrets to services that never should have received them.
• The problem requires a sequence of redirects (cross-domain then same-domain) which is not uncommon in real-world web flows (CDNs, authentication redirects, load balancers, API gateways).

Why this matters in practice​

Many production systems rely on short-lived bearer tokens, API keys in Authorization headers, or cookie-based session tokens. Attackers who can induce or control redirect chains—either by compromising an intermediary or by influencing server-side redirect configurations—could steer a client into sending secrets to a host that should never receive them. The vulnerability reduces the guarantee that net/http provides about not leaking credentials across origins.

---

Scope and affected versions​

The issue affects the standard library’s net/http client implementations in Go releases prior to the fixes applied on the project’s release branches. The practical outcome for administrators and developers:

• Systems compiled with affected Go toolchains may include the vulnerable client behavior, regardless of the OS they run on.
• Statically linked binaries that embed a vulnerable Go runtime (typical for Go programs) are affected until rebuilt with a patched toolchain.
• Container images and packages that include older Go toolchains or link in older net/http libraries remain vulnerable until updated and redeployed.

Patched releases were produced on the Go release branches; the versions carrying the fix are the first stable releases that include the net/http redirect-handling patch. Because release numbering and branch names vary, the reliable mitigation is to upgrade the Go toolchain to the first release on your channel that includes the net/http fix, rebuild your binaries, and redeploy.
Note: different vulnerability databases and vendor advisories may list slightly different CVSS or severity labels (the reported scores cluster around the mid‑range). Those numerical ratings vary by scoring authority and should be treated as guidance rather than absolute truth.

---

Attack scenarios and practical impact​

Typical exploitation chain​

• A client makes an authenticated request to a legitimate service at a.com with Authorization: Bearer <token>.
• a.com responds with a redirect (3xx) to b.com/1 (cross-domain). The client correctly drops or omits the Authorization header when following this redirect.
• b.com/1 responds with another redirect to b.com/2 (same-domain redirect on b.com). Due to the bug, the client mistakenly reattaches the Authorization header and sends it to b.com/2.
• If b.com is controlled by an attacker or an intermediate service is compromised, the token ends up exposed to an unintended party.

Why attackers might be able to exploit this​

• Redirects are widely used for SSO flows, CDN re-routing, vanity URL handling, and load balancer chains. Attackers who can manipulate any redirect in the chain—via compromised origins or maliciously-crafted links—could construct a chain that triggers the bug.
• Servers accepting requests from unknown clients or third-party origins may log or persist Authorization headers, increasing the damage once the header appears on an unintended host.
• Some tokens grant access to sensitive APIs or persistent sessions, magnifying the impact of a single leak.

Realistic impact assessment​

• Confidentiality: The primary impact is information exposure. If an Authorization header contains a bearer token for a high-privilege API, exposure could let an attacker make authenticated calls until the token is revoked.
• Integrity & Availability: This bug does not directly modify data or stop services, but leaked credentials could be used to perform actions that affect integrity or availability.
• Practical severity: Medium in most environments—serious when tokens or credentials used are long-lived or allow wide access.

---

How to detect exposure and prioritize response​

• Inventory: Identify all services, binaries, and containers compiled with Go toolchains affected by the net/http issue. This includes CLI tools, agents, microservices, and any product that bundles Go.
• Build-time detection: Search build pipelines and CI artifacts for the Go versions used during compilation. Look for builds that used older toolchains.
• Runtime detection: Investigate logs and network captures for unexpected Authorization headers sent to domains that should not receive them. Watch for 3xx response patterns that match the cross-domain → same-domain chain described above.
• Threat prioritization: Prioritize systems that:
• Handle high-privilege or long-lived tokens.
• Perform automatic redirect-following without additional validation.
• Are publicly exposed and frequently access third-party hosts.

---

Immediate mitigation steps (fast actions)​

• Stop the bleeding: If upgrading the toolchain is not immediately possible, disable automatic redirect-following in vulnerable clients and handle redirects manually.
• In Go, set http.Client.CheckRedirect to return http.ErrUseLastResponse to receive the redirect response instead of automatically following it.
• Remove sensitive headers before following redirects under your own redirect code. For manual redirect handling, explicitly strip Authorization and Cookie headers unless the target host is known-trusted and intended.
• Rotate tokens that may have been exposed, especially long-lived API keys or service tokens.
• Rebuild and redeploy: prioritize updating the Go toolchain to a patched release and rebuilding all statically-linked binaries.
• Add egress controls and logging to detect tokens being sent to unexpected domains.

---

Recommended patch and upgrade guidance​

• Upgrade Go to the patched release for your branch as soon as it is available. The fix is present in the Go release branches after the patch was merged; upgrade your builds to a patched toolchain, rebuild applications, and redeploy.
• For systems where updating the toolchain is heavy-weight:
• Vendor the net/http package or apply a backported patch at build time (for teams that can vet a targeted patch).
• Use runtime mitigation by turning off automatic redirect following and using a safe, audited redirect handler.
• After upgrading, rebuild and redeploy all binaries, container images, and packages that may include the vulnerable client.
• If you rely on packaged distributions (OS packages, containers from registries), verify vendor advisories for fixed package releases and apply those updates per your normal patching workflow.

Quick developer checklist​

• Run go version in CI/build servers and developer machines to identify toolchains used.
• For each build artifact, confirm the Go toolchain version embedded or compile-time used.
• Upgrade the Go toolchain used by builds to the patched release.
• Rebuild all artifacts, re-run tests, and redeploy.
• Rotate any secrets that might have been exposed by prior artifacts.

---

Code-level mitigations and examples​

If immediate upgrading is not possible, add one of these mitigations to client code to avoid accidental leaking of sensitive headers during redirects.

Option A — disable automatic redirect following and handle redirects explicitly​

• Disable redirects at the client level.
• Inspect the Location header of 3xx responses.
• Explicitly follow only trusted locations; strip or re-add headers based on explicit trust checks.

Example (Go):

client := &http.Client{ CheckRedirect: func(req *http.Request, via []*http.Request) error { // Prevent automatic following of redirects. return http.ErrUseLastResponse },
} // Make request and inspect response manually
resp, err := client.Get("[url]https://a.example/[/url]")
if err != nil { // handle error
}
defer resp.Body.Close if resp.StatusCode >= 300 && resp.StatusCode < 400 { loc, err := resp.Location if err == nil { // Validate loc.Host explicitly before following if isTrustedHost(loc.Host) { // Create new request with safe headers for trusted host req, _ := http.NewRequest("GET", loc.String, nil) // Optionally set Authorization if trusted // req.Header.Set("Authorization", "Bearer ...") resp2, err := client.Do(req) // ... } }
}

Option B — use CheckRedirect to strip sensitive headers on any redirect​

This approach uses CheckRedirect to remove sensitive headers for redirected requests so that even if net/http would try to reattach headers, the CheckRedirect hook will sanitize the outgoing request.
Example (Go):

client := &http.Client{ CheckRedirect: func(req *http.Request, via []*http.Request) error { // Remove any sensitive headers from the redirect request req.Header.Del("Authorization") req.Header.Del("Cookie") // If proxy headers should be removed: req.Header.Del("Proxy-Authorization") return nil // allow redirect to proceed },
}

This is a safe stopgap because it runs on each redirect and ensures that redirects do not carry sensitive header values.

---

Operational recommendations for Windows administrators and developers​

• Identify all Windows services, scheduled tasks, and packaged apps that include Go binaries. Many desktop and server-side tools distributed on Windows are compiled with Go and may be vulnerable.
• Use the go version command where you have source or build capability. For compiled binaries, ask vendors for the Go version used to build the product or verify package metadata.
• For Windows systems using packaged installers or vendor-provided executables, check vendor advisories and apply vendor-supplied updates.
• For containerized workloads running on Windows nodes, rebuild and publish updated container images after updating the Go toolchain.
• For enterprise environments with multiple teams, add this vulnerability to centralized vulnerability management and coordinate token rotation where necessary.

---

Testing and validation​

After applying a fix or mitigation:

• Run unit and integration tests for any code paths that perform redirects.
• Create controlled redirect chains in a test environment to validate that Authorization and Cookie headers are not sent to untrusted hosts.
• Use network captures (pcap) or application-layer logs to confirm that outgoing requests behave as expected.
• If CheckRedirect was used to disable or strip headers, assert that downstream functionality relying on automatic forwarding still operates correctly (or update the flow to support manual reauthorization if required).

---

Longer-term hardening and risk reduction​

• Avoid embedding long-lived tokens in Authorization headers for flows that may follow redirects. Use short-lived tokens and one-time flows where possible.
• Prefer OAuth flows with explicit redirects mediated by the browser or a secure token exchange, and avoid server-side redirect chains that are opaque to the application.
• Apply network egress controls and data-loss prevention (DLP) rules to detect sensitive headers being transmitted to unexpected external hosts.
• Add tests in CI that emulate redirect chains to catch regressions in future releases of net/http or other HTTP client libraries.

---

Risk, severity, and public proof-of-concept status​

• Severity: The practical severity is medium for most deployments; systems that use high-privilege or long-lived tokens face elevated risk.
• CVSS: Public vulnerability feeds report CVSSv3 scores in the mid-6 range or slightly lower depending on scoring authority. Differences stem from how confidentiality and scope are assessed.
• Proof-of-concept: Aggregators and some vulnerability feeds reference the existence of public PoC code on public code hosting sites. Treat such claims cautiously: if a public PoC is discovered in the wild, prioritize patching and token rotation immediately. If any sign of exploitation is found in logs or telemetry, assume potential compromise and respond accordingly.

If confirmation of a public exploit or active exploitation is needed for your environment, perform targeted telemetry searches and consult vendor advisories—do not rely solely on aggregator claims.

---

Strengths of the response and potential residual risk​

• The Go project has a mature security process and the net/http bug was addressed in the release branches; the availability of patches and the open discussion in the project provides transparency.
• Patching and rebuilding remove the vulnerable behavior; the fix is demonstrated in release branches and backport candidates.
• Residual risk remains for long-lived binaries, devices, or third-party vendors that do not promptly rebuild and distribute patched artifacts. The real-world risk is concentrated where credentials are long-lived, where redirect chains are common, or where third-party services can manipulate redirects.

---

Final checklist: what to do right now​

• Inventory all Go-built artifacts and identify the toolchain versions used to build them.
• Upgrade your Go toolchain to a version that includes the net/http redirect fix and rebuild artifacts.
• If immediate upgrade is impossible, apply one of the code-level mitigations: disable automatic redirects or strip sensitive headers in CheckRedirect.
• Rotate credentials that may have been exposed, giving highest priority to long-lived or high-privilege tokens.
• Add redirect-chain tests to CI to detect regressions or future related issues.
• Review ingress/egress logs for anomalous transmissions of Authorization or Cookie headers to unexpected domains.
• Coordinate with third-party vendors to ensure any packaged products are rebuilt and updated.

---

This is a reminder that the security of HTTP client behavior is a foundation for modern distributed systems. Redirects may look harmless, but they are an easy vector for unexpected data flow. Applying the available fixes, rebuilding artifacts, and hardening redirect-handling logic will substantially reduce exposure and return the net/http client to its intended security posture.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center