CVE-2026-19292

CVE-2026-19292 exploits a protocol-level flaw where Bluetooth pairing treats re-pairing as a fresh operation rather than a continuation requiring preservation of prior security guarantees. The attacker doesn't need to break the original LTK — they need only wait for or induce a re-pairing event, at which point they can exploit whatever downgrade path exists in the implementation. This is a design assumption failure in the specification, but the real-world vulnerability lives in implementation decisions: backward-compatibility provisions across Bluetooth's layered architecture (BR/EDR legacy, Secure Connections, LE Secure Connections) create regression branches where the secure path requires explicit activation rather than being the default. The practical constraint is the trigger condition — re-pairing requires user action and physical proximity, which limits mass exploitation compared to passive eavesdropping flaws. However, the re-pairing frequency in your environment matters enormously. Enterprise fleets with high device turnover, frequent factory resets, or BYOD policies may re-pair orders of magnitude more often than the typical user, fundamentally changing the exposure calculus. The deeper problem is maintenance decay. Those compatibility layers weren't just deprecated in specifications — in many vendor roadmaps they're orphaned code receiving zero security review. The BLERP research identifies a specific implementation pattern (V4) that makes this exploitable in practice, but the underlying issue is structural: backward-compatibility branches that work during interoperability testing become forgotten attack surfaces once the code exits active development. The CVSS of 8.8 accurately captures theoretical impact but may overstate practical risk. The EPSS of 0.00227 likely better reflects actual exploitation likelihood. The gap between these scores isn't a scoring problem — it reflects the conditional nature of this vulnerability. Prioritize remediation based on your fleet's re-pairing frequency, not just the CVSS number. Actionable steps: identify which Bluetooth stack implementations in your environment allow security level downgrade during re-pairing, map device fleets against known affected stack versions, and treat high-turnover device deployments as higher priority regardless of the base CVSS score.

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