CVE-2026-31773: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-31773 is an authentication bypass vulnerability in the Linux kernel's Bluetooth Security Manager Protocol (SMP) legacy responder path, where the Short-Term Key (STK) is incorrectly marked as authenticated during Just Works or Confirm pairing even when MITM authentication was not performed. The flaw resides in the smp_random() function, which labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH — reflecting the locally requested security level rather than the actual pairing outcome. It affects Linux kernel versions from 3.15.5 through multiple stable branches up to (but not including) fixed releases. Disclosed on May 1, 2026, it carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-372 (Incomplete Internal State Distinction): the legacy responder path in smp_random() conflates the requested security level (BT_SECURITY_HIGH) with the achieved authentication state (SMP_FLAG_MITM_AUTH). During Just Works or Confirm legacy pairing, SMP_FLAG_MITM_AUTH remains unset because no MITM-resistant authentication exchange occurs, yet the STK is stored with an authenticated flag, misrepresenting the security properties of the derived key. The attack vector is adjacent network (Bluetooth range), requires no privileges or user interaction, and exploits the mismatch to conduct MITM attacks on Bluetooth connections. The Secure Connections code path already correctly treats JUST_WORKS/JUST_CFM as unauthenticated, making this a regression specific to the legacy path (GitHub Advisory, Red Hat Bugzilla).

Successful exploitation allows an adjacent attacker to conduct man-in-the-middle attacks on Bluetooth communications by exploiting the incorrect authentication metadata on the STK. Because the kernel treats the unauthenticated pairing as authenticated, higher-level security policies that rely on this flag may fail to detect or reject the compromised session, enabling an attacker to intercept, eavesdrop on, and manipulate Bluetooth traffic without detection. The confidentiality, integrity, and availability impacts are all rated High, affecting any Bluetooth-enabled Linux system within radio range of the attacker (GitHub Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of active in-the-wild exploitation as of the time of this report (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.046% (0.000460), indicating a low near-term exploitation probability. Exploitation requires physical or logical proximity within Bluetooth range and the ability to initiate or intercept a legacy pairing session.

1. Reconnaissance: Identify Bluetooth-enabled Linux systems running vulnerable kernel versions within radio range using tools such as hcitool scan or btlejuice to enumerate discoverable devices.
2. Initiate legacy pairing: Position the attacker's device between the target Linux system and a Bluetooth peer, then trigger a legacy SMP pairing exchange using Just Works or Confirm method (e.g., using a rogue Bluetooth device or a tool like bettercap with Bluetooth MITM capabilities).
3. Exploit authentication mismatch: During the pairing, ensure SMP_FLAG_MITM_AUTH remains unset (as it will be in Just Works/Confirm flows). The vulnerable smp_random() function will store the STK with an authenticated flag despite no MITM protection being established.
4. Intercept communications: With the STK incorrectly marked as authenticated, leverage the derived key to decrypt and manipulate Bluetooth traffic between the victim device and its peer, as higher-level security checks will not reject the session.
5. Maintain access: Continue intercepting or injecting data into the Bluetooth session, as the kernel's security state incorrectly reflects a higher trust level than was actually negotiated (GitHub Advisory).

• Network: Unexpected or unknown Bluetooth devices appearing in proximity during pairing events; duplicate or rogue Bluetooth device addresses (BD_ADDR spoofing) detected in hcitool scan output.
• Logs: Kernel logs (dmesg) showing Bluetooth SMP pairing events with BT_SECURITY_HIGH but without corresponding MITM authentication flags; repeated or anomalous pairing requests from unknown devices in /var/log/syslog or journalctl -u bluetooth.
• Process: Unusual Bluetooth daemon (bluetoothd) activity or unexpected pairing completions without user confirmation prompts, particularly for Just Works pairings on systems configured to require authenticated connections.

Patches are available across multiple stable kernel branches. Administrators should upgrade to one of the following fixed versions: 5.10.253, 5.15.203, 6.1.168, 6.6.134, 6.12.81, 6.18.22, 6.19.12, or 7.0 (GitHub Advisory, Red Hat Bugzilla). As a workaround for systems that cannot be immediately patched, consider disabling Bluetooth entirely (rfkill block bluetooth) or restricting legacy pairing modes via BlueZ configuration (/etc/bluetooth/main.conf — set JustWorksRepairing = never and enforce SSP/Secure Connections where possible). Organizations handling sensitive data over Bluetooth should prioritize patching immediately.