The Go standard library vulnerability tracked as CVE-2025-47912 — a flaw in net/url that allows values other than IPv6 addresses to appear inside square-bracketed host components — has been publicly disclosed and patched upstream, and Microsoft’s initial machine-readable attestations currently identify the Azure Linux distribution (and its CBL‑Mariner lineage) as the Microsoft product family that includes the vulnerable component. That MSRC attestation does not technically prove other Microsoft products are safe; it documents what Microsoft has validated so far and commits to updating the CVE/VEX records if additional Microsoft products are found to ship the affected Go component.
Background / Overview
The root defect is in the Go standard library’s net/url package: the Parse-related functions permitted non‑IPv6 values — including hostnames or IPv4 forms — to be accepted when they appeared inside square brackets in the host component of a URL. Per RFC 3986, square brackets are reserved for IPv6 literals only (for example,
http://[::1/); hostnames and IPv4 addresses must not be bracketed. The bug therefore creates a mismatch between the library’s validation and the RFC expectation. The vulnerability affects the following net/url symbols in affected Go releases: JoinPath, Parse, ParseRequestURI, URL.Parse, and URL.UnmarshalBinary. Upstream fixes were rolled into the Go project and are present in patched releases; the vulnerability is listed as GO‑2025‑4010 and is associated with CVE‑2025‑47912. The public CVSS and impact assessments place this as a medium‑severity parsing/validation bug (commonly seen in URL parsing components). CVSS values reported by trackers are in the mid range (around 5.3), reflecting that the issue can be triggered remotely but generally has constrained confidentiality/integrity/availability impact unless combined with higher‑level application logic or authorization bypasses.
What Microsoft has published so far
Microsoft’s attestation model (CSAF / VEX) and the Azure Linux focus
Microsoft has adopted a phased, machine‑readable disclosure model: it publishes CSAF advisory documents for CVEs it assigns and VEX attestations to state whether specific Microsoft products are known affected, not affected, fixed, or under investigation. Microsoft’s MSRC blog explains that the rollout started with Azure Linux (the distribution previously known as CBL‑Mariner), and that Microsoft will expand VEX/CSAF coverage to additional products over time. That transparency model is important: it tells customers
what Microsoft has validated at the time of disclosure, not necessarily everything Microsoft might later discover. Microsoft’s CVE product mapping and VEX/CSAF output for CVE‑2025‑47912 explicitly list Azure Linux (and CBL‑Mariner components) as the products that include the vulnerable golang packages in Microsoft’s inventory at the time the attestations were published. The machine‑readable product tree in Microsoft’s VEX files maps the vulnerable golang components into Azure Linux product versions and related component artifacts. Microsoft’s public statement also reiterates the commitment to update the CVE/VEX records if additional product impact is discovered.
What that wording means in practice
When Microsoft says “Azure Linux includes this open‑source library and is therefore potentially affected,” read that as:
- Microsoft has completed the inventory and mapping step for the Azure Linux product family and determined that specific Azure Linux builds ship the vulnerable golang components; and
- Microsoft has not yet published validated attestations mapping those vulnerable components to other Microsoft internal SKUs — not because it’s impossible that other SKUs include them, but because those SKUs haven’t yet been fully inventoried, validated, or attested in the VEX/CSAF output at publication time.
This follows Microsoft’s stated VEX rollout approach: start with a single, well‑scoped product (Azure Linux), publish attested statuses for that product, then expand the same process to more products as the mapping work completes.
Is Azure Linux the only Microsoft product that includes the library and therefore potentially affected?
Short answer: No — Azure Linux is not the only Microsoft product that could technically include the vulnerable net/url code — but it
is the only Microsoft product Microsoft has publicly attested as including the vulnerable component at the time of the advisory.
Longer explanation and evidence:
- Microsoft’s VEX/CSAF mappings and the MSRC advisory for CVE‑2025‑47912 list Azure Linux / CBL‑Mariner package artifacts as the Microsoft product components that ship the affected golang packages. The machine‑readable metadata shows golang package entries tied to Azure Linux component IDs. That is the authoritative Microsoft‑side mapping at disclosure.
- The Go project and vulnerability trackers (pkg.go.dev, OSV, GitHub issue tracker) identify the vulnerability as part of the Go standard library and indicate the fixed versions of Go: before go1.24.8 and from go1.25.0 before go1.25.2 are vulnerable; patches were landed in the 1.24.x and 1.25.x maintenance streams. Any product that bundles or distributes an unpatched Go runtime or a binary built with a vulnerable Go toolchain can inherit the net/url flaw. That broad technical footprint means many Microsoft offerings that embed Go‑compiled components could be affected in principle — but Microsoft’s published VEX currently maps only Azure Linux.
- Microsoft also publishes and maintains Go‑language client libraries (the Azure SDK for Go) and other Go code on GitHub. Those repositories are source code that depends on the Go standard library at runtime when compiled; the mere existence of Go source in Microsoft repos is not the same as shipping a vulnerable runtime — the vulnerability appears in the compiled standard library or packaged golang runtime, not in unrelated Go source files. That said, Microsoft’s published software supply‑chain artifacts (SDK binary distributions, cloud agents, container images, tooling) must be inventoried to determine whether they incorporate a vulnerable Go runtime or were built with a vulnerable toolchain.
Put plainly: Microsoft’s public attestation identifies Azure Linux as a known shipping product that includes the vulnerable golang packages; Microsoft has explicitly said it will update the CVE/VEX records if additional products are found to include the component. Therefore Azure Linux is
the only Microsoft product publicly attested so far, but other Microsoft products could conceivably be affected if they ship unpatched Go runtimes or include binaries built with vulnerable toolchains.
Technical exposure: how this vulnerability matters to customers and operators
The net/url issue is a parsing/validation bug. On its own it does not instantly equal remote code execution; instead, the typical risk patterns are:
- Malformed or intentionally crafted URLs processed by an application that relies on net/url may be incorrectly parsed, leading to misrouting, improper host comparison, or bypasses of host or origin checks.
- If application logic uses bracketed host parsing to implement security decisions (for example, canonical host matching, origin checks, or access‑control decisions), the bug could be used to craft input that subverts that logic and creates authorization or request routing flaws.
- Any network‑exposed service that accepts user‑supplied URLs for validation, redirect resolution, or proxying should be considered in scope for further review if it is built with a vulnerable Go standard library.
Real‑world exploitability depends heavily on how an application uses the URL parsing APIs. The NET effect is medium‑severity at the library level, but the real impact can escalate if the vulnerable parsing is chained into higher‑level authorization or routing logic.
What to check right now (practical steps)
Security and ops teams should take a measured, supply‑chain focused approach: inventory, identify, remediate.
1. Inventory Microsoft‑supplied images and packages you run
- Check if you run Azure Linux (Azure Linux 3.0 / azl3) or CBL‑Mariner 2.0 images anywhere in your environment; those are explicitly attested as including the vulnerable golang components. Use your cloud image inventory, container registries, and orchestration manifests to list images. Microsoft’s VEX/CSAF files show the exact component names used in the Azure Linux product tree and can be consumed programmatically.
2. Detect binaries built with vulnerable Go versions
- Identify Go runtimes and statically linked Go binaries in your fleet. Common places to look:
- Container images (scan layers for /usr/local/go or typical golang package files).
- Linux packages (check package manager metadata for packaged golang versions).
- Standalone binaries — many Go programs are statically linked and include version metadata or build info.
- Commands and techniques (examples):
- On a Linux host, list installed golang RPM/DEB packages:
- rpm -qa | grep -i golang
- dpkg -l | grep -i golang
- Inspect container images:
- docker run --rm image:tag cat /usr/local/go/VERSION || true
- docker run --rm image:tag strings /path/to/binary | grep -i 'go1.' || true
- For statically linked Go binaries, use strings and look for build information:
- strings /usr/bin/mybinary | grep -E 'go1.[0-9]+' || true
- If you find go toolchain versions before go1.24.8 or between go1.25.0 and go1.25.1 inclusive, treat them as vulnerable and prioritize remediation. The upstream vulnerability metadata and pkg.go.dev explicitly list the affected release ranges.
3. Prioritize and remediate
- If the vulnerable component appears in an OS distribution package (for example, the golang package in Azure Linux images), apply vendor updates as they appear for that distribution. Microsoft’s VEX indicates where Microsoft is tracking and when fixes are planned or available. For Azure Linux customers, follow Microsoft’s Azure Linux advisories and patch channels.
- If you run Go‑compiled services or third‑party applications built with a vulnerable toolchain, rebuild those services with a fixed Go version and redeploy:
- Upgrade local toolchains to go1.24.8 (or later) or go1.25.2 (or later) depending on your branch.
- Rebuild and repackage images/containers/binaries.
- Validate with functional and security tests before rolling out.
- For managed cloud services where Microsoft controls the runtime, monitor MSRC VEX outputs and the product update guidance; Microsoft has committed to updating the CVE records if additional products are affected.
Detection and mitigation recommendations for developers and maintainers
- Avoid trusting client‑supplied URL parsing results for security decisions. Wherever possible, canonicalize and validate hostnames with explicit logic that enforces RFC 3986 semantics rather than relying on unchecked library behavior.
- Apply defense‑in‑depth:
- Validate incoming URLs against a whitelist of expected hostnames or IP spaces before parsing.
- Use high‑level application logic to enforce explicit origin or host checks (for example, exact string match against an allowed set).
- If you maintain Go code that calls net/url.Parse or related functions, upgrade your Go toolchain and recompile. Upstream fixed releases address the root cause; rebuilding is the safest remediation.
- If rebuilding is not immediately possible, add application‑level validators that detect bracketed hostnames that are not valid IPv6 addresses and reject them. This is a temporary compensating control, not a substitute for applying the patch.
Verifiable technical facts and recommended versions
- Upstream Go vulnerability metadata (pkg.go.dev / GO‑2025‑4010) lists the affected ranges: before go1.24.8 and from go1.25.0 before go1.25.2. The patched releases are go1.24.8 and go1.25.2 (and later). Rebuilding with those versions or newer removes the vulnerable net/url behavior.
- Distribution trackers (Debian, Ubuntu, AWS AMI advisories, etc. list packaged golang versions and fixed package versions; use your distro’s security tracker to map package versions to fixed releases in your deployment. Debian and other Linux distribution trackers have entries showing which packaged Go versions were vulnerable and where fixes were landed.
Why the vendor attestation matters — and what it does not mean
Microsoft’s VEX/CSAF output is valuable for automation and prioritization: it gives deterministic, machine‑readable answers about whether a specific Microsoft product (as defined in Microsoft’s product tree) includes a given upstream component and whether that product is known affected. That reduces noisy investigation work for customers who run exactly those Microsoft products.
However, an attestation that “Azure Linux includes the component and is therefore potentially affected” is not a universal guarantee that
no other Microsoft product includes the same upstream code. Vendors commonly publish verified attestations for a subset of their product portfolio first (a “crawl/walk/run” approach) and expand coverage as inventory work completes. Microsoft explicitly states it will update the CVE/VEX mappings if additional Microsoft SKUs are identified as shipping the component. Customers should treat the attestation as an authoritative answer for the
products the vendor has validated, and should perform their own inventory for other Microsoft artifacts they consume.
Practical checklist (runbook) for security teams
- Inventory:
- List all Azure Linux / CBL‑Mariner instances and container images in production.
- List all containers and binaries that embed a Go runtime or were built with Go.
- Detect:
- Scan images and hosts for packaging metadata and binary buildinfo for Go versions.
- Flag any go toolchain or binary built with go < 1.24.8 or (1.25.0 ≤ version < 1.25.2).
- Remediate:
- Apply vendor patches for Azure Linux / CBL‑Mariner when available.
- Rebuild and redeploy in‑house Go services with Go 1.24.8+ or 1.25.2+.
- Replace or update third‑party images/binaries that ship vulnerable Go runtimes.
- Mitigate (short term):
- Add input validation to detect and reject bracketed hostnames that are not valid IPv6 literals.
- Monitor application logs for suspicious parse failures or unexpected host values.
- Monitor:
- Subscribe to MSRC advisories and VEX/CSAF feeds for updates to the CVE product mappings.
- Follow upstream Go security announcements for any follow‑on patches or advisories.
Risks and caveats
- Unverifiable claim risk: It is not possible for external observers to prove the absence of the vulnerable component in every Microsoft product; Microsoft’s public attestation documents only the components it has verified and mapped. Until Microsoft expands VEX coverage across more SKUs, customers must assume that Microsoft‑supplied artifacts they run could contain the vulnerable code unless the VEX/CSAF attestation explicitly marks them as not affected or fixed. Microsoft has stated it will update the CVE if additional affected products are found.
- Real‑world impact variability: The vulnerability is a library‑level parsing bug. Many real‑world exploit scenarios depend on higher‑level application logic. Assessments should therefore focus on which services accept and interpret user‑supplied URLs or perform host/origin checks using net/url APIs.
- Patching vs. rebuilding: For application code that includes a static Go runtime, simply upgrading the OS package might not be sufficient — a rebuild with a patched toolchain is required. This is a common supply‑chain nuance for compiled languages.
Bottom line
- Microsoft’s MSRC VEX/CSAF output currently maps CVE‑2025‑47912 to Azure Linux (and CBL‑Mariner components) as the Microsoft product family that includes the vulnerable golang packages; Microsoft has committed to updating the CVE/VEX records if more Microsoft products are found to include the component. That attestation is authoritative for Microsoft products that have been validated, but it is not a mathematical proof that no other Microsoft SKU includes the vulnerable library.
- Technically, any Microsoft product that ships a vulnerable Go runtime or a binary built with a vulnerable Go toolchain is potentially affected. Security teams should therefore inventory their environments, detect Go versions in use, rebuild or apply vendor patches where necessary, and monitor MSRC VEX updates. Upstream Go patches are available in go1.24.8 and go1.25.2 (and later), and rebuilding with those releases removes the vulnerable net/url behavior.
CVE‑2025‑47912 is a reminder that modern software security depends on good software bill‑of‑materials, machine‑readable attestations, and practical operational follow‑through: vendor‑published VEX/CSAF data accelerates triage, but every organization must still inventory, detect, and remediate the actual artifacts they run.
Source: MSRC
Security Update Guide - Microsoft Security Response Center