Software House iSTAR Ultra door controller (before 6.8.9.CU01): Unauthenticated command injection giving root

Impact

Unauthenticated command injection giving root on the door controller. The iSTAR Ultra is the panel that decides whether a door opens - including the doors into the datacenter hall and the cages inside it. Root on it means an attacker unlocks doors on demand, holds them unlocked, enrols their own credentials, and deletes or rewrites the access log so no record of the entry exists. What someone standing inside your cage can then do is the real impact: pull NVMe drives holding customer data and model weights, attach a laptop to a server's console or management port, plug into the out-of-band switch and reach every BMC in the row, install an interposer on a management link, or simply photograph the topology. For a bare-metal GPU provider that is also a tenant-handoff catastrophe - the boundary you sell your customers is precisely that nobody else can physically touch their machines, and this bug removes it silently. Root persistence on the controller means the compromise survives your incident response unless you re-image the panel.

Who can reach it

Unauthenticated, over the network, to the controller. iSTAR panels are typically on a dedicated physical-security VLAN, which sounds reassuring until you check who else is on it: the CCTV/VMS servers, the intercom system, the badge-office workstations, and the security integrator's remote-support path. Any of those is a stepping stone. Panels are also often mounted in unsecured back-of-house spaces, so physical access to the panel's Ethernet port is a parallel route.

What to do

Firmware update to 6.8.9.CU01 or later, applied through the Software House/Johnson Controls integrator. Door controller firmware updates are disruptive in a specific way most operators underestimate: doors typically fall back to a fail-secure or fail-safe local mode during the flash, so you need security staff physically present at affected doors for the window. Plan it, do not skip it - a 10.0 on the panel guarding your GPUs is not something to defer. After patching, re-image rather than trust any panel you suspect was reachable while vulnerable, rotate the integrator's credentials, and put the physical-security VLAN behind a firewall with an explicit allow-list rather than treating it as inherently trusted.

References