# BLERP Attacks Break BLE Re-Pairing at Scale _BLERP attacks exploit six BLE re-pairing flaws to overwrite pairing keys and hijack 22 of 22 tested devices, with no spec fix since 2024._ **Published:** 2026-08-30 **Source:** https://www.startuphub.ai/cybersecurity/blerp-attacks-break-ble-re-pairing-at-scale --- [BlackHat](https://www.youtube.com/watch?v=_08bb55Q33o) 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 re-pairing flawDriverResearchers at EURECOM found six protocol flaws in Bluetooth Low Energy re-pairingFrom the article 2 mentionsResearchers Tommaso Sacchetti and Daniele Antonioli of EURECOM demonstrated re-pairing flaws that let any nearby attacker overwrite the pairing key.Four BLERP attacksContextOverwrite pairing keys by tricking already paired devices into running pairing againFrom the article 2 mentionsBlackHat Asia 2026 showed how BLERP attacks turn a forgotten BLE feature into a universal bypass.performPairing key hijackEffectAttackers overwrite the long term key PK1 without authentication on nearby devicesFrom the article 4 mentionsRe-pairing lets two already-paired devices run pairing again and replace that key with PK1.demonstrated in22 of 22 devices pwnedOutcomeEvery tested phone, laptop, mouse, watch, car, and medical device fell to the demoFrom the article 5 mentionsIt is in billions of phones, laptops, mice, watches, cars and medical devices.BLE re-pairing flawDriverResearchers at EURECOM found six protocol flaws in Bluetooth Low Energy re-pairingFrom the article 2 mentionsResearchers Tommaso Sacchetti and Daniele Antonioli of EURECOM demonstrated re-pairing flaws that let any nearby attacker overwrite the pairing key.Spec ignores re-pairingDriverBluetooth core 6.2 is 3,000+ pages and mentions re-pairing only four timesFrom the articleThe spec treats re-pairing as just a new pairing.BlackHat Asia 2026 demoCoreSacchetti and Antonioli showed BLERP bypassing security on billions of BLE devicesFrom the articleBlackHat Asia 2026 showed how BLERP attacks turn a forgotten BLE feature into a universal bypass.yieldsV1 to V6 vulnerabilitiesCoreFour new flaws enable unauthenticated central, peripheral, and downgrade attacks on re-pairingenableFour BLERP attacksContextOverwrite pairing keys by tricking already paired devices into running pairing againFrom the article 2 mentionsBlackHat Asia 2026 showed how BLERP attacks turn a forgotten BLE feature into a universal bypass.performPairing key hijackEffectAttackers overwrite the long term key PK1 without authentication on nearby devicesFrom the article 4 mentionsRe-pairing lets two already-paired devices run pairing again and replace that key with PK1.22 of 22 devices pwnedOutcomeEvery tested phone, laptop, mouse, watch, car, and medical device fell to the demoFrom the article 5 mentionsIt is in billions of phones, laptops, mice, watches, cars and medical devices.No vendor fix yetOutcomeNo spec fix shipped since 2024 despite coordinated disclosure with manufacturers 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](https://www.youtube.com/watch?v=_08bb55Q33o) 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)](https://www.google.com/finance/quote/AAPL:NASDAQ), [Alphabet Inc. (NASDAQ:GOOGL)](https://www.google.com/finance/quote/GOOGL:NASDAQ), Xiaomi, Samsung, Logitech and [Microsoft](https://www.startuphub.ai/cybersecurity/microsoft-ai-s-structural-shift-in-cybersecurity). [Logitech (NASDAQ:LOGI)](https://www.google.com/finance/quote/LOGI:NASDAQ) peripherals, an Xbox controller and several open stacks were vulnerable to central impersonation. [Microsoft (NASDAQ:MSFT)](https://www.google.com/finance/quote/MSFT:NASDAQ) 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. --- Original analysis from [startuphub.ai](https://www.startuphub.ai), the #1 AI startup directory. © StartupHub.ai. All rights reserved. You may not republish this article in full without a license. Search engines and AI research tools may crawl and summarize for reference. Bulk reproduction or model training on this content requires a license. See https://www.startuphub.ai/terms.