CVE-2021-43613: H2O password hashes exposed,

CISO Take

This is a firmware-level flaw in Insyde InsydeH2O's SysPasswordDxe module, where user and administrator BIOS password hashes are written into runtime UEFI variables that any locally-authenticated low-privilege process can read, enabling privilege escalation on the affected machine. It requires local access already (AV:L, PR:L) and no public exploit code or Nuclei template exists, and it is not in CISA's KEV list, so this is not an actively-exploited, internet-facing threat — the EPSS score of 0.00114 reflects very low real-world exploitation probability. Despite the ml_library tag in this feed, InsydeH2O is general-purpose UEFI firmware, not an AI/ML software package; its relevance to AI operations is indirect, limited to on-prem GPU training clusters, edge inference appliances, or MLOps workstations that happen to run affected Insyde-based firmware and rely on BIOS passwords as a physical/local-access control. With 21 other CVEs recorded against this same firmware codebase and an OpenSSF Scorecard of 5.7/10, this looks like a pattern of firmware hardening debt rather than an isolated bug — asset owners should inventory which servers/workstations use InsydeH2O firmware, apply Insyde's vendor patch referenced in SA-2022027, and stop relying on UEFI/BIOS passwords alone as a security boundary on shared or physically-accessible AI infrastructure.

Sources:NVDEPSSOpenSSFATLASinsyde.com

What is the risk?

Medium severity (CVSS 6.5) with local attack vector and low privileges required — an attacker needs an existing local, low-privileged session on the target machine to read the exposed runtime UEFI variable and recover password hashes, then use them to escalate to administrator/BIOS-level privileges. No user interaction is needed and complexity is low, so once local access is achieved, exploitation is straightforward for anyone who understands UEFI variable enumeration. However, exploitability in the wild is low: no public PoC, no Metasploit/ExploitDB module, no CISA KEV listing, and an EPSS score of 0.00114 (well below typical actively-exploited thresholds). The realistic risk is concentrated in environments where untrusted or lower-tier users already have local shell/console access to shared AI training or inference hardware (e.g., shared GPU servers, lab workstations, multi-tenant on-prem clusters) and where BIOS/firmware password reuse across a fleet would let a single compromised hash escalate to broader hardware control.

How does the attack unfold?

Initial local access

Attacker obtains a low-privileged local session on a machine running InsydeH2O firmware, such as a shared AI training server or GPU workstation.

Credential exposure

Attacker reads the runtime UEFI variable exposed by SysPasswordDxe to recover user and administrator BIOS password hashes.

AML.T0090

Privilege escalation

Attacker cracks or reuses the extracted hashes to gain BIOS/firmware administrator privileges on the host.

Impact

With firmware-level access, attacker can tamper with boot integrity or Secure Boot settings, undermining trust in the hardware that hosts AI training data or models.

Initial local access

Attacker obtains a low-privileged local session on a machine running InsydeH2O firmware, such as a shared AI training server or GPU workstation.

Credential exposure

Attacker reads the runtime UEFI variable exposed by SysPasswordDxe to recover user and administrator BIOS password hashes.

AML.T0090

Privilege escalation

Attacker cracks or reuses the extracted hashes to gain BIOS/firmware administrator privileges on the host.

Impact

With firmware-level access, attacker can tamper with boot integrity or Secure Boot settings, undermining trust in the hardware that hosts AI training data or models.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
H2O	pip	—	No patch
7.5KOpenSSF 5.727 dependentsPushed 11d ago8% patched~0d to patchFull package profile →

Do you use H2O? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 3% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVLocal

ACLow

PRLow

UINone

SChanged

CNone

IHigh

ANone

What should I do?

1 step

1) Inventory hardware/firmware to identify systems running Insyde InsydeH2O, especially on-prem AI training servers, GPU nodes, and edge inference devices. 2) Apply the vendor-supplied firmware update referenced in Insyde's advisory SA-2022027 (https://www.insyde.com/security-pledge/sa-2022027/) as soon as your OEM ships a corresponding BIOS update. 3) Until patched, treat local access to affected hosts as equivalent to BIOS-admin access — restrict physical and OS-level local access to trusted personnel only, and avoid relying solely on BIOS/firmware passwords as an isolation boundary in shared/multi-tenant AI compute environments. 4) Rotate any BIOS/firmware passwords that may have been exposed, and avoid password reuse between firmware and OS/domain accounts. 5) Detection is limited since exploitation happens locally via UEFI variable reads with no network signature — monitor for unexpected UEFI variable access attempts or unauthorized firmware configuration changes via endpoint/EDR tooling where supported, and track OEM BIOS version compliance in your asset management system.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

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

