broken authorization in Akia keyless entry lets an authenticated guest unlock other rooms

Finding

Found as a paying guest at a hotel using Akia's keyless-entry feature. While using the legitimate in-app door-unlock for my own room, I observed that the unlock action relied on a client-supplied room/door identifier that was not properly authorized server-side against the authenticated guest's booking.

Impact

Insecure Direct Object Reference / missing object-level authorization. An authenticated guest could unlock rooms other than their own, resulting in unauthorized physical access to guest rooms at an affected property.

I acted in good faith: I confirmed the flaw only to the point where the server accepted a modified request. I did not physically open, enter, or attempt to access any room other than my own, and I did not access, modify, or exfiltrate any data.

Patches

The vendor responded quickly and coordinated the disclosure. Akia deployed an interim configuration fix that removed the reliance on a client-supplied room number, closing off the exploitable exposure, and then rolled out a root-cause fix enforcing a proper server-side authorization check on the unlock action. The issue is remediated.

Workarounds

No longer required now that the vendor has remediated. Prior to the fix, the mitigation was to restrict or temporarily disable remote unlock until server-side authorization was enforced; where available, guests could also use mechanical/secondary door locks.

Timeline

• Reported to the vendor's published security contact on 7 September 2026.
• Vendor acknowledged and flagged to engineering.
• Interim configuration fix deployed by the vendor.
• Root-cause fix (server-side authorization on the unlock action) deployed.
• Coordinated public disclosure via CIRCL

References

Vendor security contact per their published security.txt (security@akia.com).