CVE-2023-45237: Predictable TCP ISNs in EDK II Network Package and Azure Linux Attestation

CVE-2023-45237 exposes a weakness in the EDK II Network Package’s random number handling that can produce predictable TCP sequence numbers — a problem that matters for any product shipping the affected edk2 code, and one Microsoft’s brief MSRC advisory has deliberately scoped to Azure Linux while promising to expand its attestations if other Microsoft artifacts are discovered to include the same upstream component. ([blog.quarkslab.comlab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html)

Background / Overview​

EDK II (edk2, the TianoCore open‑source UEFI project) provides firmware components used widely in virtualization and platform firmware, including OVMF/UEFI images for QEMU/KVM and other virtualization stacks. CVE‑2023‑45237 was disclosed in January 2024 as part of a broader set of network‑stack issues in EDK II: the Network Package’s PRNG and seed initialization can be predictable, allowing attackers to infer TCP Initial Sequence Numbers (ISNs) with less effort than intended. Upstreams and major Linux distributors have treated this as a real defect and released fixes.
Microsoft’s public messaging on its Security Update Guide for related Linux CVEs uses a short, carefully worded FAQ line: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” That statement is accurate for the product inventory Microsoft has completed and published so far, and Microsoft has stated it will update CVE/VEX attestations if additional product families are found to carry the component. Archived MSRC pages show this same FAQ text repeated across multiple Linux CVE entries.
This article explains what CVE‑2023‑45237 actually is, why Microsoft’s phrasing matters (and how to interpret it), how other vendors have responded, and what operators should do now to establish exposure and mitigate risk.

---

What CVE‑2023‑45237 is (technically)​

The flaw in plain language​

At the core of CVE‑2023‑45237 is a weak PRNG macro and a weak seed source used by the EDK II Network Package. The PRNG macro is a simple linear congruential generator (LCG) pattern — the classic “multiply by 1103515245, add 12345” formulation — and the seed is derived from coarse platform time fields plus a monotonic counter. That combination makes generated TCP sequence numbers predictable under realistic conditions, enabling an attacker to more easily guess or infer ISNs used by the stack.
Predictable ISNs are not an abstract nicety: TCP sequence numbers are a core defense against blind or off‑path TCP injection and session hijacking. If an attacker can reliably predict the ISN an endpoint will use for a freshly established connection, they can spoof segments or perform injection attacks that would otherwise be much harder. The technical write‑ups and the edk2 patch notes make this clear: the PRNG and seed mechanism were insufficiently unpredictable for security‑sensitive usage.

How distributions and vendors classified the severity​

Different sources assigned different severity metrics — some vendors and distribution advisories present the issue as Medium while others (or NVD enrichments) show higher base score vectors depending on confidentiality impact assumptions. Major Linux distributors (Red Hat, Oracle, Ubuntu, Amazon Linux) published advisories and fixed packages for edk2, demonstrating that the issue reached widely used packaged artifacts. Those vendor advisories also list the specific edk2 files and components patched in response.

---

Why Microsoft singled out Azure Linux — and what that actually means​

Product‑scoped attestation, not exclusivity​

Microsoft’s MSRC phrasing — that “Azure Linux includes this open‑source library and is therefore potentially affected” — is a product‑level attestation. In plain terms:

• It is authoritative for Azure Linux. Microsoft has completed an inventory for the Azure Linux artifacts it ships and confirmed the presence of the implicated edk2/network code there. Customers running Azure Linux images should treat the attestation as a canonical signal to act on.
• It is not a categorical statement that no other Microsoft product includes the same code. Microsoft’s advisory language and rollout of machine‑readable CSAF/VEX attestations (a rollout the company began in October 2025) are phased and product‑by‑product. The absence of an attestation for a given Microsoft product does not prove the code is absent from that product. Microsoft has committed to updating CVE/VEX records if further internal mapping finds the same upstream component in other product families.

This distinction — attested affected vs. potentially affected — is the central operational point every customer and security team must understand. Several independent vendor and community write‑ups (and public advisories) echo the same interpretation: Azure Linux is a confirmed hit because Microsoft checked that product; other Microsoft images and kernels remain unverified until inventoried.

Why Microsoft takes this approach​

A Microsoft cloud or software product is typically composed of many independently built artifacts, each with its own source sets, build recipes, and configuration flags. Whether an upstream source file or library is present in a particular product artifact depends on the precise commit ranges, the build configuration, and which binaries are included in the release. For Linux‑kernel or firmware‑type components, that means the same upstream project (edk2 in this case) can appear in some Microsoft artifacts and not others. That reality motivates the scoped phrasing: public attestations for the artifacts Microsoft has audited, plus a promise to expand the mapping as further inventories complete.

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — but with an important qualification.

• If you read Microsoft’s MSRC line strictly, Azure Linux is the only Microsoft product Microsoft has publicly attested to include the edk2 network package for CVE‑2023‑45237 at the time of the advisory; that attestation is authoritative for Azure Linux images.
• Technically and practically, any Microsoft product or artifact that ships the same edk2 code (same commit range without the fix), or that includes firmware/OVMF images built from affecteld carry the vulnerability. Examples of artifacts that commonly pull in edk2 code: OVMF firmware used by virtual machine images, packaged edk2 RPMs in some Linux vendors, or other virtualization/firmware artifacts that embed EDK II. Red Hat, Oracle and other distributors have already patched packaged edk2 instances, which underscores how the library appears across vendor ecosystems.

In short: Azure Linux is the product Microsoft has verified and published. Other Microsoft artifacts are unverified rather than proven safe until either Microsoft publishes additional VEX/CSAF attestations or you perform artifact‑level inspection yourself. Multiple independent analyst and community posts make the same point: treat the MSRC entry as an authoritative signal for Azure Linux and perform artifact verification for any other Microsoft‑supplied images you run.

---

How to determine whether your Microsoft artifacts are affected (practical checklist)​

Perform these steps in order of priority. Each is actionable and rooted in artifact‑level verification — the only reliable way to move from “potentially affected” to “confirmed impacted” or “confirmed not affected.”

• Prioritize Azure Linux images first.
• If you run Azure Linux, follow Microsoft’s remediation guidance for that product and apply the updates Microsoft publishes for the affected images.
• Confirm the OS image and package versions in use; edk2 fixes are distributed as edk2/ovmf package updates in many distros.
• Request machine‑readable attestations (CSAF/VEX) and SBOMs from Microsoft for the artifacts you run.
• Microsoft has begun publishing CSAF/VEX attestations and has pledged to update them as furlete. Use those attestations to determine per‑artifact exposure; where VEX asserts “included,” treat that product as in‑scope.
• Scan or inspect the artifacts yourself.
• For VM images or firmware/OVMF blobs, extract and scan file lists for the edk2 NetworkPkg files (for example, searching for NetLib.h or the TCP/DHCP modules referenced in the edk2 patch notes).
• For package‑based images, query the installed edk2/ovmf package and compare the package version against fixed versions listed in vendor advisories (Red Hat, Ubuntu, Oracle, Amazon Linux all published fixes).
• If you run WSL2 or custom Microsoft kernel artifacts, treat them as potential carries until verified.
• Microsoft distributes kernel artifacts and images across multiple product lines; whether those artifacts include the vulnerable edk2 code depends on the build content. Until Microsoft publishes a VEX attestation or you inspect the artifact, assume uncertainty.
• Use image‑scanning tools and SBOM matching.
• Compare SBOM components against the edk2 commit ranges known to be vulnerable (edk2 stable202311 / specific edk2 revisions listed in upstream patches).
• If you have a CI/CD pipeline building VM/firmware images, integrate the upstream CVE checks into the pipeline so builds fail on insecure edk2 revisions.
• If you find affected artifacts, apply upstream fixes and rebuild/redeploy.
• The edk2 project published security patches; distributions and vendors have rolled fixes into package updates. Apply those updates and, where necessary, rebuild firmware images so the fixed edk2 code is included in the artifact you deploy.

---

Mitigation and risk‑reduction priorities​

• Prioritize patching Azure Linux images that Microsoft attests as including the library. The MSRC attestation is the clearest, immediate operational signal for Azure Linux customers.
• For other Microsoft artifacts (WSL kernels, Azure Marketplace images, specialized VM images, hypervisor/firmware stacks), require artifact inspection or wait for Microsoft’s expanded VEX attestations before relaxing mitigations.
• Where immediate patching isn’t possible, reduce network attack surface:
• Limit or firewall management/boot networks where PXE/firmware network stacks are reachable.
• Use network segmentation and host hardening toss capable of exploiting predictable ISNs.
• Monitor MSRC CVE pages and vendor advisories for updates; Microsoft has explicitly committed to updating CVE mappings if additional Microsoft products are found to ship the component.

---

Notable strengths and potential risks in Microsoft’s approach​

Strengths​

• Transparency for checked products: Microsoft’s product‑scoped attestation provides a high‑fidelity, machine‑readable signal for Azure Linux customers — a meaningful operational benefit that helps prioritize patching. The CSAF/VEX rollout also creates an automated way for customers to consume per‑artifact truth about included open‑source components.
• Phased inventory realism: Performing a per‑product inventory in a large organization with many artifacts is laborious; Microsoft’s explicit wording and commitment to update attestations as inventories continue is pragmatic and creates an auditable trail.

Risks and gaps​

• Misinterpretation risk: The short MSRC FAQ line is easily misread as “only Azure Linux is affected.” That interpretation would be dangerous; absence of an attestation ≠ absence of the vulnerable code. Several community posts and advisories point out exactly this misreading and warn customers not to assume other Microsoft artifacts are safe without verification.
• Artifact blind spots: Customers who consume multiple Microsoft artifacts (Marketplace images, WSL kernels, custom Azure services) may have blind spots if they do not request SBOMs or run independent scans. Microsoft’s promise to update VEX helps, but it still requires either customers to wait for further attestations or to proactively scan their artifacts.
• **Operaen a vendor publishes fixes, rebuilding VM images, OVMF blobs, or firmware stacks and redeploying them at cloud scale takes time and careful orchestration. During that window, systems remain exposed if they shipped vulnerable edk2 revisions.

---

Cross‑reference: who else patched edk2 and what that implies​

Multiple mainstream Linux distributions and vendors treated CVE‑2023‑45237 as sufficiently serious to include edk2 fixes in packaged updates. Red Hat issued specific edk2/security advisories and OVMF/edk2 package updates; Oracle, Ubuntu, Amazon Linux, and other distributors published their own advisories and fixed packages. This proves the edk2 codebase is widely packaged and used across the ecosystem — reinforcing why customers must not assume an absence of attestations equals safety.
Upstream edk2/TianoCore also published patches and a commit list that identifies the NetworkPkg files modified in the security patch. Those upstream patches are the canonical technical fix that downstream packagers and integrators used to remediate the code.

---

Practical remediation checklist (actionable)​

• If you run Azure Linux: apply Microsoft’s Azure Linux updates immediately; confirm package/AMI versions match the fixed releases Microsoft or your distribution lists.
• For other Microsoft artifacts (WSL, Marketplace images, custom kernels): request a VEX/CSAF attestation or SBOM; if unavailable, scan the artifact for edk2 code or package versions and apply fixes where found.
• If you control image/firmware build pipelines: ware images that reference edk2, incorporating the upstream edk2 patches; perform regression testing and redeploy.
• If you cannot immediately patch firmware or images: implement network mitigations (segment boot network, limit PXE/UEFI network reachability) and monitor for suspicious TCP injection or anomalous sequence behavior.
• Document the remediation status of each artifact and maintain a verified SBOM inventory for rapid future triage.

---

Conclusion​

CVE‑2023‑45237 is a genuine vulnerability in EDK II’s network code: a weak PRNG and predictable seed mechanics that make TCP ISNs easier to infer. Multiple vendors and upstream edk2 maintainers published fixes, and mainstream Linux distributors rolled those fixes into package updates. Microsoft’s security guidance naming Azure Linux is authoritative for that product — it confirms Microsoft has inventory‑checked and found the component there — but the wording is product‑scoped, not an exclusivity guarantee. In operational terms, treat Microsoft’s MSRC attestation as definitive for Azure Linux images and treat all other Microsoft artifacts as unverified until confirmed; require VEX/CSAF attestations, SBOMs, or artifact scans before assuming an artifact is unaffected.
The practical job for defenders and operators is straightforward but procedural: identify the artifacts you run, check them (or demand attestations), patch or rebuild where the vulnerable edk2 revision appears, and use network controls to limit exposure while remediation is underway. Microsoft’s commitment to publish machine‑readable attestations and to update CVE entries if further products are found to include the component is helpful — but customers must still perform artifact‑level verification to close their own blind spots.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center