CVE-2026-65198

Executive Summary

CVE-2026-65198 is a hard-coded cryptographic key vulnerability (CWE-321) in Huawei's openUBMC firmware stack, where a single SNMPv3 USM key is used for both authentication and privacy across all shipped units. Any attacker who obtains the publicly recoverable key from the open-source build can authenticate to and decrypt SNMPv3 traffic from every unmodified device — access that maps to full administrative control, including system reset and firmware upgrade. All openUBMC-based iBMC deployments retaining factory defaults are affected, and no patch exists.

Technical Analysis

SNMPv3's User-based Security Model (USM) separates authentication from privacy: an authentication key (authKey) signs messages for integrity and origin verification, while a privacy key (privKey) encrypts payloads. Secure deployments derive these keys from a per-user passphrase via key localization (RFC 3414), producing unit-specific key material. CVE-2026-65198 violates this design in two compounding ways.

First, the same literal value is used for both the authentication key and the encryption key. Per the NVD description, the iBMC product build — via manifest/build/customization/default_password.lua — sets AuthenticationKey == EncryptionKey == 7df2f29369e3ac3245b2c9d46b67a0ecd055197e41808a34ef325db2f6422581. The community seed file account/manufacture/default_password.lua sets both to 7a2f5b86f20233ec7b7bef49643fbf34d86d0cbf6f1f8f5c52d4f30d4536938b.

Second, and more severely, these are shipped constants — not per-unit values generated at manufacture. Every device built from a given configuration carries identical key material. Because the keys are baked into the build definition rather than provisioned at runtime, they are not rotated during Administrator password reset, meaning the hard-coded material survives account provisioning and post-deployment credential hygiene. The constants are recoverable directly from the open-source repository, so no reverse engineering of a physical device is required to obtain them.

The architectural aggravating factor is privilege mapping: SNMP access on these devices is mapped to full device administration. Even where SNMP is nominally a monitoring interface, the affected platform grants it rights equivalent to administrative control, including system reset and firmware upgrade operations. A read/write SNMP principal is therefore not a low-impact monitoring identity but a full management identity. Combined, these properties reduce the exploitation barrier to knowledge of two public string constants.

Exploitation Scenarios

No public PoC or exploit code is available for this CVE. The following chain is inferred from the vulnerability class (hard-coded shared symmetric key) and the details given in the NVD description. No file paths, function names, or endpoints beyond those quoted in the description are asserted.

1. Reconnaissance / target identification. An attacker enumerates internet- or management-network-exposed SNMP services (UDP/161 by convention). Candidate targets are openUBMC-based iBMC units running an iBMC product build or a community seed build that still carries the shipped key. Because the keys are build constants, fingerprinting the product and build lineage — for example via publicly documented openUBMC build characteristics — is sufficient to predict which key applies; there is no need to test per-unit key material.

2. Triggering the flaw. The attacker extracts the relevant constant (7df2f2...2581 for the iBMC product build, 7a2f5b...938b for the community seed) from the open-source build definition. They then configure an SNMPv3 USM user using that single value as both authKey and privKey under the matching security level (authPriv), and send a standard SNMPv3 request. Since the device stores the same constant, USM authentication succeeds on the first attempt — no brute force or cryptography is involved. The shared auth/priv value means the attacker can both generate messages the device accepts and decrypt responses.

3. Decryption and interaction. With authPriv established, the attacker authenticates to the SNMP engine and decrypts SNMPv3 traffic received from the device using the identical key. This defeats the confidentiality protection USM is supposed to provide: any captured or solicited SNMPv3 response is readable. Where the platform exposes writable SNMP objects mapped to administrative functions, the attacker can issue configuration-changing requests through the same authenticated session.

4. Post-exploitation impact. Because SNMP access is mapped to full device administration, successful USM authentication yields administrative capability. The description explicitly identifies system reset and firmware upgrade as reachable privileges. From an attacker's standpoint this enables denial of service through device reset, persistent compromise via installation of modified or malicious firmware, and potential lateral movement or platform takeover where firmware control is used as a foothold.

Impact Assessment

The CVSS v3.1 base score is 8.6 (High) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L. The attack is network-reachable (AV:N) with low complexity (AC:L), requires no privileges (PR:N) and no user interaction (UI:N). Confidentiality is rated Low (C:L), reflecting exposure of SNMP traffic and device state rather than bulk data. Integrity is rated High (I:H) — the dominant factor — because authenticated administrative access permits firmware modification and configuration change. Availability is Low (A:L), consistent with reachable but not necessarily destructive device reset capability.

