Database/Control plane, storage & DevOps
Software House iSTAR Ultra, Ultra LT, Ultra G2 and Edge G2 door controllers: An unauthenticated user can log
Impact
An unauthenticated user can log into the controller with administrator rights. No exploitation, no chain - just log in as admin on the panel that governs the doors into the hall and the cages inside it. Administrator on an iSTAR panel means unlocking doors, enrolling credentials, changing door schedules, and editing or clearing the local event log so the entry leaves no record. Whoever walks in can pull drives containing model weights and customer data, attach a console to a running node, plug into the out-of-band management switch and reach every BMC in the row, or leave a hardware implant behind. For a bare-metal GPU provider this is a direct breach of the physical isolation guarantee sold to tenants, and because the log can be cleared from the same session, you may never be able to prove it did or did not happen. This is the fourth distinct critical or high finding on the iSTAR platform in this database's window, which is itself the finding: treat the platform as needing continuous advisory tracking rather than set-and-forget.
Who can reach it
Unauthenticated network access to the controller on the physical-security VLAN. Nothing else is required. That VLAN typically also carries CCTV, intercom and the security integrator's remote-support path, any of which is a route in from a wider network.
What to do
Firmware update per Johnson Controls' advisory for each affected iSTAR model - a security-integrator engagement with doors in local fallback during the flash, so it needs staff at affected doors for the window. Because the flaw grants administrator without authentication, assume any panel reachable during the exposure window may have had credentials added or the event log cleared: audit the panel's credential list and the head-end's cardholder database against a known-good baseline after patching. Structurally, put the physical-security VLAN behind a firewall with an explicit allow-list from the head-end only, and stop treating that VLAN as trusted because it is 'the security network'.
References
Related entries
- AMD Radeon Graphics display driver - input validation: Improper input validation in the Radeon display driver letsCVE-2023-31320 · AMD Radeon Graphics display driver - input validationHigh
- ZKTeco BioTime v8.5.5 (iclock API path traversal): Unauthenticated arbitrary file read on the BioTime serverCVE-2023-38950 · ZKTeco BioTime v8.5.5 (iclock API path traversal)High
- KNX devices using KNX Connection Authorization Option 1 (BCU key): An attacker sets the BCU key on KNX devicesCVE-2023-4346 · KNX devices using KNX Connection Authorization Option 1 (BCU key)High
- Johnson Controls Metasys NAE55 / SNE / SNC network engines and Facility Explorer F4-SNC (before 11.0.6 / 12.0.4)CVE-2023-4486 · Johnson Controls Metasys NAE55 / SNE / SNC network engines and Facility Explorer F4-SNC (before 11.0.6 / 12.0.4)High
- OpenZFS: Block-cloning path can replace file contents with zero bytes, potentially disabling security mechanismsCVE-2023-49298 · OpenZFSHigh
- Slurm (NULL pointer dereference in RPC handling): A crafted message crashes the Slurm daemon. On slurmctld that stallsCVE-2023-49936 · Slurm (NULL pointer dereference in RPC handling)High
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.