CVE-2024-45336: HTTP Client Header Leakage Vulnerability

CVE-2024-45336 Overview

CVE-2024-45336 is an information disclosure vulnerability in the Go standard library net/http client. The HTTP client correctly strips sensitive headers such as Authorization when following a cross-domain redirect. However, the client incorrectly restores those headers if a subsequent redirect returns to a same-domain target. A redirect chain from a.com/ to b.com/1 and then to b.com/2 will incorrectly forward the original Authorization header to b.com/2. Applications written in Go that issue authenticated HTTP requests and follow redirects can leak credentials to untrusted hosts. The Go security team tracks this issue as GO-2025-3420.

Critical Impact
Sensitive headers including Authorization can leak to untrusted third-party hosts during multi-hop redirect chains, exposing bearer tokens and credentials.

Affected Products

Go standard library net/http package (versions prior to the GO-2025-3420 fix)
Applications and services built with affected Go versions that follow HTTP redirects
NetApp products bundling affected Go runtimes (see NetApp advisory NTAP-20250221-0003)

Discovery Timeline

2025-01-28 - CVE-2024-45336 published to NVD
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-45336

Vulnerability Analysis

The Go net/http client implements redirect handling that distinguishes between same-domain and cross-domain redirects. Sensitive headers such as Authorization, Cookie, and WWW-Authenticate are intentionally stripped when the redirect target moves to a different host. This behavior protects credentials from being forwarded to hosts the user did not authenticate against.

The defect lies in how the client tracks header state across multiple redirect hops. After stripping sensitive headers on a cross-domain hop, the client does not persist the "stripped" state. When a later redirect returns to a host considered same-domain relative to the previous hop, the client restores the original headers from the initial request. This restoration sends credentials to a host that was reached only via an untrusted intermediate.

The issue is classified as information exposure through redirect handling. Exploitation requires an attacker to control a redirect chain that an authenticated Go HTTP client will follow, which often involves user interaction or a server that returns attacker-controlled Location headers.

Root Cause

The root cause is incorrect state management in the redirect logic of net/http. The client evaluates header forwarding based on the immediate hop rather than the full provenance of the redirect chain. Once a request has traversed an untrusted domain, any sensitive headers from the original request should remain stripped for the remainder of the chain.

Attack Vector

A remote attacker who controls or compromises a web server in a redirect chain can craft Location responses that bounce the Go HTTP client through an attacker domain and back to a host of the attacker's choosing. The Go client will then restore the Authorization header and deliver it to the final destination. The attack requires the victim application to issue authenticated requests and follow redirects automatically, which is the default http.Client behavior. See the Go Vulnerability Report GO-2025-3420 for the upstream technical write-up.

Detection Methods for CVE-2024-45336

Indicators of Compromise

Outbound HTTP requests from Go-based services containing Authorization headers directed at unexpected external hosts.
Server access logs on third-party services receiving bearer tokens or basic-auth credentials that were never explicitly provisioned for those endpoints.
Redirect chains in proxy logs that traverse multiple distinct domains within a single client transaction.

Detection Strategies

Inventory Go binaries and container images using software composition analysis to identify builds linked against vulnerable Go versions prior to the GO-2025-3420 fix.
Inspect egress traffic for HTTP 302/307/308 chains that cross organizational trust boundaries while carrying authentication headers.
Review application code for use of http.DefaultClient or custom clients without a CheckRedirect policy that constrains cross-domain hops.

Monitoring Recommendations

Forward web proxy and TLS-inspection logs to a centralized analytics platform and alert on Authorization headers sent to domains outside an allowlist.
Track Go runtime versions across build pipelines and flag deployments that ship vulnerable toolchains.
Monitor authentication backends for unexpected token replay from third-party IP ranges, which can indicate leaked credentials.

How to Mitigate CVE-2024-45336

Immediate Actions Required

Upgrade Go toolchains and rebuild affected binaries using a Go release that includes the fix from change list go.dev/cl/643100.
Audit services that issue authenticated outbound HTTP calls and confirm they are rebuilt against a patched Go runtime.
For NetApp customers, apply updates referenced in the NetApp Security Advisory NTAP-20250221-0003.

Patch Information

The Go team fixed this defect in net/http via the change tracked at Go Issue 70530 and merged in Go CL 643100. The fix ensures that once a redirect chain crosses a domain boundary, sensitive headers from the original request are not restored on subsequent same-domain hops. Consumers must rebuild applications with a patched Go release; runtime hot-patching is not possible because net/http is statically linked.

Workarounds

Implement a custom CheckRedirect function on the http.Client that rejects redirects crossing domain boundaries, or strips Authorization from req.Header on every redirect hop.
Disable automatic redirect following by returning http.ErrUseLastResponse from CheckRedirect and handle redirects explicitly in application code.
Restrict outbound HTTP egress from Go services to an allowlist of trusted hosts using a forward proxy or service mesh policy.

bash

# Configuration example: enforce manual redirect handling in Go
# (apply at the application layer until the Go runtime is upgraded)
#
# client := &http.Client{
#     CheckRedirect: func(req *http.Request, via []*http.Request) error {
#         req.Header.Del("Authorization")
#         req.Header.Del("Cookie")
#         return nil
#     },
# }