Microsoft has confirmed that its Azure Linux distribution carries a recently patched flaw in the Go standard library that could let attackers slip malicious URLs past host-based security checks. The vulnerability, tracked as CVE-2025-47912, affects the net/url package and was fixed upstream in Go versions 1.24.8 and 1.25.2. While Azure Linux is the only Microsoft product currently attested as affected, the advisory warns that additional products may be added to the list as the company continues its inventory.
What Exactly Changed in Go’s URL Parser?
At the heart of the bug is a lax validation in Go’s net/url package. When processing URLs, functions like Parse, ParseRequestURI, and JoinPath accepted values inside square brackets that were not valid IPv6 addresses. According to RFC 3986, square brackets in the host component are reserved for IPv6 literals only—think http://[::1]/. Hostnames or IPv4 addresses like http://[evil.com]/ should never be bracketed.
The flaw lets an attacker supply a crafted URL where a bracketed hostname slips past validation. Any application that uses Go’s URL parsing for security decisions—such as origin checking, host whitelisting, or request routing—could be tricked into treating a malformed host as legitimate. The upstream advisory (GO-2025-4010) assesses the severity as medium, with a CVSS score of 5.3. It’s not a remote code execution risk on its own, but the parsing gap becomes dangerous when chained with application-level access controls.
Affected Go releases are those before 1.24.8, and the 1.25.0–1.25.1 range. The patched versions are 1.24.8 and 1.25.2. Any software built with a vulnerable Go toolchain or shipping a vulnerable Go runtime inherits the bug.
Microsoft’s VEX Attestation: Only Azure Linux for Now
Microsoft began publishing machine-readable security advisories in CSAF/VEX format in October 2025, starting with Azure Linux (previously known as CBL‑Mariner). The VEX documents for CVE-2025-47912 map vulnerable Go packages into specific Azure Linux product versions and component IDs. No other Microsoft product—not Windows, not Office, not any cloud service—has yet been attested as affected.
Microsoft’s advisory page states plainly: “If impact to additional products is identified, we will update the CVE to reflect this.” In other words, the current attestation is a snapshot of what Microsoft has validated so far. It does not guarantee that other Microsoft offerings are safe. Many internal services, SDKs, and container images embed Go runtimes, and Microsoft’s inventory work is ongoing. For now, Azure Linux is the only Microsoft product where the presence of the vulnerable component has been publicly confirmed.
Practical Impact: Who Needs to Worry?
Security teams should interpret the advisory not as a narrow Azure Linux issue, but as a signal to scan their entire environment for vulnerable Go runtimes. Here’s who is most exposed:
- Azure Linux users: If you run Azure Linux 3.0 or earlier, or any CBL‑Mariner 2.0 images, the vulnerable Go packages are present in the base distribution. Patching is a priority.
- Operators of Go‑built services: Any microservice, CLI tool, or containerized application compiled with an unpatched Go version is potentially vulnerable. This includes in‑house tools, third‑party images, and even some Microsoft‑supplied software that might bundle Go binaries.
- Developers maintaining Go applications: If your code calls
net/url.Parseor related functions, you need to recompile with a fixed toolchain. The vulnerability lives in the standard library, so a simple rebuild is the cure.
For home users and casual Windows users, the direct risk is minimal unless you’re self‑hosting Go‑based applications on your machines. The advisory is primarily aimed at cloud operators, DevOps teams, and application developers.
How We Got Here: The Road to the Fix
The Go project disclosed the flaw in its standard security release process. The root cause was a long‑standing parser quirk that didn’t enforce RFC 3986 strictly. Upstream, the fix was straightforward: tighten the validation so that only proper IPv6 addresses are permitted within brackets. The patches landed in the 1.24 and 1.25 maintenance streams.
Microsoft’s involvement comes from its adoption of Azure Linux as a first‑party distribution optimized for containers and cloud workloads. Because Azure Linux bundles open‑source components directly, flaws in those components automatically affect the distribution. Microsoft’s move to publish VEX statements is part of a broader industry shift toward machine‑readable vulnerability disclosures, making it easier for enterprises to automate triage and prioritize patching.
What to Do Now: An Action Plan
1. Inventory Your Azure Linux Footprint
Identify every Azure Linux VM, container node, and image in your environment. Use cloud inventory tools and container registries to build a list. Microsoft’s VEX files provide exact package names and versions to watch for.
2. Hunt for Vulnerable Go Runtimes Elsewhere
Even if you don’t use Azure Linux, check for Go in other places:
- Container images: Many base images ship a Go runtime. Scan layers for /usr/local/go or inspect the Go version with docker run --rm image cat /usr/local/go/VERSION.
- Linux packages: On RPM‑based systems, run rpm -qa | grep golang; on Debian/Ubuntu, use dpkg -l | grep golang.
- Statically linked binaries: Use strings /path/to/binary | grep -E 'go1\.[0-9]+' to find build information. Flag any version earlier than 1.24.8 or between 1.25.0 and 1.25.1 inclusive.
3. Remediate Based on What You Find
- Azure Linux: Apply vendor updates from Microsoft’s package repositories as soon as they become available. Monitor the MSRC advisory and your distribution’s update channel.
- Custom Go services: Upgrade your Go toolchain to 1.24.8 or 1.25.2 (or later). Rebuild and redeploy all affected binaries and images. Run integration tests to catch any regressions.
- Third‑party software: Check with the vendor for updated builds. If none are available, consider replacing the component or applying a temporary compensating control.
4. Apply a Short‑Term Mitigation (If Patching Is Delayed)
For applications that parse user‑supplied URLs, add a validation layer that explicitly rejects bracketed hostnames not matching IPv6 syntax. This is not a substitute for patching but can buy time. Example logic: if a host component starts with [ and ends with ], require the content to be a valid IPv6 address.
5. Monitor for Updates
Subscribe to the MSRC security update guide for CVE‑2025‑47912. Microsoft has committed to updating the CVE if additional products are found to be affected. Watch for new VEX documents that might extend the affected product list.
What’s Next: Expanding Transparency
Microsoft’s phased VEX rollout is expected to grow. The lessons from this advisory highlight the importance of software bill‑of‑materials (SBOM) and machine‑readable attestations. As more pieces of the software supply chain come under automated inventory, defenders will get faster answers about what needs patching.
For now, the message is clear: don’t assume that only Azure Linux is affected just because it’s the only one listed. Inventory your Go runtimes, patch what you can, and keep an eye on Microsoft’s evolving disclosure. The vulnerability is fixed upstream; it’s on all of us to roll the fix out to our systems.