Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” should be read as a product‑level attestation — not a definitive assertion that
no other Microsoft product includes the same EDK II Network Package; Microsoft has explicitly said it will expand its mapping if additional internal products are found to include the component.
Background
The vulnerability tracked as CVE‑2023‑45229 is an
out‑of‑bounds read in the
EDK II (EDK2) Network Package, occurring while the code parses certain DHCPv6 Advertise options (IA_NA or IA_TA). The flaw was publicized in January 2024 and has been analyzed and cataloged by mainstream vulnerability databases. EDK II is the open‑source reference implementation of UEFI firmware maintained by the Tianocore community; its Network Package is responsible for DHCP/DHCPv6 handling and PXE/network boot behavior. Because EDK II is widely reused by firmware vendors and some platform tooling, vulnerabilities in its network stack have cross‑ecosystem implications. Public trackers list the CVSSv3.1 base score at 6.5 (medium) for this issue.
What Microsoft actually said — precise reading
Microsoft’s MSRC guidance for this CVE (and similar third‑party CVEs) follows the company’s recently introduced CSAF/VEX attestation program: Microsoft is publishing machine‑readable attestations starting with the Azure Linux distribution, and for the CVE in question Microsoft has attested that Azure Linux “includes this open‑source library and is therefore potentially affected.” The company also committed to update the CVE entry if additional Microsoft products are later identified as carriers of the affected component. That wording is procedural: it documents the
inventory and validation status Microsoft has completed so far, rather than offering a global guarantee about every Microsoft product. In plain terms: Azure Linux is the only Microsoft product Microsoft has
publicly attested as shipping the component at disclosure time, but that does not technically prove other Microsoft SKUs do not include the same upstream library.
Technical confirmation: what the independent sources show
Multiple independent vulnerability sources converge on the same technical facts:
- The vulnerability exists in the EDK II Network Package and is triggered during processing of IA_NA/IA_TA options in DHCPv6 Advertise messages.
- Public CVE trackers and distribution advisories list the issue, assign it a medium severity, and reference the upstream Tianocore / EDK II advisory and patches.
These independent records (NVD, OSV, Amazon/Oracle advisories, distro trackers) provide cross‑validation of the core technical description and confirm the fix is available upstream and has been integrated into distributor packaging workflows. Relying on multiple trackers is important because CVE entries and vendor mappings can be updated or enriched after initial publication.
Is Azure Linux the only Microsoft product that includes EDK II’s Network Package?
Short answer:
No — not technically. Azure Linux is the only Microsoft product Microsoft has
publicly attested as including the EDK II Network Package for this CVE so far. That attestation reflects Microsoft’s current validated inventory for that product, and Microsoft has committed to expand the attestation if other Microsoft products are later found to include the component. Treat Microsoft’s statement as an authoritative,
product‑scoped declaration rather than a universal negative for all Microsoft offerings. Why that distinction matters:
- Build‑time choices matter. Whether a given Microsoft artifact includes an EDK II component depends on the build pipeline used to create that artifact. Different images, kernels, or firmware bundles may be assembled with different component sets and configurations. Presence is a per‑artifact property.
- Many Microsoft offerings are distinct artifacts. Microsoft ships many different images and runtime artifacts (Azure Linux images, linux‑azure kernel tracks, AKS node images, curated ML containers, Marketplace images, WSL kernels, etc.. Each artifact must be inventoried separately. The fact that Azure Linux is attested does not automatically include or exclude those other artifacts.
- Vendor attestations are phased. Publishing VEX/CSAF attestations is an inventory exercise that is typically performed product family by product family. Microsoft’s public VEX rollout started with Azure Linux as a practical, phased approach; expect the mapping scope to expand as inventories are completed.
Which Microsoft products might plausibly include EDK II (and therefore could be at risk)?
We cannot prove inclusion for every Microsoft SKU without Microsoft‑provided attestations or host/image inspection, but these product classes are plausible candidates where EDK II or its network package could appear:
- Azure Marketplace VM images and vendor images that embed firmware/boot toolsets derived from upstream EDK II code.
- Boot/firmware artifacts used by Azure‑hosted bare‑metal offerings or specialized cloud appliances (some cloud platforms keep custom firmware stacks). Public tracing of firmware components is required to confirm presence.
- Partner or OEM images redistributed through Microsoft channels (these are often built by third parties and may include firmware/tooling that uses EDK II). These remain the publisher’s responsibility to patch, but they often show up inside Azure customer estates.
Crucially,
absence of a Microsoft attestation for a given product does not prove absence of the vulnerable component. The only deterministic way to confirm is to inspect the specific image, kernel or firmware bundle in question.
How to verify whether a Microsoft product or image you run is affected
Operators should treat Microsoft’s attestation for Azure Linux as a reliable signal
for that product only and perform host‑ or image‑level verification for everything else. Practical verification steps:
- Inventory images and SKUs in use. Enumerate VM images, AKS node pools, Marketplace images, Azure ML curated images, and any custom or partner images.
- Inspect image contents or run-time instances:
- For firmware or UEFI builds, extract and inspect the firmware image to confirm presence of EDK II artifacts.
- For virtual machine images or containers, boot or unpack the image and look for EDK II packages/artifacts or binaries that link to EDK II components.
- For kernel‑level exposures (where the vulnerability would be surfaced via a network/UEFI component), check kernel modules, boot-time components, or service images that implement network boot or DHCPv6 parsing.
- Use vendor VEX/CSAF artifacts where available — Microsoft’s published CSAF/VEX files for Azure Linux are machine‑readable and can be consumed by automation to decide whether a given Azure Linux SKU is Known Affected, Not Affected, or Fixed.
Quick command‑style checks for Linux VM images (examples you can script into discovery pipelines):
- List image manifests and metadata for container images; run python/OCI tooling to inspect layers.
- If you can boot the image: search for edk2/EFI related packages, or inspect firmware blobs with binwalk and strings for Tianocore/EDK2 markers.
- For managed Azure Linux images, consult Microsoft’s VEX output and the Azure image release notes for explicit kernel/firmware package versions.
Operational implications and recommended actions
Microsoft’s attestation is useful and reduces ambiguity for Azure Linux customers, but it does not eliminate the need for operators to perform discovery and verification across their own estates.
Immediate priorities:
- Treat Azure Linux instances listed as Known Affected as high priority for patching or applying vendor‑supplied mitigations. Microsoft’s VEX/CSAF metadata and the distro security trackers should point to the vendor packages that contain upstream fixes.
- Inventory other Microsoft images (Marketplace, AKS node images, Azure ML curated images, WSL kernels where applicable) and perform the verification steps above. Do not assume those artifacts are covered by the Azure Linux attestation unless Microsoft explicitly adds them.
- For firmware or appliance fleets managed by third parties or OEMs, contact the vendor for confirmed firmware updates; many firmware updates are the only practical remediation path on appliances.
Longer‑term posture recommendations:
- Automate ingestion of VEX/CSAF feeds into your vulnerability management pipeline so that Bronze/Gold/Silver image families are mapped automatically to CVEs and remediation status. Microsoft has published CSAF/VEX attestations specifically to make this machine‑readable.
- Apply image signing and immutable image pipelines for curated environments (Azure ML, container registries). This reduces the blast radius of unpatched legacy images.
- Maintain a discovery and patch cadence for Marketplace and partner images; assume third‑party images may lag and require separate vendor coordination.
Risks, strengths, and where ambiguity remains
Strengths of Microsoft’s approach:
- Publishing CSAF/VEX attestations for Azure Linux provides a machine‑readable, authoritative starting point to answer “is this product affected?” for one major Microsoft product family. That materially reduces false positives for customers who run Azure Linux images.
- Upstream fixes for EDK II network issues are typically small and focused, which makes packaging and backporting feasible for vendors and quick to deploy once the vendor releases patched images. Independent trackers and distro advisories confirm upstream patches were merged.
Residual risks and caveats:
- Microsoft’s initial attestation scope is not exhaustive. Until Microsoft expands VEX/CSAF mapping to other product families, customers must verify other artifacts themselves. The attestation is a commitment to update, not an immediate proof that only Azure Linux carries the component.
- Third‑party Marketplace images, partner appliances and custom images create a long tail where vulnerable components can persist. These are often out of scope for a single vendor’s attestation and require targeted discovery and vendor coordination.
- Some CVE records and index pages may be updated with richer metadata after initial publication; rely on vendor package changelogs and the upstream commit references to confirm whether a particular build is patched. Cross‑check at least two independent sources (NVD, OSV, distro tracker, or vendor advisory) when making high‑impact remediation decisions.
Practical checklist for WindowsForum readers and admins
- Confirm which Azure Linux SKUs you run and ingest Microsoft’s CSAF/VEX attestation for those SKUs. Apply published patches for those images immediately.
- Enumerate all other Microsoft‑supplied images and artifacts in use (Marketplace images, Azure ML curated images, AKS node images, WSL kernels). For each, perform an image‑level or host‑level inspection to confirm the presence or absence of EDK II network components.
- For firmware or appliance fleets, obtain firmware SBOMs or vendor confirmation that their firmware is not using an affected EDK II network package; where it is, insist on a vendor firmware update schedule.
- Ingest multiple vulnerability feeds (vendor VEX/CSAF, NVD, OSV, distribution trackers) into your vulnerability management tooling and use them as complementary sources for final remediation mapping.
Conclusion
Microsoft’s public wording that
Azure Linux includes the open‑source library and is therefore potentially affected is precise and useful: it identifies the product that Microsoft has validated and for which it provides machine‑readable attestations today. However, this is a scoped inventory statement, not a categorical claim that no other Microsoft product includes the EDK II Network Package. Customers must use Microsoft’s VEX/CSAF attestation for Azure Linux as an authoritative input for that product and continue to perform image‑ and host‑level verification across the rest of their Microsoft‑supplied artifacts. Microsoft has committed to update the CVE mapping if more products are found to include the component; until that happens, responsible operators should assume potential exposure outside Azure Linux and verify accordingly.
Source: MSRC
Security Update Guide - Microsoft Security Response Center