CVE-2025-61723: Azure Linux Attestation and Go encoding pem Risk

Microsoft’s MSRC entry for CVE-2025-61723 names the Go standard library package encoding/pem as vulnerable to a quadratic‑time parsing condition but explicitly ties Microsoft’s public product-level attestation to Azure Linux — and that attestation is a statement of inventory for that product, not proof that no other Microsoft product could include the same vulnerable library. The practical upshot: Azure Linux is the only Microsoft product Microsoft has publicly attested as including the affected component so far, but it is not technically or operationally correct to assume it is the only Microsoft product that could ship or embed the vulnerable encoding/pem code; any Microsoft image, container, or binary that embeds Go builds in the affected ranges may be a carrier until verified and patched.

---

Background / Overview​

CVE-2025-61723 is a parsing performance issue in the Go standard library package encoding/pem: certain malformed or invalid PEM inputs cause the PEM parser to exhibit quadratic complexity, meaning CPU/time cost increases non-linearly with input size. The vulnerability affects programs that accept and parse untrusted PEM data and therefore presents a denial‑of‑service (availability) risk against services that parse remote or user-supplied PEM blobs. The Go project has documented the issue and released fixed Go patch releases that address the problem. Microsoft’s public advisory language for this CVE follows its recent transparency approach: Microsoft began publishing machine‑readable CSAF/VEX attestations for third‑party components in October 2025, and Azure Linux was the first product to receive such attestations. When Microsoft’s MSRC update guide says that Azure Linux “includes this open‑source library and is therefore potentially affected,” that phrasing is an attestation of inventory for Azure Linux — Microsoft has completed the component mapping for that product and published a VEX/CSAF record. The company also states it will update CVE/VEX records if further Microsoft products are identified as shipping the same vulnerable component.

---

What CVE-2025-61723 actually is​

The technical picture​

• The affected code path is in Go’s encoding/pem package, specifically the PEM parsing function(s).
• Certain invalid PEM inputs can trigger algorithmic behavior that takes O(N^2) time relative to input size, making the parser expensive to run on large or crafted inputs.
• The primary real‑world impact is CPU exhaustion or prolonged request handling — classic denial‑of‑service — not confidentiality or arbitrary code execution.
• The Go project assigned and published the vulnerability (GO‑2025‑4009 / CVE‑2025‑61723) and fixed it in specific patch releases.

Affected versions (authoritative mapping)​

Multiple vulnerability trackers and the Go project agree on the affected ranges: before go1.24.8 and from go1.25.0 before go1.25.2. Operators should treat binaries or builds that were compiled with Go versions in those ranges as potentially vulnerable until rebuilt with patched toolchains. Distribution trackers (Debian, SUSE, Ubuntu) and cloud vendor advisories list the same mappings and package backports.

---

What Microsoft actually said — and how to read it​

Microsoft’s wording for this and similar third‑party CVEs intentionally describes product mappings as they have been validated and published via CSAF/VEX. That means:

• When Microsoft states that Azure Linux includes a particular open‑source library and is therefore potentially affected, it is reporting the result of a completed inventory and a published product-level attestation for that Azure Linux family. This is a reliable, machine‑readable signal for customers who run Azure Linux images.
• Microsoft’s commitment to “update the CVE if additional Microsoft products are identified” is procedural: the company will expand the product-level attestations as its internal inventories and build‑time provenance checks identify additional Microsoft artifacts that include the vulnerable component. It is not a categorical claim that other Microsoft products are unaffected.
• In short: Azure Linux is the only Microsoft product Microsoft has publicly mapped and attested for this vulnerability at time of disclosure, but absence of attestations for other Microsoft products does not prove absence of the vulnerable code.

---

Why Azure Linux being named does not mean “only Azure Linux”​

There are multiple, concrete technical reasons Microsoft’s attestation for Azure Linux does not equate to global exclusivity across Microsoft offerings:

• Build-time variability: Whether a product contains a specific package or library depends on that product’s build configuration. A single open‑source component can appear in some kernel builds, some image families, or in statically compiled application binaries — and not in others. Identifying presence requires per-artifact inventory.
• Statically compiled Go binaries: Go programs are commonly compiled statically and embedded directly into images or appliances. Updating the system golang package is not sufficient to purge a vulnerable static binary that was built with an affected Go release — those binaries must be rebuilt with a patched toolchain and redeployed.
• Multiple Microsoft distribution surfaces: Microsoft ships many image families and runtime artifacts — Azure Linux images, marketplace VM images, curated container images (for Azure Machine Learning), AKS node images, WSL kernels, and more. Each is an independent inventory target. Microsoft’s attestation only covers those SKUs it explicitly mapped at disclosure time.
• Third‑party and long‑tail images: Marketplace or partner images hosted in Azure, or third‑party container images pulled into customer registries, may include older, unpatched Go toolchains or prebuilt binaries. These are not automatically covered by Microsoft’s Azure Linux attestation.

