CVE-2026-6485: H2O BIOS Shell — HIGH

CISO Take

This vulnerability lives in the UEFI firmware shell shipped by InsydeH2O (a BIOS vendor used across many OEM systems, including GPU and edge-inference servers), where crafted shell commands or startup scripts can bypass Secure Boot and load unsigned, potentially malicious boot code. It is not an AI/ML software vulnerability — the 'ml_library' tagging here appears to be a data classification artifact (likely a name collision with the h2o package), and there is no evidence this affects any AI framework, model, or inference pipeline directly. That said, any AI infrastructure host running InsydeH2O firmware — training clusters, GPU inference nodes, edge AI appliances — inherits the exposure at the platform-integrity layer, since a Secure Boot bypass undermines the trust root for everything running above it, including AI workloads. Exploitation requires local access and high privileges (AV:L/PR:H), there is no public exploit, no CISA KEV listing, and no EPSS data, which puts real-world exploitation likelihood low for now. Action: inventory hosts running InsydeH2O firmware (especially bare-metal AI/GPU servers and edge devices), apply the vendor patch referenced in Insyde's advisory SA-2026004 once available for your OEM's BIOS version, and treat this as a standard firmware/Secure Boot hardening item rather than an AI-specific risk.

Sources: NVD CISA KEV OpenSSF

What is the risk?

Moderate severity in absolute terms (CVSS 8.2, high confidentiality/integrity/availability impact) but low near-term exploitation likelihood given local access and high-privilege prerequisites, no public exploit code, no scanner template, and absence from CISA KEV. This is a firmware/platform-security issue, not an AI/ML-specific vulnerability — its relevance to AI systems is limited to shared infrastructure risk (any compute host, AI or otherwise, running affected InsydeH2O firmware inherits the exposure).

How does the attack unfold?

Local privileged access

Attacker obtains high-privilege local access to a host running vulnerable InsydeH2O UEFI firmware.

UEFI Shell abuse

Attacker invokes the embedded UEFI Shell to run commands or a startup script that bypasses Secure Boot checks.

Boot integrity compromise

An unsigned bootkit or malicious boot component loads beneath the OS, persisting across reboots and reinstalls.

AML.T0112

Downstream host compromise

With trusted boot broken, the attacker gains a durable foothold on the host, potentially exposing any AI workloads, credentials, or data running above it.

Local privileged access

Attacker obtains high-privilege local access to a host running vulnerable InsydeH2O UEFI firmware.

UEFI Shell abuse

Attacker invokes the embedded UEFI Shell to run commands or a startup script that bypasses Secure Boot checks.

Boot integrity compromise

An unsigned bootkit or malicious boot component loads beneath the OS, persisting across reboots and reinstalls.

AML.T0112

Downstream host compromise

With trusted boot broken, the attacker gains a durable foothold on the host, potentially exposing any AI workloads, credentials, or data running above it.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
H2O	pip	—	No patch
7.5K OpenSSF 5.5 27 dependents Pushed 11d 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.1%

chance of exploitation in 30 days

Higher than 2% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

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 servers/workstations/edge devices for InsydeH2O UEFI firmware, prioritizing bare-metal AI training and inference hosts. 2) Check OEM BIOS release notes against Insyde advisory SA-2026004 and apply the vendor-supplied firmware update when your OEM ships it. 3) Until patched, restrict physical and privileged local access to affected hosts (this requires PR:H, so credential/access hygiene materially reduces risk). 4) Where supported, disable or lock down the UEFI Shell in production BIOS configurations and enforce Secure Boot key protections (e.g., BIOS admin passwords, disabling boot-order changes from OS). 5) Detection: monitor for unexpected boot configuration changes, unsigned boot loaders, or Secure Boot state changes via TPM attestation/measured boot logs if available.

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?

Auth Bypass Code Execution Inference

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6 - Security of AI system supporting infrastructure

NIST AI RMF

GOVERN 1.5 - Risk monitoring and management processes are established for AI system infrastructure

Frequently Asked Questions

What is CVE-2026-6485?

This vulnerability lives in the UEFI firmware shell shipped by InsydeH2O (a BIOS vendor used across many OEM systems, including GPU and edge-inference servers), where crafted shell commands or startup scripts can bypass Secure Boot and load unsigned, potentially malicious boot code. It is not an AI/ML software vulnerability — the 'ml_library' tagging here appears to be a data classification artifact (likely a name collision with the h2o package), and there is no evidence this affects any AI framework, model, or inference pipeline directly. That said, any AI infrastructure host running InsydeH2O firmware — training clusters, GPU inference nodes, edge AI appliances — inherits the exposure at the platform-integrity layer, since a Secure Boot bypass undermines the trust root for everything running above it, including AI workloads. Exploitation requires local access and high privileges (AV:L/PR:H), there is no public exploit, no CISA KEV listing, and no EPSS data, which puts real-world exploitation likelihood low for now. Action: inventory hosts running InsydeH2O firmware (especially bare-metal AI/GPU servers and edge devices), apply the vendor patch referenced in Insyde's advisory SA-2026004 once available for your OEM's BIOS version, and treat this as a standard firmware/Secure Boot hardening item rather than an AI-specific risk.

Is CVE-2026-6485 actively exploited?

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

How to fix CVE-2026-6485?

1) Inventory servers/workstations/edge devices for InsydeH2O UEFI firmware, prioritizing bare-metal AI training and inference hosts. 2) Check OEM BIOS release notes against Insyde advisory SA-2026004 and apply the vendor-supplied firmware update when your OEM ships it. 3) Until patched, restrict physical and privileged local access to affected hosts (this requires PR:H, so credential/access hygiene materially reduces risk). 4) Where supported, disable or lock down the UEFI Shell in production BIOS configurations and enforce Secure Boot key protections (e.g., BIOS admin passwords, disabling boot-order changes from OS). 5) Detection: monitor for unexpected boot configuration changes, unsigned boot loaders, or Secure Boot state changes via TPM attestation/measured boot logs if available.

What systems are affected by CVE-2026-6485?

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

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

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

What is the AI security impact?

Affected AI Architectures

model serving infrastructuretraining pipelinesedge AI deployments

Compliance Controls Affected

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN 1.5

What are the technical details?

Original Advisory

UEFI BIOS embedded Shell could be used to bypass Secure Boot via shell commands or startup scripts.

Exploitation Scenario

An adversary who has already obtained high-privilege local access to an AI infrastructure host (e.g., via a prior compromise, insider access, or physical access to an on-prem GPU server) invokes the InsydeH2O UEFI Shell and issues commands or a startup script that disables or circumvents Secure Boot signature checks. This lets the attacker load an unsigned bootkit that persists beneath the OS and any AI runtime, surviving reinstalls and evading OS-level EDR, potentially enabling long-term stealthy access to sensitive training data, model weights, or credentials stored on that host.