Go net http CVE-2025-58186 Impact Across Microsoft Products

Executive summary — short answer

• No. Azure Linux is not the only Microsoft product that can include the vulnerable net/http code. Any Microsoft product, service, agent, SDK, or container image that ships or vendors Go binaries (or Go-based packages) built with the vulnerable versions of the Go standard library may be affected. Examples include Microsoft-maintained Go projects such as the Azure SDK for Go and Microsoft‑owned projects (e.g., GitHub’s Go CLI components) that use the Go standard library’s net/http. For details about the vulnerability, the Go project’s tracking issue and multiple vulnerability databases describe the problem and the fixes.

Why I’m answering this now

• You linked Microsoft’s MSRC statement that highlights Azure Linux and says Microsoft will update the CVE if more products are affected. That statement is correct as a product-specific disclosure, but it does not imply Azure Linux is the only Microsoft product that uses the Go net/http library. Microsoft ships or supports multiple Go-based components and SDKs; any of those that include a vulnerable Go runtime or vendor the vulnerable net/http code must be assessed and, if necessary, updated. The Go vulnerability itself, and its remediation, are public and independent of a single Microsoft product.

Technical background (what the bug is and how it was fixed)

• The problem (CVE-2025-58186): net/http’s cookie parsing had no limit on the number of cookies accepted. Even though overall HTTP header bytes are limited (MaxHeaderBytes), the library would happily parse many tiny cookies (for example, many repeated "a=;") and allocate one struct per cookie, allowing an attacker to force large memory allocations from a single request. The result is uncontrolled resource consumption (availability impact).
• The fix: the Go project limited the number of cookies parsed to a default of 3,000 and added an httpcookiemaxnum GODEBUG knob so operators can tune that value. The fix is tracked in the Go issue tracker and was included in the security releases.
• Fixed releases: the vulnerability was fixed in the Go security releases (Go 1.24.8 and Go 1.25.2 — upgrade targets for most users). If you build your own Go binaries, you should use patched toolchains or rebuild with patched standard libraries.

What “includes this open‑source library” really means in practice

• Two different ways a product can “include” net/http:
• The product is written in Go and was built with a Go toolchain that included a vulnerable net/http (the Go stdlib is compiled into your binary). This is the most direct case: the vulnerable code is inside the executable or library that the product ships.
• The product ships other software (agents, containers, SDKs, plugins) that themselves bundle Go-based binaries or vendor Go libraries (for example, a container image that installs a Go-based service or Go-based agent). In that case the product “includes” the vulnerable library indirectly via its dependencies or images.
• Any binary that was compiled with a vulnerable standard library (Go versions before the fixed releases) can contain the vulnerable code even if the host OS (e.g., Windows) itself is not shipping a separate Go runtime. Go programs are commonly statically linked and include the stdlib in the final executable.

Why Azure Linux is not the sole Microsoft product to check

• Microsoft maintains multiple open-source Go projects and also uses Go in public products and tooling. Two representative, public examples:
• Azure SDK for Go (azcore and related packages) are official Microsoft projects and import and use the Go standard library (net/http) for HTTP requests and pipelines. If the SDK or binaries built using it were built with a vulnerable Go stdlib, those builds could be affected.
• GitHub CLI / GitHub Go libraries (GitHub is a Microsoft company): these projects are written in Go and use net/http extensively; their binaries will include the stdlib. Many organizations and Microsoft teams consume or ship these kinds of Go-built tools.
• Beyond these explicit examples, Microsoft-run services, agents, container images, and internal tools sometimes include Go binaries or vendor Go packages. Any such product where the shipped binary was built with a vulnerable Go release is a candidate for impact.

Concrete evidence and verification sources (summary)

• Go project issue tracking and vulnerability records: the Go issue and associated CLs describe the exact bug, the mitigation (limit + GODEBUG option), and the patch path. The Go issue #75672 is the primary tracker for this CVE.
• Public vulnerability databases (OSV / pkg.go.dev / other aggregators) list the vulnerability, affected versions, and the patched releases (Go 1.24.8, Go 1.25.2). These databases are authoritative for the embargo/disclosure and remediation dates.
• Public examples of Microsoft-owned/maintained Go code that imports/uses net/http (Azure SDK for Go, GitHub/go code): these demonstrate Microsoft products/projects that do include the Go net/http standard library in practice and thus must be assessed for build-time dependency on vulnerable Go versions.

