Master Lock's Bluetooth padlock uses AES encryption for communication between the app and the lock. AES is secure. The implementation is not.
The lock sends the same initial nonce every time a Bluetooth connection begins. Since the same nonce combined with the same key produces the same keystream, an attacker can record one legitimate unlock session and replay the entire sequence indefinitely. No brute force, no key extraction, no account compromise — just a recording.
Additional vulnerabilities compound the failure: expired guest access continues to work after revocation, temporary users can extend their own access indefinitely, and malformed Bluetooth packets cause memory corruption in the lock's firmware.
The AES primitive is correct. The protocol wrapping it is broken. The lock encrypts everything — and the encryption is meaningless because the nonce never changes. A strong cipher with a predictable nonce is a complicated way to have no lock at all.
Security is a property of protocols, not primitives. You cannot evaluate a system's security by checking whether its cryptographic algorithm is sound. The algorithm operates within a protocol, and the protocol operates within an implementation, and the vulnerability will be wherever you stopped looking. In this case, the developers verified the cipher and assumed the nonce handling was obvious. The nonce handling was obvious — obviously wrong.