CVE-2026-65932

A malformed LMP message that stops Bluetooth advertising sounds like a niche bug—until you examine where BT122 modules actually live. This isn't a vulnerability you exploit with automated tooling from the internet; it's a targeted denial-of-service that requires only radio range to a device you can physically reach. That distinction matters because the CVSS 5.3 score and EPSS probability metric are measuring script-kiddie automation, not deliberate operational disruption. In industrial sensor arrays, medical peripherals, and point-of-sale terminals, a BT122 that stops advertising is a node that goes silent—and in OT environments, silent sensors trigger failovers, alert floods, or automated shutdown sequences depending on how the system was designed. The attack surface isn't one device; it's the advertising channel serving multiple clustered devices in a facility, and hitting it doesn't require sophisticated equipment. The 'plaintext pause encryption response' message is the operational tell. That message should not be processed in plaintext—it belongs to a legacy encryption state transition that the firmware retained for backward compatibility and never removed. There's a deprecated handler sitting in production code that wasn't audited because it was assumed inert. If this audit (B-E2) found one deprecated LMP message handler, the same audit likely found others. The patch for this CVE addresses the symptom, not the structural decay: abandoned parsing paths that persist across firmware revisions because removing them introduces compatibility risk. The practical implications are straightforward. First, identify whether BT122 devices in your environment sit in critical discovery-dependent workflows—if losing advertising triggers operational responses, this vulnerability has blast radius beyond the device itself. Second, treat this as a class vulnerability rather than an isolated CVE; the BT122 shares firmware architecture with predecessors that have shown similar state machine issues (KNOB, BIAS, BLESA). Third, recognize that industrial Bluetooth patch cycles operate on timescales that make EPSS meaningless—the probability that someone with physical access will exploit this before a patch reaches your deployed hardware is the wrong metric. The real question is whether your operational technology environment treats a silent BT122 as a degraded state or a critical alarm, and whether that response is acceptable.

Reviewed through automated stages and approved by a human before publication.