fwupd's Redfish plugin: Any unprivileged local user on the host can read a working BMC credential out of a config file

Impact

Any unprivileged local user on the host can read a working BMC credential out of a config file. That is a direct escalation from 'has a shell on the node' to 'has an account on the node's out-of-band controller', which is the boundary a bare-metal operator is selling. From there the attacker reaches the BMC's Redfish surface with a legitimate operator account and can chain into any of the authenticated BMC bugs elsewhere in this list. If your provisioning tooling deploys fwupd with the Redfish plugin across the fleet, the same class of credential is sitting on every node. When it creates an OPERATOR account on the BMC, it writes the auto-generated password into /etc/fwupd/redfish.conf without restricting the file's permissions, leaving BMC credentials world-readable on the host.

Who can reach it

Any local unprivileged account on a host running fwupd with the Redfish plugin enabled. No root, no network position on the management VLAN, no exploit - just file read. On rented bare metal, the tenant is that local account.

What to do

Update fwupd to a version carrying the permissions fix. Because the credential has already been written in the clear on existing installs, updating the package is not sufficient: you must also rotate the BMC operator account fwupd created on every affected node, and check the permissions of /etc/fwupd/redfish.conf directly rather than trusting the package version. This is config-and-credential work rather than a firmware flash, so it is cheap to remediate but easy to leave half-done.

References