How is it classified?

Data LeakageAuth BypassInferenceAML.T0090- OS Credential Dumping

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6-AI system infrastructure security

NIST AI RMF

GOVERN 4.1-Risk management processes account for third-party and infrastructure risk

Frequently Asked Questions

What is CVE-2021-43613?

This is a firmware-level flaw in Insyde InsydeH2O's SysPasswordDxe module, where user and administrator BIOS password hashes are written into runtime UEFI variables that any locally-authenticated low-privilege process can read, enabling privilege escalation on the affected machine. It requires local access already (AV:L, PR:L) and no public exploit code or Nuclei template exists, and it is not in CISA's KEV list, so this is not an actively-exploited, internet-facing threat — the EPSS score of 0.00114 reflects very low real-world exploitation probability. Despite the ml_library tag in this feed, InsydeH2O is general-purpose UEFI firmware, not an AI/ML software package; its relevance to AI operations is indirect, limited to on-prem GPU training clusters, edge inference appliances, or MLOps workstations that happen to run affected Insyde-based firmware and rely on BIOS passwords as a physical/local-access control. With 21 other CVEs recorded against this same firmware codebase and an OpenSSF Scorecard of 5.7/10, this looks like a pattern of firmware hardening debt rather than an isolated bug — asset owners should inventory which servers/workstations use InsydeH2O firmware, apply Insyde's vendor patch referenced in SA-2022027, and stop relying on UEFI/BIOS passwords alone as a security boundary on shared or physically-accessible AI infrastructure.

Is CVE-2021-43613 actively exploited?

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

How to fix CVE-2021-43613?

1) Inventory hardware/firmware to identify systems running Insyde InsydeH2O, especially on-prem AI training servers, GPU nodes, and edge inference devices. 2) Apply the vendor-supplied firmware update referenced in Insyde's advisory SA-2022027 (https://www.insyde.com/security-pledge/sa-2022027/) as soon as your OEM ships a corresponding BIOS update. 3) Until patched, treat local access to affected hosts as equivalent to BIOS-admin access — restrict physical and OS-level local access to trusted personnel only, and avoid relying solely on BIOS/firmware passwords as an isolation boundary in shared/multi-tenant AI compute environments. 4) Rotate any BIOS/firmware passwords that may have been exposed, and avoid password reuse between firmware and OS/domain accounts. 5) Detection is limited since exploitation happens locally via UEFI variable reads with no network signature — monitor for unexpected UEFI variable access attempts or unauthorized firmware configuration changes via endpoint/EDR tooling where supported, and track OEM BIOS version compliance in your asset management system.

What systems are affected by CVE-2021-43613?

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

What is the CVSS score for CVE-2021-43613?

CVE-2021-43613 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.13%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelines

MITRE ATLAS Techniques

AML.T0090OS Credential Dumping

Compliance Controls Affected

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN 4.1

What are the technical details?

Original Advisory

An issue was discovered in SysPasswordDxe in Insyde InsydeH2O. User and administrator password hashes are exposed in runtime UEFI variables, leading to escalation of privilege

Exploitation Scenario

An adversary who has already obtained a low-privileged local session on an on-prem AI training server or GPU workstation — for example via a compromised service account, a malicious internal user, or lateral movement from a less-secured shared research environment — enumerates UEFI runtime variables exposed by SysPasswordDxe and extracts the stored user/administrator BIOS password hashes. Because no additional user interaction or high privilege is required, the attacker cracks or reuses these hashes to obtain administrator-level firmware access, potentially disabling Secure Boot, tampering with boot-time integrity checks, or establishing low-level persistence that survives OS reinstallation — all without ever touching the AI models, training data, or inference APIs running on the machine, but undermining the trust foundation of the hardware they depend on.

Weaknesses (CWE)

CWE-732Incorrect Permission Assignment for Critical Resource

CWE-732 — Incorrect Permission Assignment for Critical Resource: The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

[Implementation] When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
[Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]

Source: MITRE CWE corpus.