CVE-2020-16630
TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an...
CVE-2020-16630 is a medium vulnerability (CVSS 6.8) in Ti 15.4-stack, published September 20, 2021. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.69%, the 53rd percentile. No source names a fixed version.
- Severity
- 6.8 MediumCVSS 3.1, NVD
- Exploit chance
- 0.69%EPSS, 53rd percentile
- Exploitation
- None knownNot on CISA’s or ENISA’s lists
- Fixed in
- No fix listedNo source names one
Description
TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile’s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission.
Attack profile
How easy it is to exploit
- Attack vector
- Adjacent network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Exploit likelihood
Affected products
What each source reports
NVD Score used
TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile’s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission.
- Record
CVE-2020-16630- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - CVSS 2.0
- 4.3 Medium
AV:A/AC:M/Au:N/C:P/I:P/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
CVE ListNo score
TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile’s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission.
- Record
CVE-2020-16630- Updated
- 2026-11-02
EUVDEUVD-2020-8591No score
TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile’s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission.
- Record
EUVD-2020-8591- Updated
- 2026-11-03
GitHub AdvisoriesGHSA-h5cr-94cg-hxmrNo score
TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an...
TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile’s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission.
- Record
GHSA-h5cr-94cg-hxmr- Weakness
- CWE-863
- Updated
- 2026-11-02
History
| Recorded | Changed | Sources |
|---|---|---|
| facts | ||
| aliases | EUVD | |
| first indexed | CVE List, GitHub Advisories, NVD |
Dates are when Every CVE recorded each change. Upstream dates may differ.