CVE-2026-65197 Overview
CVE-2026-65197 is an improper signature verification flaw [CWE-347] in H3C HDM Family-A baseboard management controllers. The firmware updater validates RSA signatures against a public key stored in the mutable file /conf/public.pem. An authenticated Redfish client with firmware-update privilege can overwrite that trust anchor through the UpdateService.UploadSignKey action. The device then accepts firmware signed with the attacker's matching private key. Family-A platforms ship without a hardware root-of-trust (no PFR), so the substituted key goes undetected. The issue was observed on H3C HDM Family-A G5 HDM 6.14.01, and G3/G5 builds exposing the Redfish/DRE update tree appear affected. HDM2 uses a different update path and is not in scope.
Critical Impact
An authenticated administrator can replace the firmware trust anchor and install a signed malicious BMC image, bypassing cryptographic update protections entirely.
Affected Products
- H3C HDM Family-A G5 HDM 6.14.01 (confirmed)
- H3C HDM Family-A G3 builds exposing the Redfish/DRE update tree
- H3C HDM Family-A G5 builds exposing the Redfish/DRE update tree
Discovery Timeline
- 2026-10-13 - CVE-2026-65197 published to NVD
- 2026-10-14 - Last updated in NVD database
Technical Details for CVE-2026-65197
Vulnerability Analysis
The H3C HDM Family-A firmware updater performs RSA signature verification using a public key loaded from the filesystem rather than from immutable hardware storage. The verifier reads /conf/public.pem at update time and treats whatever key is present as authoritative. Because the same management plane exposes a Redfish endpoint that writes to this file, the trust boundary collapses into a single authenticated API call. The result is a classic chicken-and-egg failure: the key used to verify firmware is itself protected only by the same OS the firmware updates.
Root Cause
Two design decisions combine to produce the flaw. First, the UpdateService.UploadSignKey Redfish action accepts arbitrary content and writes it verbatim to /conf/public.pem, performing only a filename extension check that the multipart field ends in .pem. Second, Family-A platforms lack a Platform Firmware Resilience (PFR) hardware root-of-trust, so there is no out-of-band mechanism to attest that the public key in use matches a vendor-provisioned key. The verification chain terminates in mutable storage.
Attack Vector
An attacker needs valid credentials for an account carrying the firmware-update privilege, or any administrator account, and network reachability to the BMC Redfish interface. The attacker generates an RSA keypair, uploads the public key through the UpdateService.UploadSignKey action, signs a crafted firmware image with the matching private key, and submits the image through the standard firmware update workflow. The device verifies the image against the attacker-controlled key and installs it. See the RunZero Advisory on CVE-2026-65197 for the full technical write-up.
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-65197
Indicators of Compromise
- Modification timestamp changes on /conf/public.pem that do not correlate with vendor firmware releases.
- Redfish audit entries recording UpdateService.UploadSignKey invocations.
- Firmware images whose signing certificate subject or fingerprint does not match H3C's published signing key.
- Unexpected BMC firmware version strings or build hashes after a maintenance window.
Detection Strategies
- Baseline the SHA-256 hash of /conf/public.pem on each BMC and alert on any drift.
- Parse BMC Redfish and syslog streams for UploadSignKey and SimpleUpdate action calls, correlating actor accounts with change tickets.
- Compare installed firmware image hashes against vendor-published values after every update.
Monitoring Recommendations
- Forward BMC audit logs to a centralized SIEM and retain them for at least 180 days.
- Alert on authentication events for accounts holding the firmware-update role, especially outside maintenance windows.
- Monitor management-network segments for Redfish traffic originating from unexpected sources.
How to Mitigate CVE-2026-65197
Immediate Actions Required
- Restrict Redfish access to a dedicated, isolated management VLAN with strict ACLs.
- Audit all accounts with the firmware-update privilege and remove unnecessary assignments.
- Rotate BMC administrator credentials and enforce strong, unique passwords.
- Capture a known-good hash of /conf/public.pem on every HDM Family-A system and monitor for changes.
Patch Information
At the time of publication no vendor patch is referenced in the enriched data. Consult the RunZero Advisory on CVE-2026-65197 and H3C support channels for firmware updates addressing the mutable trust anchor. Because Family-A platforms lack PFR, any fix must either lock down the Redfish action or move the verification key to immutable storage.
Workarounds
- Block the UpdateService.UploadSignKey endpoint at an upstream reverse proxy or management firewall where feasible.
- Disable Redfish entirely on BMCs that do not require remote firmware updates.
- Require multi-party approval and change-control tickets for any BMC firmware update action.
- Place BMC management interfaces behind a jump host that enforces session recording.
# Example: baseline and monitor the firmware trust anchor
sha256sum /conf/public.pem > /var/lib/bmc-baseline/public.pem.sha256
# Periodic integrity check
sha256sum -c /var/lib/bmc-baseline/public.pem.sha256 \
|| logger -p auth.alert "BMC trust anchor /conf/public.pem changed"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

