openUBMC: SNMP pseudo-user is granted the full privilege set, so a low-privilege SNMP caller acts as admin

CVSS 5.4CVE-2026-65199Firmware, BMC & network fabriccurated

Impact

get_user_privilege in route_mapper/account.lua returns the complete nine-privilege set for the special_users group, which includes the SNMPv1_v2c pseudo-identity. An authenticated but deliberately low-privilege SNMP user therefore invokes mapped backend operations as an administrative identity on the BMC. BMC accounts are routinely handed out read-only so that monitoring can poll inventory and sensors without being able to change anything; this collapses that boundary. On a GPU fleet the BMC is the out-of-band path to power control and host firmware, and SNMP community strings tend to be shared across a whole rack, so the blast radius is every node polled with the same string. The advisory describes integrity and availability impact rather than a full takeover.

Who can reach it

Any SNMP caller on the management network that knows the community string or SNMP credentials - typically the monitoring VLAN. Authentication is required, but only at the lowest privilege level the BMC offers.

What to do

Update openUBMC firmware once Huawei publishes a fixed build; the record does not name a fixed version, so until it does the mitigation is to stop relying on SNMP privilege separation: disable the SNMP service on the BMC where it is not needed, and keep BMC SNMP strictly on an isolated management VLAN reachable only from the monitoring hosts. A firmware update means flashing the BMC, which is possible with the host running on most platforms but should still be staged per rack.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-65199 https://www.runzero.com/advisories/huawei-openUBMC-snmp-privsec-cve-2026-65199

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.