A memory exhaustion bug in Go’s standard net/http library, tracked as CVE-2025-58186, can let remote attackers crash services with a flood of cookies—and Microsoft’s early advisory only told part of the story. While Redmond quickly patched its Azure Linux distribution, the flaw also lurks in official Go-based tools like the Azure SDK for Go and GitHub CLI. IT teams that don’t check their own environments could leave a door open for denial-of-service attacks.

On October 29, 2025, Go maintainers released security updates 1.24.8 and 1.25.2 to fix a resource exhaustion issue in cookie parsing. The ParseCookie function inside net/http had no cap on how many cookies it would accept per request. An attacker could send thousands of tiny cookies—think repeated a=; headers—forcing the server to allocate a struct for each. The result: uncontrolled memory consumption that can degrade performance or lead to an out-of-memory crash.

The fix introduces a default limit of 3,000 cookies and allows operators to tune that number via the GODEBUG=httpcookiemaxnum environment variable. The vulnerability doesn’t require elevated privileges or authentication; a single carefully crafted request can overwhelm an affected service. Go issue #75672 and the Go vulnerability database document the details.

Affected and Fixed Go Versions

Version Range Status
Go 1.24.x before 1.24.8 Vulnerable
Go 1.25.0 – 1.25.1 Vulnerable
Go 1.24.8 Fixed
Go 1.25.2 Fixed

Any binary built with a vulnerable Go toolchain includes the flawed net/http code, regardless of the operating system it runs on.

Where Microsoft Products Stand

Contrary to initial impressions, this isn’t just an Azure Linux story. Microsoft’s MSRC advisory for CVE-2025-58186, published shortly after disclosure, focused on Azure Linux because the distro ships Go as part of its open-source commitment. Redmond promptly patched that OS, and the advisory says, “If impact to additional products is identified, we will update the CVE.”

But Azure Linux is just one leaf on a much larger tree. Microsoft owns and maintains multiple Go projects that rely on net/http:
- Azure SDK for Go (azcore): Used by countless internal and customer apps to interact with Azure services. It imports net/http directly; any binary built with a vulnerable Go version inherits the flaw.
- GitHub CLI and GitHub Go libraries: GitHub, a Microsoft subsidiary, ships the gh command-line tool and other Go-based components. Windows users who installed GitHub CLI may be running a vulnerable binary.
- Azure DevOps agents and container images: Many agent distributions and container images from Microsoft bundle Go-based tooling. AKS nodes, IoT Edge containers, and even some Azure extensions can embed vulnerable binaries.

These products don’t automatically update themselves when a Go security release ships. Because Go binaries are often statically linked, the vulnerable code is baked into the executable—there’s no runtime patch you can apply at the OS level. That means IT teams must hunt down every instance of a Go-built binary in their environment.

Why This Isn’t a Typical Patch Tuesday

Windows admins are used to applying cumulative updates and moving on. CVE-2025-58186 flips the script: the vulnerability doesn’t live in Windows itself, and Microsoft’s standard update mechanisms won’t reach it. Even if your Windows Server 2025 boxes are fully patched, a Go-based microservice running inside a container on that server can still be wide open.

The core issue is that modern enterprises run dozens of tools written in Go, often without realizing it. Kubernetes components, Prometheus exporters, and even some Microsoft-authored PowerShell modules have Go under the hood. The forum analysis traced the vulnerability through Microsoft’s GitHub repositories, confirming that Azure SDK for Go and GitHub CLI actively import net/http. If your team built a custom Azure function using the Go SDK and compiled it with Go 1.24.7, you’re carrying the bug.

Microsoft’s decision to initially call out only Azure Linux is not unusual—vendors often start with products they directly ship as an OS and expand the advisory as internal scans progress. But that leaves a window where customers relying on MSRC alone may assume they’re safe. In reality, the CVE page is a starting point, not the final word.

Your Move: Detection and Mitigation Playbook

Don’t wait for MSRC to list every affected tool. Here’s what you can do right now:

1. Inventory Go Binaries

On Windows, look for executables that may be Go-built. Common candidates include gh.exe (GitHub CLI), azcopy.exe, or any custom agent installed under C:\AzureDevOps\. If you have Go installed, run:

go version -m path\to\binary.exe

That prints the Go version and module list. If Go isn’t available, use a tool like Sysinternals’ strings and search for the pattern go1. inside the binary; presence of a version string strongly suggests a Go build.

For container images, use scanning tools that can detect Go buildinfo. Trivy, Snyk, and even a simple docker run --entrypoint /bin/sh image -c "find / -type f -executable | xargs -I {} sh -c 'go version -m {} 2>/dev/null'" can surface Go binaries.

2. Check the Go Version

If a binary reports a build version older than 1.24.8 or in the 1.25.0–1.25.1 range, it’s vulnerable. Table above has the exact cutoff. For containers, inspect image labels or SBOMs if available; some Microsoft images now include version metadata.

3. Rebuild or Replace

  • In-house code: Rebuild with Go 1.24.8 or 1.25.2. Update any go.mod files and redeploy.
  • Third-party Microsoft binaries: Check the product’s GitHub releases or official download pages for an updated version compiled with a patched Go. For GitHub CLI, for example, verify the latest release notes mention the fix. If no update is available yet, consider mitigation (next step) and contact support.
  • Containers: Pull updated base images and redeploy your services. For AKS, Microsoft may provide patched node images; check the AKS release tracker.

4. Apply Runtime Mitigation (Temporary)

For any Go process you can’t immediately rebuild, set the environment variable:

GODEBUG=httpcookiemaxnum=3000

This caps cookie parsing at 3,000 (or a lower value you choose) and prevents the unbounded allocation. It’s not a permanent fix—the vulnerable code path still exists—but it limits memory exhaustion. This mitigation works only for binaries that read the GODEBUG environment variable (standard for Go programs). Add it to your service’s configuration or container spec while you plan a rebuild.

5. Monitor MSRC and Go Advisories

Bookmark the MSRC CVE-2025-58186 page. Microsoft may update it with a broader product list, including CSAF/VEX documents. Also watch the Go vulnerability database entry for any late-breaking guidance.

6. Long-term: Automate Go Buildinfo Scanning

Add a step to your CI/CD pipelines that runs go version -m on every built binary and fails the build if a vulnerable Go version is detected. Include Go versions in your SBOMs so you can cross-reference against announced CVEs without manual digging.

Watch This Space

CVE-2025-58186 is a wake-up call that language runtimes aren’t just an OS problem. As Microsoft continues its audit, expect additional entries in the MSRC advisory. However, the real lesson is that organizations must own the inventory of every executable they run—not just the base OS. Cookie bombs aren’t going away, but with a proactive scan-and-rebuild approach, you can stop them from exploding in your environment.