Blast radius is the critical concern. The key values are shipped constants rather than per-unit secrets, so compromise is not device-specific: one disclosed constant applies to every unit built from the same configuration. This creates a systemic exposure across fleets that retain factory defaults, including units where Administrator password resets have already been performed, since the SNMP keys are not rotated by those resets. The attacker population with access to the key is effectively unbounded, as the constants are recoverable from the open-source build itself.

Business impact includes unauthorized firmware manipulation on management controllers — components that typically sit beneath the operating system and are trusted by higher layers — meaning compromise may be invisible to host-based controls and survive OS reinstallation. Device resets can disrupt managed server infrastructure. Because EPSS has not yet been scored by FIRST.org and CVE-2026-65198 is not in the CISA KEV catalog, there is no evidence of observed exploitation in the wild as of this writing; however, absence of exploitation evidence reflects only the absence of reporting, and the preconditions for trivial exploitation are fully met.

Detection Guidance

Sigma Rule

title: SNMPv3 USM Authentication Using Known Hard-Coded openUBMC Default Key
id: 8f2c1a44-6519-4eae-9d3b-7c6519800001
status: experimental
description: Detects SNMP traps or management-plane log entries indicating SNMPv3 requests authenticated against the shipped openUBMC default USM key (CVE-2026-65198).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-65198
author: valtersit.com Threat Intelligence
date: 2026/01/01
logsource:
  product: bmc
  service: snmp
detection:
  selection_source:
    src_ip|cidr:
      - '0.0.0.0/0'
  selection_indicators:
    message|contains:
      - 'default_password'
      - 'AuthenticationKey'
      - 'EncryptionKey'
      - 'usmUser'
  selection_key_material:
    message|contains:
      - '7df2f29369e3ac3245b2c9d46b67a0ecd055197e41808a34ef325db2f6422581'
      - '7a2f5b86f20233ec7b7bef49643fbf34d86d0cbf6f1f8f5c52d4f30d4536938b'
  condition: selection_indicators or selection_key_material
falsepositives:
  - Legitimate administration using non-default USM credentials
  - Build or provisioning scripts that reference default_password.lua by design
level: high
tags:
  - attack.valid_accounts
  - attack.t1078
  - cve.2026.65198

YARA Rule

rule CVE_2026_65198_openUBMC_Default_SNMPv3_USM_Key
{
    meta:
        description = "Detects hard-coded openUBMC SNMPv3 USM default keys assigned to both AuthenticationKey and EncryptionKey (CVE-2026-65198)"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-65198"
        date = "2026-01-01"
        severity = "high"

    strings:
        $k1 = "7df2f29369e3ac3245b2c9d46b67a0ecd055197e41808a34ef325db2f6422581" ascii wide nocase
        $k2 = "7a2f5b86f20233ec7b7bef49643fbf34d86d0cbf6f1f8f5c52d4f30d4536938b" ascii wide nocase
        $f1 = "default_password.lua" ascii wide
        $p1 = "manifest/build/customization/default_password.lua" ascii wide
        $p2 = "account/manufacture/default_password.lua" ascii wide
        $a1 = "AuthenticationKey" ascii
        $a2 = "EncryptionKey" ascii

    condition:
        ($k1 or $k2) or (any of ($p*)) or ($f1 and $a1 and $a2)
}

Suricata IDS Rule

alert udp any any -> any 161 ( \
  msg:"CVE-2026-65198 openUBMC Hard-Coded SNMPv3 USM Key Authentication Attempt"; \
  flow:to_server; \
  content:"|30|"; offset:0; depth:1; \
  content:"|04|"; \
  byte_test:1,>,2,0; \
  threshold:type limit, track by_src, count 10, seconds 60; \
  reference:cve,2026-65198; \
  reference:url,nvd.nist.gov/vuln/detail/CVE-2026-65198; \
  classtype:attempted-admin; \
  sid:90065198; rev:1; )

alert udp any any -> any 162 ( \
  msg:"CVE-2026-65198 openUBMC SNMPv3 Trap Using Known Default USM Key"; \
  flow:to_server; \
  content:"|30|"; offset:0; depth:1; \
  threshold:type limit, track by_src, count 10, seconds 60; \
  reference:cve,2026-65198; \
  classtype:attempted-admin; \
  sid:90065199; rev:1; )

