Database/Firmware, BMC & network fabric
Software House iSTAR door controllers (firmware before 6.6.B) and the IP-ACM Ethernet Door Module link: The iSTAR
Impact
The iSTAR controllers do not support authenticated communications with the iSTAR Configuration Utility, and the older IP-ACM door-module link used a fixed AES key and a fixed IV restarted on every message - which leaks enough structure that door-unlock commands can be replayed or forged outright. Both bugs land in the same place: the wire between the controller and its door hardware or configuration tool is not trustworthy, so an attacker on that network can open doors without ever authenticating to anything. Standing in the hall or the cage, that person reaches drives, console ports, the out-of-band management switch and the physical console of machines running customer workloads. For a multi-tenant GPU operator this collapses the cage boundary that the whole bare-metal isolation story rests on, and it does so without generating a failed-authentication event anywhere, because there is no authentication to fail.
Who can reach it
A host on the physical-security network that can see traffic between the iSTAR controller and the IP-ACM modules or the configuration utility. That means passive capture and replay, or active injection, from the security VLAN - typically shared with CCTV and the integrator's tooling. Physical access to structured cabling in a back-of-house space is an equally valid vector and is not covered by most tenants' security policies because the cabling is the landlord's.
What to do
Update iSTAR controller firmware to 6.6.B or later, which introduces authenticated ICU communications, and retire the affected IP-ACM generation in favour of the IP-ACM v2 hardware that supports proper encryption. That is firmware plus a hardware refresh of the door modules - a capital project with a security integrator and per-door downtime, not a patch. Until it is done: physically secure every cable run and panel between the controller and the door modules, put the physical-security VLAN behind a firewall with an allow-list, and enable 802.1X or port security on the switch ports serving door hardware so a rogue device cannot join the segment. Treat any hall where door-module cabling runs through space you do not control as a hall with a broken cage boundary.
References
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.