TTLock Android App < 9.8.260718 Hardcoded BLE Pairing Key Exposure
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 9.8.260718
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: no
- Technical impact: total
Summary
The TTLock Android app (versions before the 9.8.260718 release) and the smart-lock firmware it pairs with are affected. An attacker within Bluetooth range could exploit the hardcoded encryption key to take control of a lock, including unlocking it, adding fingerprints or access codes, and performing administrative actions without any authentication.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
TTLock Android application before v9.8.260718 and associated smart-lock firmware contain a hardcoded static AES key vulnerability that allows an attacker within Bluetooth range to decrypt the per-pairing session key transmitted during BLE pairing. Attackers can observe the pairing exchange, recover the persistent session key using the embedded defaultKey, and forge authenticated BLE requests to unlock the device, add fingerprints or access codes, and perform administrative actions without authentication or user interaction.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: poc · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Sciener TTLock
fixed in 9.8.260718