Coverage clarification, 29 October 2026: This article examines a UEFI vulnerability. For the intended investigation of installed rootkits, bootkits and their persistence, read UEFI rootkits: BlackX, firmware implants and the limits of a clean rebuild. The vulnerability analysis remains available as additional reading; it does not establish an infection chain for those implants.

Executive summary

A critical vulnerability in TianoCore EDK II warrants an urgent review of network-booting infrastructure. CVE-2026-97631, also registered as EUVD-2026-108230, concerns pre-boot code execution in the PXE driver. ENISA's European Vulnerability Database records a CVSS v4.0 score of 9.5 and an affected upstream range through edk2-stable202608. That is a codebase-level assessment: it is not an inventory of affected servers or proof that every UEFI device is vulnerable. ENISA EUVD

The practical priority is to identify machines that actually execute the affected network-boot path, establish who can reach them during that interval, and obtain a firmware-specific remediation answer. A source-code fix exists. Its presence in upstream development does not establish that a particular motherboard, appliance or virtual-machine firmware has received it.

This assessment is current to 29 October 2026. No reviewed primary source establishes a named actor exploiting this CVE in the wild. The CISA Known Exploited Vulnerabilities catalogue contained no matching entry when checked for this article; catalogue absence is not proof that exploitation has never occurred. CISA KEV catalogue

What the vulnerability actually exposes

The upstream advisory describes an unauthenticated attack during IPv4 or IPv6 PXE boot. A reachable client accepts ICMP error messages while its PXE driver is active. Incorrect copying into a fixed 504-byte field can corrupt memory during the firmware's Driver Execution Environment phase. The documented outcomes include a boot failure and, for an attacker with knowledge of the target firmware build, execution before the operating system loads. TianoCore advisory

Two boundaries matter. First, this exposure requires the vulnerable boot path to be running; the existence of UEFI firmware on a machine is insufficient. Second, the upstream description permits a routed unicast ICMP message, subject to actual reachability. Its conditions do not require an existing operating-system administrator account or categorically limit the attacker to the same Ethernet segment. Network ACLs, routing and the duration of the boot window therefore belong in the exposure assessment. The CVSS vector records an attack requirement, AT:P, alongside network reachability and no required privileges. TianoCore advisory

For defenders, the right unit of assessment is a device-and-boot-workflow pair. A server normally booting from disk may still try PXE when its disk fails, when an operator selects a recovery option, or when provisioning software changes its next-boot configuration. Treat those as inventory questions, not assumptions about a particular product.

A public fix is not a completed fleet rollout

The repository records an initial public patch proposal on 28 September. A revised fix, pull request 13302, was merged on 15 October, before the advisory's publication on 22 October. The revised change adds bounds checks and corrects the buffer-offset calculation in both address-family handlers; its accompanying tests distinguish the faulty and corrected behaviour. Initial proposal, merged fix

As checked on 29 October, the advisory's patched-version field still gives no patched version, despite linking the merged fix. Record that distinction explicitly: upstream code corrected; downstream firmware delivery must be verified. It would be misleading either to say there is no fix anywhere or to declare every device safe because the pull request is closed.

Distribution trackers reinforce the need to check the actual product. Debian lists its tracked edk2 packages as vulnerable/unfixed, including the listed bookworm, trixie and development versions. These package records are relevant to software-distributed firmware such as OVMF; they do not replace the hardware manufacturer's BIOS advisory. Debian security tracker

SUSE records affected ovmf products and an overall pending state. It also publishes an 8.8 CVSS v3.1 assessment with an adjacent-network vector, alongside the upstream 9.5 CVSS v4.0 vector. These are different assessments and scoring versions. Retain their provenance rather than silently substituting one score or assuming that either describes the network layout of a particular installation. SUSE advisory

Exposure triage: questions that produce an actionable inventory

The following is TIR's defensive triage recommendation, rather than a vendor-certified affected-model list.

Check Evidence to retain Operational consequence
Firmware provenance Manufacturer, model, firmware version and vendor response for this CVE Establish whether the vulnerable component or its fix is present
Boot paths Normal boot order, one-time boot settings, fallback and recovery procedures Find devices that can enter PXE even if ordinary boots use disk
IPv4 and IPv6 Provisioning configuration and routing/ACL review for both families Avoid assessing only one of the two affected handlers
Network access during boot Provisioning VLAN boundaries, allowed sources and remote-management paths Determine whether untrusted traffic can reach the pre-OS client
Virtual firmware Hypervisor/OVMF package version and the firmware image assigned to each VM class Distinguish package installation from the firmware a guest actually uses
Remediation receipt Vendor bulletin, fixed image identity, rollout record and post-update verification Close an asset only against a specific verified fix

Prioritise shared provisioning environments, remotely recoverable systems and devices whose boot networks are reachable from less-trusted segments. Evaluate the effect of a provisioning outage as well as confidentiality risk: a failed recovery path can prolong an otherwise routine incident.

For disk-only systems, confirm that network boot and fallback are disabled where operationally appropriate. For systems that require PXE, document why and assign an owner to the temporary exposure controls. An unknown firmware lineage should remain an unresolved assessment, not automatically become either “affected” or “safe”.

Containment while the vendor-specific update is established

Where network boot is unnecessary, remove that path through the supported firmware-management process and test normal startup and recovery. Where it is necessary, restrict access to the provisioning environment and review the paths by which traffic can reach a booting client. Preserve an approved recovery method before changing boot settings.