All of the above means the correct operational posture is to treat Microsoft’s Azure Linux attestation as a valuable automation signal for Azure Linux images, but to verify other Microsoft images and services you run before concluding they are unaffected.

---

Where the vulnerable library may appear inside Microsoft’s ecosystem​

The following product surfaces are plausible carriers of an affected encoding/pem implementation, and therefore deserve verification if you run them:

• Azure Linux images and kernel/toolchain packages — Microsoft has attested Azure Linux as “potentially affected” where it found the component. This is authoritative for customers running those images.
• Microsoft-published container/runtime images (for example, curated Azure Machine Learning environments and the Azure Container for PyTorch) that bundle language runtimes or prebuilt framework binaries; these images can contain Go-built tooling or packages. Curated images are updated on their own cadence and must be checked separately.
• Managed or partner runtimes hosted on Azure (Databricks runtime images, Marketplace images): these can include pre-installed language runtimes or static binaries compiled with earlier Go versions; their security depends on the upstream builder’s update cadence.
• WSL2 kernel and any Microsoft-supplied Linux kernels: kernel-level distribution choices are a build-time decision; a default WSL kernel may or may not include specific packages. Verify per-instance configuration.
• Windows-hosted appliances, agents, or services that embed static Go binaries (e.g., monitoring agents, cloud agents, or vendor appliances) — Go binaries are cross-platform and may appear on Windows, too.

Where Microsoft has published VEX/CSAF attestations, those attestations should be consumed as deterministic, machine‑readable inputs for vulnerability automation. Where attestations are absent, customers must perform host, image and artifact-level checks.

---

How to verify whether a Microsoft product or image you run is affected​

The only reliable way to determine exposure is to inspect the actual artifact (image, VM, binary) you run. Below is a prioritized, practical verification checklist.

Quick inventory and discovery (high priority)​

