CVE-2025-5994 Rebirthday: Azure Linux Attestation and Verifying Microsoft Artifacts

Microsoft’s short, product-focused line on CVE-2025-5994 — that “Azure Linux includes this open‑source library and is therefore potentially affected” — is factually correct for the Azure Linux deliveries Microsoft has inspected, but it is not a technical guarantee that no other Microsoft product can include the same vulnerable component. Microsoft has chosen a phased, machine‑readable VEX/CSAF rollout that starts with Azure Linux and will expand as their inventory completes, which means the attestation is authoritative for Azure Linux today but leaves other Microsoft artifacts in the “unverified until checked” category.

---

Background / Overview​

CVE‑2025‑5994 (the “Rebirthday Attack”) is a high‑impact cache‑poisoning vulnerability affecting caching DNS resolvers that implement EDNS Client Subnet (ECS). The issue was disclosed in mid‑July 2025 and affects Unbound builds compiled with ECS support (roughly Unbound 1.6.2 through 1.23.0, depending on compile‑time flags and runtime configuration). The vulnerability allows a remote attacker to leverage query segregation created by ECS to increase the chance that a spoofed non‑ECS reply will be accepted into cache because multiple distinct outgoing ECS query variants reduce the effective entropy of the transaction ID space in practice. The Unbound project and downstream distributions shipped a targeted fix in Unbound 1.23.1 and equivalent vendor packages; major distro advisories followed swiftly.
Why this matters: Unbound is widely used as a recursive, validating, caching resolver across many Linux distributions, embedded devices, appliances, and cloud images. Where Unbound is present, and where it was built with ECS enabled and configured to send ECS upstream, the Rebirthday Attack creates a realistic path to cache poisoning that can subvert DNS resolution integrity for victims of the poisoned cache. The fix is simple in principle (upgrade or apply the Unbound patch), but the operational burden is finding every copy of the vulnerable binary and every image that may embed it.

---

What Microsoft actually said — and how to read it​

Microsoft’s MSRC guidance for a number of recent open‑source CVEs has used the formulation you quoted: a concise product attestation (“Azure Linux includes this open‑source library and is therefore potentially affected”), paired with a public commitment to publish machine‑readable VEX/CSAF attestations beginning in October 2025 and update mappings if additional Microsoft products are identified. That combination is intended to give immediate, deterministic guidance to Azure Linux customers while Microsoft completes its broader artifact inventory. ([microsoft.com] carefully:

• Attestation ≠ Exclusivity. Saying Azure Linux includes the library is an authoritative inventory statement for that product family, but it does not assert that Azure Linux is the only Microsoft product that contains the component. Large vendors ship many artifacts and compiled images; a product attestation is the answer to “what did you check?” not “what didn’t you check?”
• VEX/CSAF is phased and evolving. Microsoft’s approach is to publish deterministic, machine‑readable attestations per product as those inventories are completed. Expect the mapping to change over time; absence of an attestation for Product X is absence of assurance, not proof that Product X is safe.

Put plainly: Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the affected Unbound code for CVE‑2025‑5994; that makes Azure Linux a confirmed remediation priority. It does not mean that other Microsoft‑distributed images, kernels, or appliances are automatically free of the vulnerable library — each artifact remains a verification task until Microsoft marks it Not Affected or Fixed.

---

The technical reality: presence in source ≠ exposure in practice​

To determine real exposure you must prove three things for each artifact:

• The vulnerable code was present in the upstream source when the artifact’s build snapshot was taken (i.e., the kernel or package version predates the upstream fix).
• The vulnerable component was built in or id compiled with ECS support, or a distribution package that ships libunbound/unbound).
• The runtime configuration enables the risky behavior (for Rebirthday: Unbound configured to send ECS client‑subnet data to upstream resolvers).

If any of the three conditions is false, the artifact is not practically vulnerable even if the upstream tree contains the file. That logic applies across Microsoft artifacts: presence in a repo or source tree is not sufficient to claim exposure without artifact‑level verification.

---

Which Muld plausibly carry this Unbound exposure?​

Microsoft has disclosed Azure Linux as a known carrier for many open‑source components; however Microsoft as an organization also builds and distributes many Linux‑based artifacould* (depending on build provenance) include Unbound or other vulnerable components. Examples worth checking:

• Azure Linux distribution images (the attested family). Microsoft has explicitly inspected these. ffected until patched.
• Azure Marketplace VM images and Microsoft‑published base images that are built from or include Azure Linux packages. Those images often reuse distribution packages and can tme package versions.
• Container base images published by Microsoft (including ones used for platform services). If a container was built from an image or package set that included Unboucan inherit the issue.
• Appliance images and virtual appliances published to Azure Marketplace that include Linux userland packages. These are frequently created from distro images and can include vulnerable components.
• Any internal Microsoft tooling that ships Linux images (for example, node or agent images used by AKS, images used by managed services). These are plausible carriers until attested.