Do not apply a blanket instruction to drop all ICMP or disable IPv6 across the estate. Those protocols have legitimate network functions, and a poorly scoped control can disrupt provisioning or ordinary connectivity. Use the network and platform teams to define a narrow, tested control that addresses the reachable boot path. The desired outcome is a documented reduction in exposure, with an owner and a review date.

Request a written answer from each relevant vendor: whether the deployed firmware contains the affected driver; which image or package contains the correction; whether a reboot, cold start or other activation step is required; and how an operator verifies the running result. Do not flash a generic EDK II build onto production hardware as a substitute for its supported firmware image.

A maintenance record should distinguish downloaded, installed, activated and verified. For virtual infrastructure, also confirm what existing and newly provisioned guests will use. If no supported correction is available, retain the exception and compensating controls in the asset record rather than closing the vulnerability on the strength of an upstream commit.

Detection and investigation

There is no campaign-specific IOC set in the reviewed primary disclosure. Do not treat a generic boot failure, a large packet or the presence of PXE as proof of exploitation. Useful investigation begins by correlating several independent observations.

Retain provisioning timestamps, DHCP/PXE service records, network telemetry for the relevant segment, remote-management activity and firmware-update records. Unexpected boot-order changes, unexplained provisioning failures, or access to management interfaces outside an approved change window can justify examination. They also have benign explanations, including deployment errors, failing hardware and legitimate recovery work.

If an asset is suspected of compromise, isolate it through an approved process and preserve available evidence before reflashing or replacing components. Ask the vendor or a firmware specialist to establish whether the event is confined to memory, has changed disk-resident boot components, or has modified persistent firmware. That distinction determines recovery. A clean endpoint scan alone does not resolve a concern about execution before the endpoint agent started.

MITRE ATT&CK's Pre-OS Boot family provides useful terminology for investigation and prevention, including firmware integrity checks, controlled network access and authorised update processes. Map an observed persistence mechanism only when evidence supports it. A vulnerability's potential to execute in firmware is not itself proof of System Firmware persistence (T1542.001) or a deployed Bootkit (T1542.003). MITRE ATT&CK T1542

Threat-actor context: a precedent, not an attribution

Firmware threats have a documented operational history. ESET's LoJax investigation linked malicious UEFI firmware to APT28, also tracked in that reporting as Sednit and Fancy Bear. It documented writing a malicious module into SPI flash, giving that particular implant persistence beyond an operating-system reinstall. That is evidence about LoJax, not evidence that APT28 uses CVE-2026-97631. ESET LoJax research

TIR's updated APT28 profile supplies the wider actor context, including the distinction between documented long-term monitoring, infrastructure longevity and firmware persistence. Its router-hijacking investigation covers a separate campaign and should not be read as a link to this firmware flaw.

Keep the current issue separate from Windows bootloader revocation problems. Microsoft's BlackLotus-related guidance describes a different Secure Boot bypass, with physical access or local-administrator privileges and specific boot-manager mitigation steps. Those requirements are not interchangeable with this EDK II network-boot vulnerability. Nor does applying those Windows mitigations demonstrate that an OEM's PXE firmware has been corrected. Microsoft boot-manager guidance

A durable implant surviving disk replacement requires evidence of persistence outside that disk. The public description of CVE-2026-97631 establishes a pre-OS execution opportunity; it does not establish that every successful use automatically rewrites SPI flash or survives every reboot. That difference should remain visible in incident reporting and executive briefings.

Persistence, dwell time and trusted access

The comparison with sophisticated attacks on management appliances is operational: both can place attacker activity outside an ordinary endpoint agent's view. The persistence layer still matters. Firmware modification, an appliance implant, a changed administrative permission and a stolen token require different evidence and different removal steps. An operating-system rebuild does not validate all those layers.

Likely (B2) — a response limited to patch installation will leave material uncertainty about an already compromised system. This is an assessment from the distinction between the corrected PXE code and ESET's separately documented persistent firmware implant; it is not a finding that this CVE installs LoJax. Patch verification closes the vulnerable entry point. Incident closure requires evidence about what an attacker actually changed.

No measured dwell time for CVE-2026-97631 is established by the reviewed disclosure. A boot-time exposure window is not an estimate of time an attacker remains undetected. Our BeyondTrust/Bomgar and SolarWinds comparison examines trusted remote access, permission persistence and the limits of comparing different incident timelines.

Assessment and outlook

TIR assessment: inventory and restrict exposed provisioning paths now, while obtaining product-specific remediation evidence. The potentially high impact makes the issue significant, but indiscriminate fleet-wide assumptions will waste effort and can damage recovery capability. Prioritisation should follow verified boot behaviour, network reachability and the status of the deployed firmware.

Three developments would change this assessment: a credible report of in-the-wild exploitation; a vendor-confirmed affected-model and fixed-version matrix; or evidence that a given environment exposes a broader boot path than its current inventory records. Monitor the upstream advisory, the appropriate vendor tracker and the EUVD record for changes.

Evidence confidence: high for the published vulnerability identity, disclosed conditions and merged upstream correction; unresolved for a complete downstream hardware list and named-actor exploitation. Official records are assessed A2 for this review: authoritative provenance, without independent exploit reproduction by TIR. Defensive priorities above are analysis, not observed attacker activity.

Related TIR reporting

Sources are linked beside the claims they support. EUVD information is attributed to ENISA's European Vulnerability Database. No live exploitation test was performed for this assessment.