• Enumerate images and runtime surfaces you use:
• Azure VM images, Marketplace images, AKS node images, VM snapshots.
• Container registries: Azure Container Registry (ACR), Docker Hub images you run in AKS or pipelines.
• Azure ML curated environments, ACM (Azure Container for PyTorch) images, and Databricks runtime versions.
• WSL instances and custom WSL kernels.
• Identify deployed binaries and packages that are Go-built:
• On Linux images: check installed packages (apt/rpm/zypper/apk) for golang or go runtime packages.
• For container images: inspect Dockerfile/manifest or run the image and query package manager lists.
• For static binaries: locate application binaries and examine them for Go build metadata. (See commands below.

Useful commands and checks​

• Check installed Go package on Debian/Ubuntu:
• apt list --installed | grep golang
• Check installed Go package on RHEL/SUSE:
• rpm -qa | grep golang
• Inspect a running container image:
• docker run --rm -it image /bin/sh -c "apt list --installed 2>/dev/null | grep golang || rpm -qa | grep golang || apk info | grep go"
• Check a binary for Go build strings (useful for static Go binaries):
• strings /path/to/binary | grep -Eo "go1.[0-9]+.[0-9]+"
• readelf -p .note.go.buildid /path/to/binary (where readelf is available)
• Note: these techniques are heuristics — not all binaries expose version strings. If the binary is stripped, or if the build environment removed metadata, vendor attestations may be necessary.
• For Azure ML curated images:
• Inspect the curated environment metadata in Azure ML Studio (image/Dockerfile layers often list included language runtimes).
• For WSL kernels:
• zcat /proc/config.gz | grep -i CONFIG_<RELEVANT_FLAG> (kernel config checks for module inclusion when relevant)

These checks help determine whether the image or binary was built with an affected Go toolchain or if the system golang package is at a vulnerable version.

When you find Go in the affected ranges​

• If the system package is vulnerable: update the distro package to the fixed release provided by your distro or vendor (for example go1.24.8 or go1.25.2 where appropriate), then rebuild any dependent artifacts as needed.
• If a statically-built Go binary is present and was compiled with an affected toolchain: you must rebuild the binary with a patched Go release and redeploy the rebuilt artifact. Patching the host package alone will not fix embedded static binaries.

---

Remediation and mitigation roadmap​

Immediate actions (0–48 hours)​

• Prioritize assets that parse untrusted PEM inputs (public‑facing APIs, upload endpoints, CI/CD runners, image ingest pipelines). These are highest‑risk carriers of a remote DoS.
• Consume Microsoft’s CSAF/VEX feed for Azure Linux and any product-level attestations Microsoft publishes; treat a Microsoft “Known Affected” or “Under Investigation” status as immediate triage input for that SKU.
• Inventory Go-built artifacts across your estate and prioritize redeploy/rebuild for network-facing services.
• Put resource limits in front of parsing operations if possible (process CPU/memory quotas, request size limits) as a temporary compensating control.

Patching and rebuild (1–4 weeks)​

• Patch the Go toolchain to a fixed release:
• Upgrade to Go 1.24.8 or later in the 1.24.x line, or Go 1.25.2 or later in the 1.25.x line, as recommended by the Go project and distribution advisories.
• Rebuild all static Go binaries with the patched toolchain and redeploy images and appliances.
• Replace or rebuild container images with updated base images and republish to your registries.
• Validate post‑deploy: run parsing tests against representative PEM inputs (including crafted invalid inputs) to ensure that CPU usage and latency are within acceptable bounds.

Interim mitigations if immediate rebuild is infeasible​

• Rate-limit and authentication-gate endpoints that accept PEM inputs.
• Use proxy or TLS-terminator components that perform parsing with a patched stack before handing PEMs to legacy Go consumers.
• If you control the application code, add protective parsing sanity checks (maximum acceptable size, reject obviously malformed headers early) but treat that only as temporary because the root cause still exists in the runtime parsing code.

---

Risk assessment and practical advice for WindowsForum readers​

• Treat Microsoft’s Azure Linux VEX/CSAF attestation as a definitive, authoritative signal for Azure Linux images — act on it quickly if you run those images.
• For other Microsoft products or images in your estate, do not assume safety simply because Microsoft has not yet published a VEX attestation for them. Instead, perform the artifact-level checks described above (image manifests, binary version strings, package versions). Vendor attestations are an automation convenience, but they are only as comprehensive as the inventories that produced them.
• If you use third‑party marketplace images, partner images, or community containers within Azure, treat those images as separate entities: they are not automatically covered by Microsoft’s Azure Linux attestation and must be inventoried independently.
• For high‑assurance environments, require signed, pinned images and enforce a rebuild policy for vendor-supplied artifacts so you control the update cadence.

---

Where public records and vendor attestations agree — and where they don’t​

Cross‑checks between the Go project, the NVD, distribution security trackers (Debian, Ubuntu, SUSE), cloud vendor advisories (Amazon Linux ALAS), and Microsoft’s VEX/CSAF attestations form a consistent technical picture: the encoding/pem parser had a quadratic complexity issue, Go maintainers released fixes in the indicated patch releases, and multiple distros and vendors have begun packaging updates. Use those independent feeds to corroborate your remediation plan. Caveat: public attestations from Microsoft are product‑scope statements at a point in time. They are authoritative for the products named; they are not evidence that other Microsoft products are free of the vulnerable component unless Microsoft explicitly attests that status. Treat any absence of mention as “not yet attested” rather than “not affected.”

---

Conclusion — practical verdict on the user’s question​

• Short answer: No — Azure Linux is not necessarily the only Microsoft product that can include the vulnerable encoding/pem code. It is, however, the only Microsoft product Microsoft has publicly attested as including the affected library for CVE‑2025‑61723 at the time of Microsoft’s disclosure.
• Operational guidance: treat Microsoft’s Azure Linux VEX/CSAF attestation as an authoritative, machine‑readable signal for Azure Linux images and act on it immediately if you run those SKUs. For any other Microsoft products, images, or services in your environment, perform artifact‑level verification: check package versions, inspect container/image manifests, and search static binaries for Go build metadata. Rebuild and redeploy static Go binaries with patched toolchains to fully remediate.
• Final caution: vendor attestations materially speed triage, but they are a phased disclosure approach. Until Microsoft expands VEX/CSAF attestations to additional SKUs, treat any un‑attested Microsoft artifact as requiring verification rather than as inherently safe.

---

Appendix: Key references for action (authoritative technical facts)

• Fixed Go releases and the Go vulnerability record (GO‑2025‑4009 / CVE‑2025‑61723) documenting affected ranges and the fix commits.
• NVD entry and enrichment metadata for CVE‑2025‑61723.
• Distribution and vendor trackers (Debian / Ubuntu / SUSE / Amazon Linux) for package mappings and fixed package versions.
• Microsoft’s MSRC blog on publishing CSAF/VEX for Azure Linux (background on the attestation program and its phased rollout).
• WindowsForum operational guidance and analysis of Microsoft attestations and their meaning for customers.

(Where any specific product-level attestation or mapping is needed for automation, consult the publisher’s machine‑readable CSAF/VEX artifacts or vendor security advisory and validate artifact IDs against the images and binaries you actually run.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center