Database/Firmware, BMC & network fabric

Rittal IoT Interface and CMC III Processing Unit - firmware upgrade signature check: The admin web interface verifies
Impact
The admin web interface verifies patch files with an HMAC-style check whose key is a long string hard-coded in the firmware - and the firmware is freely downloadable, so anyone can extract the key and sign their own malicious update. That is a complete bypass of firmware integrity on the device that monitors cabinet temperature, humidity, door state, smoke and access for a rack or a row. An attacker who lands code there gets persistence on facility hardware nobody re-images, the ability to falsify environmental telemetry so a real thermal excursion in a GPU row never raises an alarm, and control of whatever access and door outputs the CMC III drives. The falsified-telemetry angle is the one operators underestimate: your temperature monitoring is the thing that is supposed to tell you a cooling attack is underway, and this lets the attacker turn it into a liar while the racks cook. The IoT Interface variant is a general-purpose gateway, so the same implant is a pivot point onto the facility network.
Who can reach it
Access to the admin web interface to upload the crafted patch - so an authenticated or otherwise-reachable path to the device on the facility VLAN. CMC III processing units and IoT Interfaces are typically on the monitoring network alongside PDU cards and environmental sensors, reachable from the DCIM collector and often from anything else on that segment. Given the same product family's history of backdoor accounts and injection flaws, reaching the admin interface is not a high bar.
What to do
Rittal firmware update - a small device, quick flash, no cooling impact, so this is one of the more tractable items on this list. Do it across every CMC III processing unit and IoT Interface, and note that the fleet count in a large hall is per-row or per-cabinet, so it is a technician-day of work rather than a single change. Because the flaw defeats firmware integrity, any unit you believe was reachable by an untrusted host should be re-flashed from vendor media rather than trusted after an in-place update. Then isolate: monitoring devices on their own VLAN, admin interfaces reachable only from a jump host, and no route from tenant or corporate networks.
References
Related entries
- AMI MegaRAC SPx (Redfish Host Interface): Unauthenticated auth bypass, full BMC takeover, malicious firmware flash.CVE-2024-54085 · AMI MegaRAC SPx (Redfish Host Interface)Critical
- Linux bnxt_en driver (5760X / P7 aggregation ID mask): The bnxt_en driver mishandles the aggregation ID mask on 5760XCVE-2024-56656 · Linux bnxt_en driver (5760X / P7 aggregation ID mask)Critical
- Linux kernel (drivers/infiniband/hw/bnxt_re): The driver advertises support for 13 scatter-gather entries per workCVE-2024-57936 · Linux kernel (drivers/infiniband/hw/bnxt_re)Critical
- Linux kernel (drivers/infiniband/ulp/rtrs): A remote client corrupts kernel linked lists on the RDMA block-storageCVE-2025-21805 · Linux kernel (drivers/infiniband/ulp/rtrs)Critical
- Linux kernel (drivers/infiniband/hw/erdma): Use-after-free while accepting an inbound RDMA connection. The connectionCVE-2025-22088 · Linux kernel (drivers/infiniband/hw/erdma)Critical
- Linux kernel (drivers/infiniband/core): The iWARP connection manager frees the work objects it is currently executingCVE-2025-38211 · Linux kernel (drivers/infiniband/core)Critical
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.