Database/Control plane, storage & DevOps
ZKTeco BioAccess IVS v3.3.1 access control platform: An unauthenticated attacker can open and close any door
Impact
An unauthenticated attacker can open and close any door the platform manages by sending a crafted web request. The CVSS score badly understates this: a 5.3 labelled 'access control issue' is, in the physical world, a remote door-open primitive with no credentials. The same disclosure set adds unauthenticated device enumeration (IP addresses and names of every reader and controller), unauthenticated path traversal for arbitrary file read, and SQL injection - so the attacker can map the site, find the door serving the GPU cage specifically, and then open it. ZKTeco gear is common in cost-sensitive and fast-built deployments, which describes a lot of newer GPU hosting sites, and it is often installed by a general contractor rather than a security integrator. What follows from an open cage door is the usual list: drives with model weights and customer data walk out, a console or USB device gets attached to a running node, or someone plugs into the out-of-band switch and reaches every BMC in the row.
Who can reach it
Unauthenticated HTTP request to the BioAccess IVS platform. It is a web-managed server; where it is reachable from the corporate network or, worse, published for remote administration, the attack is a single request from anywhere. Device enumeration first means the attacker does not need prior knowledge of your site layout.
What to do
Upgrade past 3.3.1 to a fixed BioAccess IVS release - ZKTeco's patch cadence and advisory quality are weak, so verify with the vendor that the specific door-control endpoint is fixed rather than trusting a version bump. Given the vendor track record, the stronger recommendation for a datacenter is to treat this product as unsuitable for a hall or cage boundary and plan replacement with a platform that has a real security program. Meanwhile: take the platform entirely off any network reachable from outside the security VLAN, put it behind a jump host, and add a compensating physical control on the doors that actually matter - a mechanical lock, a mantrap with a second independent system, or a guard - because a remote unlock primitive with no authentication is not something a network ACL fully mitigates if the ACL is ever wrong.
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.