GPU VulnDB

Database/Firmware, BMC & network fabric

Linuxfabrik monitoring-plugins: redfish checks follow BMC-supplied @odata.id links and leak credentials

CVSS 8.3CVE-2026-67436Firmware, BMC & network fabriccurated

Impact

The redfish-* plugins built request URLs by concatenating the operator-supplied base URL with @odata.id links taken from the BMC's own responses, so a malicious or already-compromised BMC can point the next authenticated request anywhere and collect the X-Auth-Token or HTTP Basic credential the monitoring host sends. In a datacenter that credential is almost never per-chassis: the same Redfish service account is pushed to every BMC in the fleet, so one tampered or compromised node yields management-plane access to the rest - power control, virtual media, firmware update, serial-over-LAN. Monitoring hosts also poll continuously, so the attacker does not need to win a race. Affects 6.0.0 and earlier.

Who can reach it

Requires control of a BMC that the monitoring host polls, or a position to tamper with its Redfish responses - typically someone already on the management VLAN or holding one BMC. No authentication to the monitoring host itself is needed; the plugin brings the credential to the attacker.

What to do

Update the monitoring-plugins package to a release containing commit ffb0a813 (the fix stops trusting response-supplied links) and the next check cycle picks it up - no restart of the Icinga or Nagios daemon beyond the normal package update. Then rotate the Redfish monitoring credential on every BMC, because the advisory does not establish whether it was already taken; if the fleet shares one account, that rotation is the real work. Keep the BMC network on its own VLAN reachable only from the monitoring host.

References

Related entries

All Firmware, BMC & network fabric entries

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.