This CVE exposes a protocol design flaw, not an implementation bug. The Bluetooth SMP security negotiation deliberately omits capability disclosure — a peripheral following the spec correctly does not announce its maximum encryption key size. This means any central device can request a weaker key (7 bytes instead of 16), dropping brute-force complexity from 2^128 to 2^56. The CVSS 8.8 reflects genuine impact, but the EPSS of 0.00134 suggests either constrained attacker awareness or the attack requiring precise positioning — not that the flaw is absent.
The medical device context elevates this beyond typical Bluetooth risks. With billions of BLE devices deployed — many embedded in bodies (pacemakers, insulin pumps, hearing aids) — the failure mode isn't merely data exposure but potential physical harm. The firmware lifecycle compounds this: many BLE stacks run on proprietary RTOS with radio firmware in ROM that cannot be updated without device recall. Vulnerable SMP state machines may sit in inaccessible silicon, protected only by assumed unexploited status.
Vendor implementations diverge meaningfully. Some stacks refuse anything below 16 bytes; others silently accept 7 — both claiming spec compliance. This inconsistency is itself evidence that the specification permits a spectrum of implementations rather than mandating secure defaults. The absence of visible Bluetooth SIG response to the documented research (BLERP V6) suggests institutional acceptance of this flaw class.
Prioritize inventorying BLE-dependent medical devices in your environment. Verify vendor key-size enforcement policies — if they claim spec compliance without specifying拒绝 weaker keys, treat the implementation as vulnerable. Recognize that protocol-layer fixes likely require backward-incompatible specification changes; implementation-layer mitigations (refusing lower key sizes) are the deployable defense, but their adoption is inconsistent across vendors.