CVE-2026-6484: H2O unverified boot — HIGH

CISO Take

This CVE affects InsydeH2O, the UEFI firmware licensed by many OEMs/ODMs to build BIOS images, and stems from a missing verification step on a firmware volume (FV) that lets a local, already-privileged attacker execute arbitrary code below the operating system. The CVSS 8.2 score reflects a scope-changed, high-impact flaw (C:H/I:H/A:H), but the attack vector is local and requires high privileges, which is why EPSS sits at just 0.00144 and CISA's SSVC decision is TRACK rather than Act — there is no public exploit and no Nuclei template, and it is not in CISA KEV. The real concern for AI/ML shops is asset scope: any training cluster, GPU/accelerator server, or edge inference appliance built on InsydeH2O firmware inherits a root-of-trust weakness that a post-compromise attacker (malware already on the box, malicious insider, or a supply-chain implant) can use to plant a persistent bootkit that survives OS reinstalls. Action: inventory hosts running InsydeH2O firmware, apply the vendor patch referenced in Insyde's advisory SA-2026003 once your OEM ships it, and enforce Secure Boot plus TPM-based firmware attestation on hosts running AI training or inference workloads. Given the low near-term exploitation likelihood, treat this as a scheduled firmware-patch item prioritized for AI compute infrastructure rather than an emergency.

Sources: NVD EPSS insyde.com OpenSSF

What is the risk?

Severity is high (CVSS 8.2, scope changed, full C/I/A impact) but exploitability is constrained: the attack vector is local and requires high privileges with no user interaction, meaning it functions as a privilege-escalation/persistence primitive for an attacker who already has elevated code execution on the host rather than a remote initial-access vector. EPSS (0.00144) and the absence of KEV listing, public exploit code, or a scanner template all point to low near-term mass-exploitation likelihood, consistent with CISA's SSVC 'TRACK' decision. The residual risk that matters is asset-specific: on high-value AI compute hosts (training clusters, GPU/accelerator inference servers, edge AI appliances), a firmware-level implant defeats OS- and container-level defenses entirely, so the effective risk should be weighted by how many such hosts run InsydeH2O firmware rather than by the generic exploitation score.

How does the attack unfold?

Local Foothold

Attacker obtains high-privilege local code execution on the target host through a separate compromise (credential theft, malicious dependency, or physical access).

Firmware Volume Tampering

Attacker writes to the unverified firmware volume, bypassing the missing boot verification check to plant malicious UEFI-level code.

Pre-OS Persistence

Malicious firmware code executes during boot, before the OS and security agents load, establishing persistence that survives OS reinstalls.

Impact on AI Host

Attacker leverages boot-level control to tamper with or exfiltrate data on the AI training/inference host, undermining all higher-layer security controls.

Local Foothold

Attacker obtains high-privilege local code execution on the target host through a separate compromise (credential theft, malicious dependency, or physical access).

Firmware Volume Tampering

Attacker writes to the unverified firmware volume, bypassing the missing boot verification check to plant malicious UEFI-level code.

Pre-OS Persistence

Malicious firmware code executes during boot, before the OS and security agents load, establishing persistence that survives OS reinstalls.

Impact on AI Host

Attacker leverages boot-level control to tamper with or exfiltrate data on the AI training/inference host, undermining all higher-layer security controls.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
H2O	pip	—	No patch
7.5K OpenSSF 5.5 27 dependents Pushed 6d ago 4% patched ~0d to patch Full package profile →

Do you use H2O? You're affected.

How severe is it?

CVSS 3.1

8.2 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 29% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Advanced

What is the attack surface?

AV Local

AC Low

PR High

UI None

S Changed

C High

I High

A High

What should I do?

1 step

1) Inventory devices running InsydeH2O firmware — check BIOS vendor/version via dmidecode -t bios (Linux) or OEM firmware tooling, prioritizing AI training/inference hosts and edge appliances. 2) Apply the OEM/ODM BIOS update referencing Insyde's advisory SA-2026003 as soon as it is available for your specific platform (Insyde is an IBV — patches ship through the device OEM, not directly from Insyde). 3) Enforce UEFI Secure Boot with vendor-controlled keys and verify Boot Guard/Platform Key configuration is locked. 4) Add TPM-based remote attestation or firmware integrity monitoring (e.g., measured boot logs) for AI compute hosts to detect firmware tampering. 5) Restrict local administrative/physical access to AI infrastructure, since exploitation requires high local privileges. 6) No workaround exists short of patching or enforcing verified boot — this is not remotely mitigable via network controls.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Supply Chain Inference

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2 - AI system security controls

