Bluetooth Low Energy (BLE) security for IoT devices: why pairing and open GATT are still the real risk

No — this guide found no CISA advisory, CVE or academic paper claiming BLE's AES-CCM link-layer encryption itself has been broken. NIST SP 800-121 Revision 2 describes LE Security Mode 1 Level 4 (added in Bluetooth 4.2) as using 'authenticated low energy Secure Connections pairing with encryption' built on AES-CMAC, the P-256 elliptic curve for key agreement, and AES-CCM for the link itself, and recommends organizations use it for every LE connection where the hardware supports it. The real, repeatedly documented weakness sits one layer up: how a device gets into that encrypted state in the first place, and what it lets an unauthenticated peer read or write once connected. CISA's own alert on the SweynTooth vulnerability family put it plainly: attackers could 'bypass the latest secure pairing mode of BLE' and gain direct read/write access to a device's data — a pairing or implementation failure, not a cryptographic break.

Mainly by targeting the pairing method and the bonding keys it produces, not the cipher that follows. NIST SP 800-121 Revision 2 warns that LE Legacy Pairing — the only pairing method available before Bluetooth 4.2's Secure Connections — 'should be considered broken' for every method except out-of-band exchange with a 128-bit temporary key, because an attacker who captures the pairing frames can derive the resulting Long-Term Key. Even Secure Connections has a documented gap: its 'Just Works' association model, used when neither device has a display or keyboard, gives no protection against an active man-in-the-middle, only against passive eavesdropping — the same weakness CISA flagged when SweynTooth-affected chips let an attacker force or abuse the unauthenticated pairing path. Real implementation bugs compound this: CVE-2024-34722, a 2024 entry in NVD, describes 'a possible authentication bypass during legacy BLE pairing due to incorrect implementation of a protocol' in Android's own Bluetooth stack (function smp_proc_rand), rated CVSS v3.1 8.8. Bonding — the step where paired devices store keys for automatic reconnection — has its own documented flaw: CVE-2020-15802 ('BLURtooth'), affecting Bluetooth Core Specification versions before 5.1, lets an unauthenticated device that bonds over one transport (LE or BR/EDR) overwrite an already-bonded key on the other transport, 'potentially overwriting an authenticated key with an unauthenticated key, or a key with greater entropy with one with less.'

GATT (the Generic Attribute Profile) is the structure every BLE device uses to organize its readable/writable data into services and characteristics, and the Bluetooth SIG's own developer material describes the underlying mechanism directly: 'A Bluetooth device contains a table of data called an attribute table which can be accessed by other connected devices in various possible ways,' and that table 'and the ways in which it can be exploited' is exactly what GATT governs. The specification lets each characteristic require authentication or authorization before it can be read or written — but that protection is only as good as whether the firmware actually enforces it. Two real, current CISA medical-device advisories show what happens when it is not enforced: ICSMA-26-148-01 (May 2026) found that Fourth Frontier's Frontier X2 wearable 'allows unauthenticated BLE read/write access to critical GATT characteristics without enforcing pairing authentication or authorization,' letting an attacker in range start or stop activities, trigger vibrations, and inject fabricated heart-rate and breathing-rate telemetry (CVE-2026-5768, CVSS v3.1 8.8); the same advisory also found the companion app could be spoofed by cloning BLE advertisements. ICSMA-25-364-01 (WHILL Model C2 electric wheelchairs and Model F power chairs) found the products 'do not enforce authentication for Bluetooth connections,' so 'an attacker within range can pair with the device and issue movement commands, override speed restrictions, and manipulate configuration profiles without any credentials or user interaction' (CVE-2025-14346, CVSS v3.1 9.8 Critical) — a mobility-assistance device with no BLE authentication at all.

Yes, and across more than one widely used stack, not a single vendor's mistake. BlueZ, the Bluetooth stack built into the Linux kernel and used in countless Linux-based gateways and hubs, has CVE-2024-8805 in NVD: a 'BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability' where 'the issue results from the lack of authorization prior to allowing access to functionality,' rated CVSS v3.1 8.8 with no authentication required. The Zephyr Project, a common RTOS for embedded BLE peripherals, lists its own 2025 Bluetooth security advisories directly on its documentation site, including CVE-2025-7403 ('unsafe handling in bt_conn_tx_processor... resulting in a write-before-zero,' a use-after-free an attacker can turn into memory corruption) and CVE-2025-10456/CVE-2025-10457, both in BLE connection and fixed-channel handling. Academic research backs this with a specification-level finding, not just implementation bugs: the BLESA paper, awarded Best Paper at USENIX WOOT 2020, found that the BLE reconnection procedure itself makes authentication optional rather than mandatory, and confirmed the resulting spoofing attack worked against real BlueZ (Linux), Fluoride (Android) and iOS BLE stack implementations — meaning a stack that followed the specification correctly could still be spoofed. Add CISA's SweynTooth alert, which names 12 (and growing) vulnerabilities across BLE SDKs from Texas Instruments, NXP, Cypress, STMicroelectronics and other silicon vendors causing crashes, deadlocks and pairing bypass, and the pattern is consistent: the BLE stack baked into a product's firmware is itself a tracked, versioned software component with its own CVE history, the same as any other firmware library.

Confirm the product actually enforces LE Secure Connections pairing (Bluetooth 4.2+) rather than falling back to Legacy Pairing, and that 'Just Works' is not silently accepted for any characteristic that controls or reads something sensitive — verify this against the shipped firmware, not the chipset's marketing claim. Review every GATT characteristic's permission flags and confirm the ones that matter (device control, health data, configuration) actually require authenticated pairing or bonding, not just encryption, since the Fourth Frontier and WHILL advisories above both involve characteristics with effectively no access control at all. Identify the exact BLE stack and version your firmware ships — BlueZ, Zephyr, a vendor SoC SDK, or a proprietary stack — and check it against known CVEs the way a [firmware SBOM](/guides/firmware-sbom/) is built to do, rather than assuming a newer Bluetooth version label means a patched stack. Test reconnection behavior specifically, since BLESA and BLURtooth both show that bonding and reconnection, not the initial pairing ceremony, can be where authentication quietly becomes optional. For the broader BR/EDR-and-LE checklist beyond BLE alone, NIST SP 800-121 Revision 2 (summarized in [SoftWSP's own guide](/guides/nist-sp-800-121-bluetooth-security/)) still gives a useful starting checklist for devices that carry both Bluetooth Classic and LE radios.