How to determine which Microsoft products in your environment are potentially affected
(you — as an org or as a customer — can run these checks)
1) Inventory services & binaries that are (or may be) written in Go

• Check vendor SDKs and command-line tools distributed by Microsoft that you run in your environment (Azure SDK for Go samples, GitHub CLI, Azure agent/tooling for Kubernetes and containers, etc.. If you or your services consume Microsoft binaires that are written in Go, treat them as candidate impacted items. Evidence: Azure SDK for Go uses net/http.

2) Scan server/agent/container images for Go-built binaries

• Look for ELF/PE/ Mach-O files that contain Go build info. On systems that have the Go tool installed you can run:
• go version -m /path/to/binary
• This prints the Go toolchain version and embedded module information for Go-built binaries (build info is present for binaries built with newer Go toolchains). That’s a precise way to discover if a binary was built by Go and which Go version was used.
• If you don’t have the Go tool, you can use strings + grep for the “go1.” text, or use debug/buildinfo readers to inspect ELF/PE sections. These are less precise but often effective.
• For container images: scan image layers for Go executables (common paths: /usr/local/bin, /usr/bin, /opt). Many Linux distributions also publish which packages include Go-built binaries; use image scanning tools to search for Go-build info.

3) If a service is built from source (internal or Microsoft-shared), determine which Go toolchain was used

• If you have CI logs (build agent logs) or container build recipes, check the Go version used during builds. If the build toolchain is one of the affected ranges (e.g., older than the patched versions cited earlier), rebuild with the patched Go release.

4) Check the product-specific advisories

