CVE-2026-65198 in openUBMC
Summary
by MITRE • 10/13/2026
Huawei's openUBMC ships a default SNMPv3 USM key that uses one value for both authentication and privacy. An attacker who holds the key (recoverable from the open-source build) can authenticate SNMPv3 to, and decrypt SNMPv3 traffic from, any unit that still carries the shipped key. The build customization `manifest/build/customization/default_password.lua` sets `AuthenticationKey == EncryptionKey == 7df2f29369e3ac3245b2c9d46b67a0ecd055197e41808a34ef325db2f6422581` for the iBMC product build, and the community seed `account/manufacture/default_password.lua` sets both to `7a2f5b86f20233ec7b7bef49643fbf34d86d0cbf6f1f8f5c52d4f30d4536938b`. These are shipped constants, not per-unit values, and they are not rotated by the Administrator password reset, so they survive account provisioning. This is especially dangerous considering that SNMP access is mapped to full device administration privileges, including system reset and firmware upgrades.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability in Huawei's openUBMC platform represents a critical failure in cryptographic key management and default credential hygiene, specifically within the Simple Network Management Protocol version 3 implementation. The core technical flaw lies in the configuration of the User-based Security Model (USM) keys for SNMPv3 services. In a secure deployment, authentication and privacy keys should be distinct to ensure that compromising one does not automatically compromise the other. However, openUBMC ships with hardcoded constants where the AuthenticationKey is identical to the EncryptionKey. This design choice eliminates any security benefit from having separate key spaces and simplifies the attack surface significantly for an adversary who obtains these static values.
The severity of this vulnerability is compounded by the fact that these cryptographic keys are not unique per device instance but are instead baked into the firmware build process through specific configuration manifests. The file manifest/build/customization/default_password.lua sets a fixed SHA-1 hash value for both authentication and encryption, while account/manufacture/default_password.lua defines another static constant for community seeds. Because these values are compiled directly into the binary or configuration files during the manufacturing phase, they remain identical across all units produced with that specific build version. This lack of per-unit entropy means that a single compromised key can be used to target any device running the affected firmware variant without requiring further reconnaissance or exploitation steps to discover unique identifiers.
Furthermore, these default keys exhibit extreme persistence within the system's lifecycle management. They are not rotated during standard administrative operations such as password resets for user accounts. This architectural oversight ensures that even if an administrator changes their login credentials, the underlying SNMPv3 service continues to operate with the original, predictable cryptographic material. Consequently, any entity capable of accessing the open-source build repository or extracting these constants from a single compromised device can immediately authenticate and decrypt traffic on all other devices sharing the same firmware baseline. This persistence transforms what might otherwise be a transient configuration error into a long-term, widespread exposure vector that persists until manual intervention reconfigures the SNMP service with unique keys.
The operational impact of this vulnerability is severe due to the privilege escalation inherent in the SNMPv3 access model within openUBMC. Accessing the management interface via SNMPv3 using these default credentials grants the attacker full device administration privileges rather than limited monitoring rights. This elevated level of trust allows an authenticated actor to execute critical system commands, including initiating hard resets that cause service denial for legitimate users and uploading malicious firmware images that can establish persistent backdoors or compromise the underlying hardware integrity. The ability to decrypt SNMPv3 traffic also enables passive eavesdropping on management communications, potentially revealing sensitive network topology information, configuration details, and operational status data that should remain confidential.
From a classification perspective, this vulnerability aligns with CWE-798: Use of Hard-coded Credentials, as it involves the use of static passwords or keys in code for authentication purposes. It also relates to CWE-326: Inadequate Encryption Strength, given the reliance on predictable key material that fails to provide confidentiality against determined attackers. Additionally, the exploitation path maps directly to MITRE ATT&CK technique T1078: Valid Accounts, where adversaries leverage legitimate credentials to access resources without needing to exploit a software flaw in the traditional sense. The ability to decrypt traffic further implicates CWE-319: Cleartext Transmission of Sensitive Information if such traffic is intercepted over unencrypted channels like UDP.
Mitigation strategies must focus on immediate remediation and long-term architectural changes. Administrators should immediately disable SNMPv3 services that are not strictly necessary for network monitoring, or restrict access to trusted management stations using strict firewall rules and IP whitelisting. If SNMPv3 remains enabled, it is imperative to generate unique, strong cryptographic keys for both authentication and privacy purposes on each individual device, ensuring they differ from one another and do not match any known default values. Organizations should also implement regular audits of configuration files to detect hardcoded credentials during the build process. Finally, Huawei must address this at the source by implementing per-unit key generation during manufacturing and ensuring that administrative password resets trigger a rotation or regeneration of associated service keys to prevent credential persistence across lifecycle events.