BLE Vulnerabilities: Known Attacks and Mitigations
SweynTooth, KNOB, BLESA, and other BLE security issues
BLE Vulnerabilities: Known Attacks and Mitigations
Bluetooth Low Energy has accumulated a significant vulnerability history since Bluetooth 4.0. Most critical vulnerabilities exploit weaknesses in pairing, key exchange, or feature negotiation rather than the underlying cryptography. This guide catalogs major vulnerabilities with affected versions, CVEs, and mitigations.
SweynTooth (2020)
Affected: 11 BLE SoCs from 7 vendors (Texas Instruments CC2640R2, NXP KW41Z, Dialog DA14580, Microchip ATSAMB11, STMicro BluNRG-1, Telink TLSR8266, Cypress CYW20719, and others)
CVEs: CVE-2019-17519, CVE-2019-17517, CVE-2019-17518 (11 CVEs total)
Vulnerability class: L2CAP and LL state machine bugs — invalid sequence numbers, zero-length PDUs, and unexpected ATT opcodes cause crashes, deadlocks, or arbitrary code execution
| CVE | Vulnerability | Impact |
|---|---|---|
| CVE-2019-17519 | LL_LENGTH_REQ with invalid Payload Length | DoS — device crash |
| CVE-2019-17517 | L2CAP invalid channel ID | DoS — link layer deadlock |
| CVE-2019-17520 | Truncated ATT opcode | RCE on some targets |
| CVE-2020-10061 | Zephyr RTOS SMP OOB write | RCE — CVE separate from SweynTooth |
Mitigation: Firmware patches released by all affected vendors. Verify SoC SDK version against vendor security advisories. All post-2020 silicon has hardware fixes.
KNOB Attack (2019) — Key Negotiation of Bluetooth
CVE: CVE-2019-9506
Affected: Bluetooth Classic BR/EDR and BLE (Bluetooth 4.x–5.1 for BR/EDR; BLE uses different key derivation but similar negotiation)
Vulnerability: The entropy of the session key can be reduced to 1 byte by a MITM attacker manipulating the LMP_encryption_key_size_req exchange. Brute-forcing a 1-byte key takes milliseconds.
BLE-specific: BLE uses a different key exchange via SMP LE Secure Connections. KNOB does not apply to LESC (which uses ECDH). pairing/" class="glossary-term-link" data-term="Legacy pairing" data-definition="Original BLE pairing (pre-4.2), now deprecated." data-category="Security">Legacy pairing (LE Legacy) is vulnerable to related key entropy reduction.
Mitigation: - Enable LE Secure Connections — immune to KNOB - Reject connections negotiating key entropy < 7 bytes - Bluetooth Core Spec 5.1+ mandates minimum 7-byte key size
BLESA (2020) — BLE Spoofing Attack
CVE: CVE-2020-9770 (iOS), CVE-2020-10556 (others)
Affected: iOS, Android, Linux BlueZ, Windows — reconnection handling
Vulnerability: After a connection drop, a peripheral reconnects without re-authentication in many implementations. An attacker impersonates the legitimate peripheral during reconnection, feeding spoofed data to the central.
Attack flow:
1. Legitimate peripheral connects to central (phone)
2. Attacker forces disconnect (deauth)
3. Attacker advertises with same [GATT](/glossary/gatt/) services as legitimate peripheral
4. Central (phone app) reconnects to attacker without re-pairing
5. Attacker sends malicious sensor readings
Mitigation: - Require re-authentication (LTK re-encryption check) on every reconnection - Central must verify bonding LTK during reconnect, not just accept any peripheral with matching name - Patched in iOS 13.4.1 (CVE-2020-9770), Android Security Bulletin 2020-05
BLURtooth (2020)
CVEs: CVE-2020-15802
Affected: Devices with both Classic Bluetooth and BLE (dual-mode) implementing CTKD (Cross-Transport Key Derivation)
Vulnerability: CTKD derives a new key on one transport (BLE) and overwrites the existing authenticated key on the other transport (Classic). An attacker with a lower-security BLE connection can overwrite a high-security Classic key.
Mitigation: - Bluetooth Core Spec 5.3 restricts CTKD: keys can only be overwritten with equal or higher security - Firmware patches available; some devices require hardware replacement
BIAS (2020) — Bluetooth Impersonation Attacks
CVE: CVE-2020-10135
Affected: All Bluetooth Classic BR/EDR (BLE secondary impact via dual-mode)
Vulnerability: Authentication procedure asymmetry — a slave can authenticate without completing the full mutual authentication challenge, allowing impersonation
BLE relevance: Less direct, but dual-mode devices sharing identity keys are at risk
Vulnerability Mitigation Summary
| Mitigation | Addresses |
|---|---|
| Always use LE Secure Connections | KNOB, legacy pairing attacks |
| Re-authenticate on every reconnect | BLESA |
| Disable CTKD or update to BT 5.3+ | BLURtooth |
| Patch SoC firmware (SweynTooth) | SweynTooth crashes/RCE |
| Use address randomization | Tracking, MITM setup prevention |
| Enforce minimum key entropy (7+ bytes) | KNOB |
For implementation of LESC and MITM protection, see BLE MITM Prevention. For signing firmware to prevent malicious OTA, see Secure BLE DFU.
Frequently Asked Questions
Yes, our guides range from beginner introductions to advanced topics. Each guide indicates its difficulty level and prerequisites so you can find the right starting point.