A bug in the Go programming language’s standard HTTP client can inadvertently leak sensitive headers—like Authorization tokens and session cookies—to unintended servers during a specific sequence of redirects. Tracked as CVE-2024-45336, the issue was disclosed via Microsoft’s Security Response Center (MSRC) and has been patched in updated Go releases. The flaw affects any software compiled with vulnerable versions of Go, which includes countless services, command-line tools, and container images running on Windows. While Microsoft has fixed the issue in its Azure Linux distribution, the real-world risk extends far beyond cloud infrastructure: every Windows administrator and developer who relies on Go-built tools needs to inventory their systems and apply updates immediately.

The Bug: How Go’s Redirect Logic Goes Wrong

When an HTTP client follows redirects, it’s common practice to strip sensitive headers like Authorization and Cookie before forwarding the request to a different host. This prevents credentials intended for one domain from being sent to another, potentially untrusted, domain.

The Go standard library’s net/http package implements this safeguard, but a flaw introduces a dangerous edge case. If a request is redirected from a.com to b.com (cross-domain), the client correctly drops sensitive headers for that hop. However, if the response from b.com issues another redirect to a different path on the same b.com domain, the client erroneously reattaches the previously stripped headers and sends them to the final destination. In effect, a chain like a.com → b.com/1 → b.com/2 can cause credentials meant only for a.com to land on b.com/2.

This bug was introduced in Go’s redirect handling code and remained undetected until a security researcher reported it. It has been fixed in the Go project’s release branches, but the affected versions span many widely deployed Go toolchains.

Who Is Affected? Not Just Azure Linux

Microsoft’s advisory on CVE-2024-45336 primarily addresses the impact on Azure Linux, a distribution Microsoft actively maintains. The MSRC page states: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?” The answer acknowledges that Azure Linux is the confirmed Microsoft product impacted, but the company will update the advisory if other products are identified.

In reality, the vulnerability is platform-agnostic. Any program compiled with an affected version of Go inherits the buggy HTTP client behavior, whether it runs on Windows, macOS, Linux, or in containers. Go’s static compilation means the vulnerable code is baked directly into the binary, unreachable for hot-patching by the operating system. That puts a wide range of Windows tools at risk: developer CLIs, monitoring agents, custom internal services, and third-party applications shipped as compiled executables.

Microsoft does not ship the Go toolchain as part of Windows, but countless Windows users run Go software. It’s up to the developers and vendors who distribute those binaries to rebuild them with a patched Go version. For IT administrators, this means checking every non-Microsoft binary in use for a potential Go dependency.

The Attack Scenario: How Redirect Chains Become Leaky

Exploitation of this bug requires a specific but not uncommon set of redirects. Here’s a typical flow:

  1. You or your software makes an authenticated request to service-a.com with an Authorization: Bearer <token> header.
  2. The server at service-a.com returns a 3xx redirect to cdn.example.net/path1 (a different host).
  3. Your Go-based HTTP client follows the redirect, correctly omitting the Authorization header from the request to cdn.example.net.
  4. The server at cdn.example.net responds with another redirect, this time to cdn.example.net/path2 (same host).
  5. Due to the bug, the client “remembers” the original Authorization header and attaches it to the request to cdn.example.net/path2.

An attacker who controls or compromises any server in the redirect chain—or who can influence redirects through open redirect vulnerabilities or malicious links—could steer your client into sending secrets to a host under their control. Once the token arrives, it may be logged, stored, or abused to impersonate the victim. The severity depends on what the token permits: a service token with broad access could be used to exfiltrate data, modify resources, or move laterally.

Patches and Industry Response

The Go project fixed the bug in its standard library and released updated Go versions. The exact version numbers vary by release branch, but as of this writing, the latest Go releases (1.22.x and 1.21.x series) include the patch. Microsoft’s MSRC advisory does not assign a specific KB number or Windows update; instead, the fix is delivered through the Go toolchain itself. For Azure Linux users, Microsoft has incorporated patched Go packages into the distribution’s repositories.

Third-party vulnerability databases and package feeds (like GitHub’s advisory database and various package scanners) list CVE-2024-45336 with CVSS scores in the mid-6 range, indicating a medium severity. Public proof-of-concept code exists, according to aggregation feeds, though no widespread active exploitation has been reported at the time of writing.

What Windows Users Must Do Now

If you’re a Windows developer, IT administrator, or power user who relies on Go-compiled tools, here’s your action plan:

1. Inventory All Go Binaries

Identify every binary on your systems that was built with Go. This includes:
- In-house microservices and command-line tools.
- Third-party tools that distribute executables (e.g., database CLIs, container tools like Docker, monitoring agents).
- Utilities installed via package managers like Chocolatey or Scoop, or downloaded from GitHub.
- Any software bundle that includes Go components.

If you have access to the source or build pipeline, check the Go version used (go version in build logs). For compiled binaries, you can often extract Go build information using tools like go version -m <binary> or GoReSym. Contact vendors for confirmation if the binary was built with a vulnerable toolchain.

2. Update Go and Rebuild

If you maintain Go software, immediately upgrade your Go toolchain to the latest patched release (e.g., go install golang.org/dl/go1.22.5@latest or equivalent minor version). Rebuild all your artifacts—including Docker images—and redeploy.

3. Rotate Potentially Exposed Credentials

Any bearer tokens, API keys, or session identifiers that may have been in use while vulnerable binaries were running should be considered compromised. Prioritize long-lived and high-privilege credentials. Revoke and reissue them after deploying the patched binaries.

4. Apply Immediate Mitigations if You Can’t Rebuild Yet

If rebuilding instantly is impossible, you can modify the HTTP client code to prevent the bug from being triggered. The most straightforward fix is to disable automatic redirect following and handle redirects manually, or to use CheckRedirect to strip sensitive headers on every redirect.

Example mitigation using CheckRedirect:

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        // Remove sensitive headers from every redirect
        req.Header.Del("Authorization")
        req.Header.Del("Cookie")
        return nil
    },
}

This ensures that no matter what the Go client’s internal logic does, sensitive headers are never sent on a redirect. Note that this may break flows that rely on token forwarding to legitimate subdomains; you’d need to implement more nuanced logic for those cases.

Alternatively, you can set CheckRedirect to return http.ErrUseLastResponse to stop all automatic redirects and handle them in your own code with explicit header sanitization and host validation.

5. Harden Your Environment

  • Monitor egress traffic for unexpected Authorization headers going to unfamiliar domains, especially from Go-based services.
  • Deploy network policies or egress firewalls to restrict outbound connections from your Go workloads to only known, trusted hosts.
  • Add redirect-chain tests to your CI/CD pipeline to catch any future regressions in HTTP client behavior.

The Long-Term View

The Go security team’s quick patch and transparent disclosure are positive signs, but the incident highlights a broader risk: foundational HTTP client libraries can contain subtle bugs that undermine security guarantees. As an industry, we’ve seen similar issues in other languages and frameworks, and they often lurk undiscovered for years.

For Windows environments that increasingly run Go-based tools—from Kubernetes utilities to desktop synchronization agents—the takeaway is clear: Go software isn’t automatically secured by the OS. It requires the same rigorous lifecycle management as any other dependency. Keep an inventory, watch for advisories like CVE-2024-45336, and plan to rebuild and redeploy quickly when patches land.

Microsoft’s advisory may have been triggered by the Azure Linux connection, but the vulnerability is a universal wake-up call. If you’re running Go on Windows, check your binaries today.