Elastic Detection

sequence by host.id with maxspan=5m
  [network where network.transport == "udp" and destination.port == 161 and event.action == "network_flow"]
  [process where event.type == "start" and
    process.args : ("*snmpwalk*", "*snmpget*", "*snmpbulkwalk*") and
    process.command_line : ("*authPriv*", "*SHA*", "*AES*")]

Splunk SPL Query

index=network sourcetype=snmp:traffic OR sourcetype=firewall
| where match(lower(_raw), "(snmpv3|usm|authpriv|default_password\.lua)")
| where match(lower(_raw), "(7df2f29369e3ac3245b2c9d46b67a0ecd055197e41808a34ef325db2f6422581|7a2f5b86f20233ec7b7bef49643fbf34d86d0cbf6f1f8f5c52d4f30d4536938b)")
    OR (dest_port=161 OR dest_port=162)
| stats count min(_time) as first_seen max(_time) as last_seen
        values(dest_ip) as target_bmc values(src_ip) as source_ip
  by host
| where count > 5
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="bmc,snmp,cve-2026-65198,">
  <rule id="100651" level="12">
    <decoded_as>snmp</decoded_as>
    <match>AuthenticationKey|EncryptionKey|default_password</match>
    <description>CVE-2026-65198: openUBMC SNMPv3 USM default hard-coded key referenced or used</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>cve_2026_65198,attempted_admin,</group>
  </rule>

  <rule id="100652" level="13">
    <if_sid>100651</if_sid>
    <regex>7df2f29369e3ac3245b2c9d46b67a0ecd055197e41808a34ef325db2f6422581|7a2f5b86f20233ec7b7bef49643fbf34d86d0cbf6f1f8f5c52d4f30d4536938b</regex>
    <description>CVE-2026-65198: Known shipped openUBMC SNMPv3 USM default key observed in event</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>cve_2026_65198,critical,</group>
  </rule>

  <rule id="100653" level="10" frequency="10" timeframe="60">
    <if_matched_sid>100651</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-65198: Repeated SNMPv3 default-key activity from same source (possible exploitation attempt)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>cve_2026_65198,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, affected-version enumeration, or workaround has been identified through any tracked source. The following measures are compensating controls, not vendor-sanctioned remediation.

1. Immediate mitigations. Remove or disable SNMP on all openUBMC-based iBMC units where it is not strictly required. Where SNMP must remain enabled, restrict UDP/161 and UDP/162 to a hardened, tightly scoped management VLAN and enforce host-level ACLs so that only authorized management hosts can reach the SNMP engine. Detect and alert on any SNMPv3 session authenticating with the shipped constants using the detection content above. Treat every device that has ever carried the default build key as potentially compromised until the key is rotated or the device is rebuilt, since the description confirms the key survives Administrator password resets.

2. Patch/upgrade steps. No patch is available. Monitor the NVD entry for CVE-2026-65198 and Huawei/openUBMC project advisories for a fixed firmware release. Where the platform permits administratively provisioning SNMPv3 USM users, override the build default: create a new USM principal with unique, per-unit key material for both authentication and privacy, then delete or disable the default principal. Do not rely on Administrator password reset to remove the shipped key. Confirm after any firmware upgrade that the hard-coded constant has been removed from the build configuration, not merely shadowed.

3. Long-term hardening. Eliminate hard-coded symmetric keys from build and manufacturing pipelines: generate per-unit key material at provisioning time and never commit secrets to build-customization or manufacture seed files. Separate authentication and privacy keys, and treat authKey/privKey equality as a configuration defect. Enforce least privilege on management protocols so SNMP is never mapped to full administrative capability. Rotate all symmetric keys — not just passwords — as part of credential lifecycle management, and add static-analysis checks in CI to fail builds containing literal key material. Validate the open-source supply chain so shipped constants are auditable and remediable.

References

• NVD — CVE-2026-65198: https://nvd.nist.gov/vuln/detail/CVE-2026-65198
• CWE-321: Use of Hard-coded Cryptographic Key: https://cwe.mitre.org/data/definitions/321.html
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/
• Huawei openUBMC project repository (build customization and community seed definitions referenced in the NVD description).
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-65198 not listed; no exploit-in-the-wild evidence as of this writing).