Software House iSTAR Ultra firmware verification and web application (tested through 6.9.2): The controller verifies

Impact

The controller verifies its firmware at boot, but the verification skips portions of the image - so an attacker who can push firmware gets persistent, boot-surviving code on the door controller that the device's own integrity check will happily bless. The companion issue is an authenticated OS command injection in the web application that escalates to root, which is a plausible way to reach the firmware write in the first place. This is the persistence problem in its purest form: you can re-image the panel, but if the attacker's implant is in the unverified region and you restore from a backup taken after compromise, it comes back. For a GPU operator the practical meaning is that door control - the boundary protecting drives, console ports and the OOB switch inside the cage - can be silently and durably owned, and no amount of log review will show it because the implant controls the logs. This is also a tenant-handoff failure: a panel compromised during one customer's tenancy stays compromised for the next one, since nobody re-flashes access-control hardware between tenants.

Who can reach it

The command-injection path requires an authenticated session to the iSTAR web application, so realistically credential theft, a default or shared integrator account, or chaining from one of the unauthenticated iSTAR issues. The firmware verification gap is then exercised by an attacker who already has that access. All of it lives on the physical-security VLAN.

What to do

Move to firmware later than 6.9.2 per Johnson Controls' guidance and confirm with the vendor that the verification gap is closed in the version you land on - the disclosure notes later firmware may also be affected, so a version number alone is not evidence. Because the flaw defeats integrity verification, patching is not sufficient for a panel you believe was reachable while vulnerable: replace it or have the vendor perform a full low-level reflash, and rebuild its configuration from a known-good source rather than a device backup. Operationally, rotate every credential on the access-control system, audit the account list for integrator and service accounts, and require MFA on any path to the iSTAR web application.

References

Related entries

• Riello NetMan 204: unauthenticated admin pages allow UPS shutdown and config disclosureCVE-2025-71318 · Riello UPS NetMan 204 network management card (admin pages and command endpoints)Critical
• Phala dcap-qvl - the Rust/npm/Python DCAP quote verification library used to verify Intel SGX and TDX attestationCVE-2026-22696 · Phala dcap-qvl - the Rust/npm/Python DCAP quote verification library used to verify Intel SGX and TDX attestation…Critical
• Voltronic Power SNMP Web Pro: unauthenticated firmware upload yields root on the UPS management cardCVE-2026-44402 · Voltronic Power SNMP Web Pro 1.1 (upload.cgi firmware update endpoint)Critical
• fakefish: KubeVirt backend ignores Redfish credentials, exposing VM power and virtual mediaCVE-2026-71566 · fakefish (Redfish BMC shim, KubeVirt backend)Critical
• Linux kernel (drivers/infiniband/hw/bnxt_re): A user context could request the write-combine doorbell page repeatedlyCVE-2026-72495 · Linux kernel (drivers/infiniband/hw/bnxt_re)Critical
• Phison PS3111-S11 SSD firmware: signature check trusts a modulus carried in the image, so any firmware verifiesCVE-2026-82876 · Phison PS3111-S11 SSD controller firmware (signature verification root of trust)Critical