TTLock EUVD-2026-109945

Exploitation requires BLE (Bluetooth Low Energy) proximity to the target lock and the ability to observe a pairing exchange between the TTLock Android app (versions before v9.8.260718) and the associated smart-lock firmware; the attacker then recovers the persistent session key using the embedded static AES defaultKey. No authentication, credentials, or user interaction are needed (PR:N/UI:N). The principal limiting factor is physical proximity - the attacker must be within Bluetooth range (AV:A), so this cannot be performed remotely over the internet - and must capture the pairing handshake. Remediation is upgrading the app to v9.8.260718 or later (and the associated firmware); the trigger for how/whether the pairing exchange can be forced to re-occur is not described in the available sources.

This is a genuine high-priority issue for the affected product class, though its risk is bounded by proximity rather than internet reach. The CVSS 4.0 vector (AV:A/AC:L/PR:N/UI:N, VC:H/VI:H/VA:N, score 8.6) describes an adjacent-network (Bluetooth-range) attack requiring no authentication and no user interaction, with high confidentiality and integrity impact and no availability impact - consistent with a hardcoded-key design flaw (CWE-321) that reliably yields the session key once the pairing exchange is observed. The vuln.today decision label is 'this_week', indicating elevated but not emergency urgency. Signals are partly incomplete: there is no CISA KEV listing and no EPSS score in the input, so widespread automated exploitation is not evidenced; a public PoC reference exists but it is not verified as working exploit code. The key tension is reach versus impact - AV:A means an attacker must be physically within Bluetooth range of each target lock, which makes this unsuitable for mass remote exploitation but highly impactful for targeted physical-access attacks (the end result is unlocking a door and adding persistent credentials). No EPSS/KEV data should be read as 'low risk' here; absence of those signals is simply missing data, not a negative finding.

An attacker positions within Bluetooth range of a TTLock-equipped door (e.g., a shared hallway or outside an apartment) and passively captures the BLE pairing exchange between the lock and the mobile app. Using the hardcoded static AES defaultKey embedded in the vulnerable app/firmware, they decrypt and recover the persistent per-pairing session key, then forge authenticated BLE commands to unlock the device and enroll their own fingerprint or access code. A public PoC reference exists but it is not verified as working exploit code; the low attack complexity and lack of any authentication or user interaction make the scenario realistic for a proximate attacker.