CVE-2026-65933

CVE-2026-65933 is an information leak in the BT122 Bluetooth firmware's connection request handling. When a malformed Bluetooth connection request arrives at the device, the error handler fails to cleanly discard the packet — instead, it processes it just enough to avoid crashing, and in doing so, adjacent memory or internal state leaks back to the attacker. The EPSS score of 0.00178 reflects real barriers: proximity requirements and the difficulty of crafting the specific malformed input. But the CVSS 5.3 is deceptively comfortable, and that's the first thing to reconsider. The BT122 almost certainly exists as a node in a larger system — a sensor mesh, a medical device bus, an industrial control chain. The leaked information isn't just a memory snapshot; it's state that the BT122 will then act on, transmit, or use to establish trust with downstream systems. If that leak includes session tokens, cryptographic nonces, or device identifiers from the handshake, the blast radius extends to every system that trusts subsequent communications from this device. The entry barrier is high; the secondary impact, once the leak enables session hijacking or device impersonation in a connected architecture, follows a completely different severity curve that the CVSS score doesn't model. This is also not a one-off. The B-E4 classification in related research identifies this as part of a recurring class: information leakage from malformed BT inputs in error handlers. The pattern appears across vendors, codebases, and years. That's not coincidence — it's the expected outcome when developers face Bluetooth protocol complexity under memory and compute constraints. The error handler that leaks probably wasn't written to leak; it predates the current security assumptions, persisted through BT version upgrades, and was never audited when BLE features arrived. The code didn't get worse; the context around it got more security-relevant. What to check: Audit your BT stack's error handlers for paths that process malformed input just enough to avoid crashing. Look for handlers that predate your current Bluetooth version or that handle connection states added in later spec revisions. Verify what downstream systems receive data from the BT122 and whether they treat that data as implicitly trusted. If the BT122 is part of a mesh or chain, model what happens if its leaked state enables impersonation. What to do: Apply the BT122 patch, but treat it as a forcing function — the fix should trigger a broader audit of error-path isolation across your Bluetooth firmware base. The low CVSS creates a perverse incentive: teams will deprioritize this for the next firmware update cycle, which on resource-constrained BT devices means 6-18 months of unpatched exposure. If your deployment model includes devices that barely have radio time to check in, the temporal gap between disclosure and remediation is itself a compounding risk. The proximity barrier makes this low-value to opportunistic attackers but high-value to anyone doing targeted reconnaissance on your sensor mesh or medical device bus. The question isn't just whether this specific instance gets fixed. It's whether your organization still has the institutional memory to understand why those error handlers exist at all — and whether the next BT variant will ship with the same pattern to a different memory address.

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