Two commmany estates — but never assume — are: (a) Windows-native components (they don’t run Unbound natively), and (b) WSL2 images that are stock distro installations without Unbound installed. Both can still be carriers if Unbound was explicitly installed or if Microsoft’s WSL kernel/image builds include a packaged resolver in certain meta images. Therefore, always verify the artifact itself.

---

Practical checklist — how to verify and triage Microsoft artifacts in your estate​

Use this stepped approach to move from uncertainty to evidence for every Microsoft-supplied artifact y: find Microsoft-supplied Linux artifacts in your environment.

• Enumerate VMs that use Microsoft‑published images (Marketplace, Azure Linux images).
• List container base images pulled from Microsoft registries.
• Identify managed nodes (AKS node pools) that use Microsoft images.
• Catalog WSL installations and any centrally distributed WSL kernels.
• Verify package presence and versions per artifact.
• For running Linux systems: run package queries (e.g., apt list --installed | grep unbound; rpm -qa | grep unbound) and capture the exact package version. For Unboundrlier than the upstream fixed release and check compile flags where possible.
• For images or container layers: extract package metadata from image manifests or use container‑analysis tooling to inspect installed packages.
• For immutable images you cannot modify: mount the image and inspect the package database or the file system tree.
• Confirm compile options / configuration for Unbound.
• If you control builds: check whether Unbound was compiled with --enable-subnet (ECS) or whether the distro package provides ECS support.
• On running systems: check Unbound’s configuration files for the options send-client-subnet, client-subnbnet-always-forward. If any are enabled, the runtime is in the vulnerable configuration.
• Prioritize remediation.
• Immediate: patch Azure Linux images and any Microsoft attested artifacts per MSRC guidance. Azure Linux is the highest priority because Microsoft confirmed it as a carrier.
• High: replace or rebuild any Marketplace or container images that include unpatched Unbound packages.
• Moderate: where patching is not feasible immediately, mitigate by disabling ECS (do not send ECS upstream) or by constraining resolver exposure with access controls and query filtering.
• Monitor and validate.
• After updates, verify the package version (Unbound >= 1.23.1 or vendor‑patched package).
• Use runtime logs and telemetry to detect anomalous DNS responses or repeated unexpected NXDOMAIN/A records that could indicate cache tampering attempts.
• Subscribe to Microsoft’s CSAF/VEX feed and vendor advisories for updates to attestations and mappings.

A practical set of commands and checks (examples):

• On Debian/Ubuntu systems: dpkg -l | grep -E 'unbound|libunbound' and check unbound -h or the package changelog.
• On RPM systems: rpm -qa | grep -E 'unbound|libunbound' and inspect the installed file list for configuration.
• For containers: docker run --rm image:tag dpkg -l | grep unbound (or equivalent for rpm-based images).
• For images in Azure Marketplace: capture the image manifest and check the SBOM or installed package lists where available.

---

Mitigation and remediation options​

• Upgrade Unbound to the fixed release (Unbound 1.23.1 or the vendor backport). Upstream and distros published fixes; apply the vendor package updates provided by your distro or rebuild from patched source.
• Disable sending ECS to upstream resolvers where feasible. If you do not need ECS, do not compile or configure it; this removes the specific risk vector. Note: disabling ECS may have performance or CDN localization impacts in some deployments; weigh tradeoffs before wholesale disabling.
• When patching is temporarily impossible, apply network mitigations: restrict upstream resolver endpoints, isolate recursive resolvers from untrusted networks, and deploy DNSSEC validation to reduce the impact of cache poisoning (DNSSEC does not prevent Rebirthday directly but increases the difficulty for an attacker to substitute validated results).
• Rebuild and redeploy container images and appliance images that embed the vulnerable package. Reproducible builds and SBOMs make this manageable; absent SBOMs, you must inspect images layer‑by‑layer.

---

Strengths and limitations of Microsoft’s VEX/CSAF attestation approach​

Strengths:

• The VEX/CSAF model gives deterministic, machine‑readable answers for specific product families and reduces noisy triage for customers who run those products. Azure Linux being the first choice: it produces a single, authoritative remediation signal for a broad set of Azure images. ([microsoft.com](Toward greater transparency: Introducing Machine-readable Vulnerability Exploitability Xchange (VEX) for Azure Linux and beyond attestations reduces false positives for large enterprises that depend on automated vulnerability scanners — when a product is attested Not Affected or Fixed, scanning rules can act automatically.

Limitations and operational risks:

• Phased coverage creates a window where other artifacts remaiefore “unknown.” Customers must still perform artifact‑level discovery for Microsoft images that have not yet been attested. The presence/absence gap can breed complacency if teams equate lack of a VEX entry with absence of exposure.
• VEX/CSAF helps decisioning but does not remove the need for SBOMs, image scanning, and configuration checks at the tenant level. Large vendors will inevitably ship many artifacts, and any one of them can carry a vulnerable package depending on build provenance.

Operational recommendation: treat Microsoft’s attestation as authoritative for the named product (Azure Linux). Use it to prioritize patching. Simultaneously, mandate an artifact‑level inventory and SBOM/scan requirement across your cloud estate to find and fix other copies of the vulnerable library.

---

Risk assessment: what an attacker can realistically achieve (and what they cannot)​

• What’s realistic: A successful Rebirthday cache poisoning of a resolver that meets the three exposure conditions can alter DNS answers served to downstream clients of that resolver, enabling interception, redirection to malicious infrastructure, or targeted suppression of service discovery. Because the attack is network‑based, remote and unauthenticated actors can attempt it where resolvers are exposed to attacker‑controlled traffic.
• What’s harder: If DNSSEC is enforced between the resolver and clients (validation at the resolver), many forms of poisoning become ineffective because forged unsigned answers will fail crypto checks. However, DNSSEC adoption is uneven, and many client‑side stacks do not perform validation.
• Blast radius nuance: a poisoned central recursive resolver (for example, a resolver used by many VMs or containers) has a larger blast radius than a per‑host resolver. Thus, prioritize servers and images that serve many tenants or that are rebroadcast as a shared resolver inside your estate.

---

What to tell your executives and engineering teams (concise messaging)​

• For executives: Microsoft confirmed Azure Linux as including the vulnerable Unbound component; Azure Linux images are a confirmed remediation priority. Microsoft is expanding machine‑readable attestations, but absence of an attestation for other Microsoft artifacts is not proof of safety — it is an in‑progress inventory. Patch Azure Linux and schedule a focused inventory for all Microsoft‑ur estate.
• For engineering and ops: Execute the verification checklist immediately: find all Microsoft images, identify Unbound packages and configuration, upgrade to vendor‑patched packages (Unbound 1.23.1 or vendor backports), or disable ECS where it is not required. Rebuild container images as necessary and enforce image scanning and SBOM checks in CI/CD pipelines.

---

Unverifiable claims and remaining unknowns​

• Microsoft may find additional affected products as their VEX/CSAF program expands. Until Microsoft publishes attestaduct or you verify the artifact yourself, it is unknown whether that artifact is affected; treat “unknown” as a prompt to verify rather than a guarantee of safety. This distinction is important and often misunderstood in community discuspossible from public records alone to enumerate every Microsoft artifact that might be a carrier; only Microsoft’s internal inventory or artifact inspection of each image can provide definitive answers. The MSRC statement is transparent about this limitation and promises updates as inventory completes.

---

Final recommendations — prioritized, actionable items​

• Patch Azure Linux images right away: apply the updates Microsoft publishes for Azure Linux and reboot/replace images according to your maintenance windows. This is the top priority because Microsoft attested these images.
• Inventory Microsoft‑published artifacts in your environment: Marketplace images, container base images, AKS node images, WSL deployments, and any Microsoft-supplied appliances. Treat un‑attested artifacts as “unverified”; verify.
• Identify Unbound packages and configuration in each artifact and upgrade to Unbound 1.23.1 or vendor‑supplied fixed packages; if upgrade is not immediately possible, disable ECS or restrict resolver exposure as a temporary mitigation.
• Adopt SBOMs and image scanning as a minimum‑viable‑defense for future open‑source CVEs: SBOMs materially reduce the time to find copies of a vulnerable library across images. Microsoft’s VEX/CSAF speaks precisely to the need for machine‑readable provenance; couple vendor attestations with your own SBOM checks.
• Subscribe to MSRC’s CSAF/VEX feeds and relevant distro advisories (Ubuntu/CVE pages, NVD) so you get update notifications when Microsoft expands its attestations or vendors release new packages.

---

CVE‑2025‑5994 is a stark reminder that vendor attestations are powerful tools — and that they are, by necessity, scoped. Microsoft’s decision to start with Azure Linux and publish machine‑readable VEX attestations improves clarity and helps customers prioritize. But the operational reality of thousands of images and compiled artifacts means defenders must still do the work of artifact inventory, configuration checks, and patching. Treat Microsoft’s attestation as an authoritative starting point, not the finish line — patch Azure Linux now, then hunt and verify every Microsoft‑supplied image you run until the VEX map reports them Not Affected or Fixed.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center