NIST AI RMF

MANAGE 2.3 - Third-party and infrastructure risks are regularly monitored and managed

Frequently Asked Questions

What is CVE-2026-6484?

This CVE affects InsydeH2O, the UEFI firmware licensed by many OEMs/ODMs to build BIOS images, and stems from a missing verification step on a firmware volume (FV) that lets a local, already-privileged attacker execute arbitrary code below the operating system. The CVSS 8.2 score reflects a scope-changed, high-impact flaw (C:H/I:H/A:H), but the attack vector is local and requires high privileges, which is why EPSS sits at just 0.00144 and CISA's SSVC decision is TRACK rather than Act — there is no public exploit and no Nuclei template, and it is not in CISA KEV. The real concern for AI/ML shops is asset scope: any training cluster, GPU/accelerator server, or edge inference appliance built on InsydeH2O firmware inherits a root-of-trust weakness that a post-compromise attacker (malware already on the box, malicious insider, or a supply-chain implant) can use to plant a persistent bootkit that survives OS reinstalls. Action: inventory hosts running InsydeH2O firmware, apply the vendor patch referenced in Insyde's advisory SA-2026003 once your OEM ships it, and enforce Secure Boot plus TPM-based firmware attestation on hosts running AI training or inference workloads. Given the low near-term exploitation likelihood, treat this as a scheduled firmware-patch item prioritized for AI compute infrastructure rather than an emergency.

Is CVE-2026-6484 actively exploited?

No confirmed active exploitation of CVE-2026-6484 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-6484?

1) Inventory devices running InsydeH2O firmware — check BIOS vendor/version via `dmidecode -t bios` (Linux) or OEM firmware tooling, prioritizing AI training/inference hosts and edge appliances. 2) Apply the OEM/ODM BIOS update referencing Insyde's advisory SA-2026003 as soon as it is available for your specific platform (Insyde is an IBV — patches ship through the device OEM, not directly from Insyde). 3) Enforce UEFI Secure Boot with vendor-controlled keys and verify Boot Guard/Platform Key configuration is locked. 4) Add TPM-based remote attestation or firmware integrity monitoring (e.g., measured boot logs) for AI compute hosts to detect firmware tampering. 5) Restrict local administrative/physical access to AI infrastructure, since exploitation requires high local privileges. 6) No workaround exists short of patching or enforcing verified boot — this is not remotely mitigable via network controls.

What systems are affected by CVE-2026-6484?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, edge AI deployments.

What is the CVSS score for CVE-2026-6484?

CVE-2026-6484 has a CVSS v3.1 base score of 8.2 (HIGH). The EPSS exploitation probability is 0.37%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesedge AI deployments

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

NIST AI RMF: MANAGE 2.3

What are the technical details?

Original Advisory

In an UEFI, Lack of verified boot to certain FV may cause arbitrary code execution.

Exploitation Scenario

An attacker who has already gained high-privilege local code execution on an AI compute host — for example via a compromised ML pipeline dependency, a stolen admin credential, or physical/console access to an edge AI appliance — writes to the unverified firmware volume to implant malicious code that runs during the UEFI boot sequence, before the OS and any endpoint security agent loads. This gives the attacker a persistence foothold beneath the operating system that survives reimaging or OS-level incident response. From there, the attacker can quietly tamper with the boot chain to weaken subsequent security controls, intercept or exfiltrate data (model weights, credentials, RAG/vector DB secrets) processed by the host, or maintain long-term covert access to a shared AI training or inference cluster.

Weaknesses (CWE)

CWE-1277 Firmware Not Updateable

CWE-1277 — Firmware Not Updateable: The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.

[Requirements] Specify requirements to include the ability to update the firmware. Include integrity checks and authentication to ensure that untrusted firmware cannot be installed.
[Architecture and Design] Design the device to allow for updating the firmware. Ensure that the design specifies how to distribute the updates and ensure their integrity and authentication.

Source: MITRE CWE corpus.