BLERP Attacks Break BLE Re-Pairing at Scale

BlackHat Asia 2026 showed how BLERP attacks turn a forgotten BLE feature into a universal bypass. Researchers Tommaso Sacchetti and Daniele Antonioli of EURECOM demonstrated re-pairing flaws that let any nearby attacker overwrite the pairing key.

BLE is the low-power flavor of Bluetooth on 2.4 GHz. It is in billions of phones, laptops, mice, watches, cars and medical devices.

The current core spec is 6.2. It is more than 3,000 pages and mentions re-pairing only four times.

What BLERP actually breaks

BLE pairing creates a long-term pairing key. Re-pairing lets two already-paired devices run pairing again and replace that key with PK1.

The spec treats re-pairing as just a new pairing. It never defines how to authenticate it or how security levels should carry over.

The six vulnerabilities

The NDSS 2026 paper defines six protocol flaws. Four are new.

V1 is unauthenticated central re-pairing. V2 is unauthenticated peripheral re-pairing. V3 and V4 are security level downgrades for peripheral and for re-pairing. V5 allows re-pairing after a failed encryption. V6 is key entropy downgrade during re-pairing, a KNOB variant.

Together they mean a single bad message is enough to force a downgrade. The standard enforces nothing between the Security Request and the pairing response.

How the four attacks work

Central impersonation sends a pairing request with no proof of the old key. The peripheral accepts and overwrites its stored key.

Peripheral impersonation is more complex. The attacker rejects the legitimate encryption request, stays connected instead of disconnecting, then sends a Security Request with a high security level. The central starts re-pairing without authentication and can be downgraded mid-handshake.

Double-channel MitM combines both. The attacker holds two different keys, one with the central and one with the peripheral. Single-channel MitM is stealthier. It relays the handshake but tampers with entropy, so both ends derive the same weak 7-byte key and can still talk.

That last variant reuses the KNOB idea but now it is triggerable at will, not only during first pairing.

Why the demo matters

The team built an open source toolkit on NimBLE with Nordic nRF52 hardware. It has a self-contained CLI for one-radio impersonation and a Python host for two-radio MitM with advertisement cloning.

The Black Hat demo used a Xiaomi phone on Android 13 and a Logitech mouse. After the real mouse went to sleep, the attacker advertised as the mouse. The phone connected, showed a single unauthenticated pairing prompt, and then the attacker moved the cursor in circles.

For devices without a display it is zero-click. For phones and laptops it is one click on a generic pairing dialog.

How widely it works

Evaluation covered 22 of 22 devices across Bluetooth 4.2 to 5.4, with all security modes and with Secure Connections on and off. Vendors included Apple (NASDAQ:AAPL), Alphabet Inc. (NASDAQ:GOOGL), Xiaomi, Samsung, Logitech and Microsoft.

Logitech (NASDAQ:LOGI) peripherals, an Xbox controller and several open stacks were vulnerable to central impersonation. Microsoft (NASDAQ:MSFT) Windows and Linux disconnected after the encryption error, which blocked the researchers' peripheral impersonation path, but the underlying downgrade and unauthenticated re-pairing flaws remained.

Two implementation quirks stood out. Apple allowed re-pairing even when the authentication requirement was equal. NimBLE allowed it with a specific crafted value, tracked as CVE-2025-62235 with CVSS 8.1.

Who fixed it and who did not

Disclosure to the Bluetooth SIG was in August 2024. As of the 2026 talk the spec is still unchanged.

Google patched Android to delete the pairing key after two encryption failures and to warn users about suspicious re-pairing. Apple patched. Apache NimBLE patched.

Microsoft said Windows settings pairing was not exploitable in the tested flow and left the spec-level weakness. Logitech called central impersonation intended behavior.

What the proposed fixes look like

The authors propose two layers. Hardened re-pairing enforces that the security level and entropy of the new key cannot be lower than the old, and forces disconnect on encryption failure.

Authenticated re-pairing redesigns the protocol to chain the new key to the old and to hash the full transcript, so tampering is detected. Both require spec changes, which is why the quick vendor hardening matters now.

Why this matters

Prior pairing attacks like KNOB, Invalid Curve and Crackle needed the attacker to catch the first pairing. That is rare. BLERP makes pairing attacks available on demand for any paired device in range.

It also lands at a bad time for hardware startups. This is the third wave of spec-compliant Bluetooth breakage after BLUFFS in late 2023 and the ongoing SweynTooth and BrakTooth implementation bugs, yet most low-cost BLE modules cannot be updated in the field. For founders building on BLE for locks, trackers, or medical peripherals, the takeaway is simple. Assume re-pairing is attacker-controlled until the stack proves otherwise, and validate entropy and security level in your companion app.

Until the SIG mandates key chaining and level enforcement, every new BLE product ships with a downgrade path.