CVE-2023-45236 is a medium severity flaw, scored 5.8, in the EDK2 network package. It uses a predictable TCP initial sequence number. The fix is in edk2-stable202405, so update firmware and avoid network boot on untrusted networks. Network boot on untrusted networks carries the risk.
What's affected
The advisory for the EDK2 network stack (tracked as GHSA-hc6x-cw6p-gj7h) lists NetworkPkg in EDK2 up to and including the 202311 release as affected. The NVD record shows the product as TianoCore EDK2 with no version bounds, so the advisory is the more precise source.
The advisory lists edk2-stable202405 as the fixed release for this CVE and for CVE-2023-45237. It also says these two issues are limited to PXE or HTTP boot on untrusted networks, which it describes as not a recommended use of the UEFI network stack, and that no known exploits exist for them.
EDK2 is the open source UEFI firmware reference code. Many vendors build their own firmware from it, so the version you need to look at is your firmware vendor's release, not the EDK2 tag. Virtual machine firmware such as OVMF is built from the same code.
How to check if you're exposed
You need to know two things: whether your machines run an EDK2 based firmware, and whether network boot is enabled on them.
On a Linux host you can read the firmware vendor and version from the DMI tables:
sudo dmidecode -t bios
For virtual machines that use OVMF, check the packaged firmware build on the hypervisor host:
dpkg -l | grep -i ovmf
rpm -q edk2-ovmf
Compare the result with your vendor's advisory, since vendors backport fixes under their own version numbers. Then look in firmware setup, or in your fleet tooling, for PXE or HTTP boot settings. The advisory states that exploitation needs PXE boot enabled, that it is off by default, and that it is often turned on for servers and some laptops.
What to do now
- List the systems whose firmware is built from EDK2, including virtual machines that use OVMF, and record the firmware version of each.
- Update to firmware that includes EDK2 stable 202405 or later.
- If you cannot update yet, turn off PXE and HTTP boot on machines that do not need network boot, as the advisory suggests.
- Keep firmware update status in the same inventory as your software dependencies, so a future firmware advisory is a query and not a project.
Why it matters
The weakness is a predictable value where an unpredictable one is needed: CWE-338, use of a weak pseudo random number generator, with CWE-200, exposure of sensitive information, also listed in the record. A TCP initial sequence number that can be guessed lets an off path attacker try to inject data into a connection.
The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, giving 5.8. Compare it with CVE-2023-45237, which describes the same flaw with a lower score of 5.3 and a vector without the changed scope. The GitHub advisory lists both scores, so the difference is in the records, not a mistake on this page.
The advisory says no known exploits exist for either issue, and the CVE is not on the CISA KEV list. The risk is real only where machines boot over a network you do not control.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan reads the manifests and lockfiles of software projects. It will not see firmware or device images, so for this issue the asset inventory and the vendor advisory are your main tools.
Quick check
Why does this CVE have a different score from CVE-2023-45237?
The advisory lists 5.8 for this one and 5.3 for the other. The vectors differ in scope, so the base scores differ.
Is network boot safe on a trusted network?
The advisory frames the risk as PXE or HTTP boot on untrusted networks. Trusted, controlled networks carry less exposure.
Sources
Last reviewed: 19 October 2026.