• Microsoft’s MSRC page quoted in your prompt is the authoritative Microsoft statement for Microsoft products. MSRC said they published Azure Linux guidance and that they will update CVE entries if more Microsoft products are affected. That is the right place to watch for product-by-product advisories. (You already linked the MSRC CVE page. If you manage Microsoft products, combine MSRC advisories with the Go project’s advisories and your local inventory scan.

Recommended remediation and mitigations (practical)

• For Microsoft-maintained or third-party Go binaries you run:
• Upgrade/rebuild with patched Go releases:
• Rebuild any Go-built binary with Go 1.24.8 or 1.25.2 (or later) where the fix is applied. Replacing the binary with a build from the fixed toolchain fully removes the vulnerable net/http code path.
• If rebuilding is not immediately possible, consider operations mitigations:
• Use the newly-introduced httpcookiemaxnum GODEBUG knob as a temporary mitigation to limit the number of cookies parsed (the default implemented in the fix is 3000). Example: set environment variable GODEBUG=httpcookiemaxnum=3000 (or a lower value if you must tighten quickly) for the process. This mitigates memory exhaustion by capping cookie counts until you can rebuild. Note: this only works for processes that support GODEBUG and whose runtime reads it — typically Go binaries — and it is intended as a temporary operational control.
• For container images and VM images (including Azure Linux):
• Update base images and rebuild containers with a patched Go runtime or update the contained Go-based packages. Replace/redistribute updated images through your standard image pipeline.
• For SDKs used in your applications:
• If you depend on Microsoft SDKs written in Go (e.g., Azure SDK for Go), update those SDK packages and, where you produce a final binary, rebuild with a patched toolchain.

Action checklist tailored for Microsoft customers (practical steps)

• Short-term (0–7 days)
• Check MSRC advisories linked to CVE-2025-58186 for Microsoft product-specific updates (you already referenced that page).
• Inventory all Microsoft-supplied binaries you run (agents, CLI tools like gh/azure-related Go tools, container images from Microsoft) and mark those written in Go as priority.
• For critical binaries that you cannot rebuild immediately, set GODEBUG=httpcookiemaxnum to a conservative value and consider additional request-level protections (WAFs, rate-limiting in front of services).
• Medium-term (7–30 days)
• Rebuild and redeploy any in-house or vendor-provided Go binaries using the patched Go releases (1.24.8 / 1.25.2 or later).
• Update container images and machine images to versions that contain patched Go code or patched packages.
• Monitor vendor and Microsoft advisory pages for product-specific patches or updated VEX/CSAF/VEX metadata (Microsoft has committed to publishing CSAF/VEX and will update CVE entries when impacted products are identified).
• Longer-term
• Add automated scanning for Go build info into your CI/CD and image-pipeline processes (detect when a binary is built with an out-of-support or known-vulnerable Go version).
• For third‑party dependencies, require SBOMs that include build toolchain info (that will make detection easier next time).

What Microsoft has said (and what that means)

• Microsoft’s public MSRC advisory for CVE-2025-58186 (the page you quoted) highlights Azure Linux as one Microsoft product that includes the open-source library and that will be kept up to date; it also says Microsoft will update the CVE entry if additional product impact is identified. That is consistent with responsible disclosure practice: Microsoft is saying it will list additional affected Microsoft products if internal inventories find other Microsoft products bundling the vulnerable code. In short: MSRC’s statement is a product-level disclosure and not a technical claim that only one product ever includes the library. (You should continue to watch MSRC for product-specific updates. [user-supplied MSRC excerpt]
• At the same time, public evidence shows the Go stdlib vulnerability and the required patches apply to any Go binaries — including Microsoft-maintained Go projects (Azure SDK for Go, GitHub-related Go tools). So operational teams should assume “possibility of impact” if they run Microsoft-supplied Go binaries and should follow the remediation checklist above.

Limitations and caveats

• Many Microsoft services are multi-layered and rely on upstream open-source projects (Kubernetes, containerd, Prometheus, etc.. Some of those upstream components are maintained outside Microsoft but can be packaged or used by Microsoft services. When a CVE touches a widely used language runtime or a standard library, the possible surface of impact is broad. Real product impact requires: (a) the product actually ships or runs a binary built with the vulnerable standard library, or (b) a product ships an image or dependency that includes a vulnerable binary.
• Automated detection is not always perfect (e.g., buildinfo may be stripped in some builds). Use a combination of SBOMs, build logs, binary inspection, and vendor advisories.

Short, practical answer to the user’s exact question

• Is Azure Linux the only Microsoft product that includes the library and is therefore potentially affected? No — Azure Linux is one product Microsoft has already called out, but it is not the only Microsoft product that can include the Go standard library. Microsoft-maintained and Microsoft-owned Go projects (for example the Azure SDK for Go and GitHub Go tools) and any Microsoft product that ships Go-built binaries should be examined for exposure. You should treat all Microsoft-supplied Go binaries, agent images, container images, and SDK-based applications as candidates to be inventoried and assessed.

References and authoritative sources used in this article

• Go issue tracking & patch: golang/go issue for cookie parsing memory exhaustion (CVE-2025-58186). This is the primary code tracker and fix discussion.
• OSV / Go vuln database: GO-2025-4012 / CVE-2025-58186 vulnerability entry (describes affected versions and the fix).
• Public security advisories that summarize the fix and the GODEBUG knob and list the fixed releases (Go 1.24.8 and 1.25.2).
• Microsoft‑maintained Go code examples (Azure SDK for Go / azcore uses net/http). If you use Azure SDK for Go in your environment, that’s an example of a Microsoft project that pulls in Go’s net/http.
• GitHub CLI / GitHub Go libraries: public examples of Microsoft‑owned products/projects written in Go and using net/http, demonstrating that Microsoft‑owned projects can include net/http in shipped binaries.

If you’d like I can:

• Help run or script the binary discovery steps for a Linux/Windows fleet (examples that run go version -m, or a small script to search images for Go buildinfo).
• Pull together a prioritized list of Microsoft-supplied packages and images (based on your environment) for a remediation runbook.
• Monitor MSRC and Go project pages for any updates and prepare a short alert-template you can send to your ops/security teams.

Notes about dates and timeline

• Public disclosure: the Go vulnerability and associated CVE were publicly documented in late October 2025 (CVE posted Oct 29, 2025 in Go / OSV entries). The Go security releases that contain the fix were published in October 2025 as well (security releases / release notes show the patched versions). Please treat releases older than the fixed versions (pre‑1.24.8; 1.25.0 up to but not including 1.25.2) as vulnerable.

— End of analysis —

---

Source: MSRC Security Update Guide - Microsoft Security Response Center