CVE-2026-31773

What it actually does

This is a Linux kernel Bluetooth Security Manager Protocol issue in the legacy pairing responder path. When a local Bluetooth service requested high security, the kernel could store a legacy Short Term Key as “authenticated” even when the actual pairing method was Just Works or Just Confirm, which does not provide man-in-the-middle protection. As a result, key metadata could incorrectly indicate that an unauthenticated pairing satisfied authenticated/high-security requirements. A nearby attacker able to perform Bluetooth pairing could potentially gain access to Bluetooth services or characteristics that were intended to require authenticated pairing.

Why it matters to the business

Systems using affected Linux kernels with Bluetooth enabled may incorrectly trust a weak Bluetooth pairing as strongly authenticated. In practical terms, an attacker within Bluetooth radio range could gain unauthorized access to protected Bluetooth functionality, potentially exposing sensitive data, allowing unauthorized device interaction, or disrupting Bluetooth-dependent workflows. The issue has a high CVSS score because successful exploitation can affect confidentiality, integrity, and availability, but exploitation requires close physical proximity, EPSS is currently low, and it is not listed in CISA KEV or known ransomware use. Because the Linux kernel is widely deployed, organizations should still treat this as important for laptops, embedded Linux devices, gateways, kiosks, medical/industrial devices, and other systems where Bluetooth is enabled.

How an attack unfolds

An attacker must be within Bluetooth range of a vulnerable Linux system and able to participate in or trigger a legacy Bluetooth pairing flow. The attacker uses a pairing method such as Just Works or Just Confirm, which does not establish MITM-authenticated pairing. On the vulnerable responder path, if the local service has requested high security, the kernel may incorrectly store the resulting legacy STK as authenticated based on the requested security level rather than the actual MITM state achieved during pairing. The attacker can then attempt to access Bluetooth services that rely on the kernel’s key authentication metadata to enforce access control. If those services accept the incorrectly marked key, the attacker may interact with resources that should have required authenticated pairing.

How to fix it

Apply a Linux kernel update from the relevant distribution, vendor, or device manufacturer that includes the Bluetooth SMP fix for deriving legacy responder STK authentication from the actual MITM state. No universal fixed package version was provided, so remediation should be based on vendor advisories and patched kernel builds for the specific distribution or device line. Where immediate patching is not possible, disable Bluetooth on systems that do not require it, disable pairable/discoverable mode by default, restrict pairing to trusted maintenance windows, require LE Secure Connections with MITM-capable methods such as passkey, numeric comparison, or OOB where supported, and avoid relying on Just Works pairing for sensitive Bluetooth services. Embedded and appliance vendors should backport the kernel patch and validate Bluetooth access-control behavior after integration.

How to confirm the fix worked

Confirm that the running kernel package includes the upstream or vendor backport for the Bluetooth SMP legacy responder STK authentication fix. Validate both package state and runtime state, since patched packages do not protect systems until the patched kernel is booted. On Linux systems, compare the running kernel from `uname -r` with the vendor’s fixed advisory level and verify package inventory using the distribution’s package manager. For functional validation, use a controlled Bluetooth test device and packet capture such as `btmon` to perform legacy Just Works or Just Confirm pairing against a service requesting high security; the resulting key should not be treated as MITM-authenticated, and access to MITM-required services should fail unless an authenticated pairing method is used. Also verify that systems are not left discoverable or pairable outside approved workflows.

Typical attack path

1. Identify a Linux-based target with Bluetooth enabled and reachable over Bluetooth radio range.
2. Trigger or wait for a legacy Bluetooth pairing opportunity with the target.
3. Negotiate a Just Works or Just Confirm legacy pairing flow that does not provide MITM authentication.
4. Cause the target responder path to store the resulting STK while the local service is requesting high security.
5. Use the incorrectly authenticated key state to access Bluetooth services or characteristics that should require authenticated pairing.
6. Perform unauthorized reads, writes, commands, or device interactions depending on the exposed Bluetooth service.

How to detect it

Retrospective detection is difficult because exploitation occurs over Bluetooth proximity and may not leave conventional network indicators. Focus on Bluetooth pairing history, BlueZ logs, kernel logs, endpoint telemetry, and packet captures if available. Look for unexpected pairings, repeated pairing attempts, legacy pairing methods, Just Works or Just Confirm pairing against services that should require authenticated pairing, and new trusted devices that appeared before patching. Useful sources include `journalctl` logs for `bluetoothd` and kernel Bluetooth messages, `/var/lib/bluetooth/` device trust and link key records, EDR file/process telemetry involving Bluetooth configuration changes, and `btmon` captures from monitored devices. Investigations should correlate pairing timestamps with physical presence, user activity, helpdesk reports, device inventory, and subsequent Bluetooth service access. Presence of legacy unauthenticated pairing followed by access to high-security Bluetooth functionality should be treated as suspicious, but absence of logs does not rule out exploitation because many systems do not retain detailed Bluetooth SMP events by default.

• bluetoothd
• /var/lib/bluetooth/
• /var/lib/bluetooth/*/*/info
• /var/lib/bluetooth/*/linkkeys
• Just Works
• Just Confirm
• Legacy Pairing
• SMP: Pairing Request
• SMP: Pairing Response
• SMP: Pairing Confirm
• SMP: Pairing Random
• MITM: 0
• Authentication Requirements: 0x00
• Authentication Requirements: 0x01
• Authentication Requirements: 0x04
• Authentication Requirements: 0x05
• btmon

What your security team should do

• Inventory Linux systems and embedded devices with Bluetooth enabled, prioritizing laptops, kiosks, gateways, appliances, medical/industrial devices, and systems in public or shared physical spaces.
• Patch or backport the fixed Linux kernel through vendor-supported channels, then reboot into the patched kernel and verify the active kernel version.
• Disable Bluetooth where it is not business-required, especially on servers and unattended devices.
• Restrict pairing windows and require user-approved pairing workflows for managed endpoints and embedded devices.
• Configure Bluetooth services to require MITM-capable pairing methods where supported and avoid Just Works for sensitive operations.
• Review Bluetooth pairing logs and device trust databases for unknown or unexpected paired devices created before patching.
• Use `btmon`, BlueZ logs, endpoint telemetry, and device management records to investigate suspicious pairings or unauthorized Bluetooth service access.
• Because the issue is not currently KEV-listed and EPSS is low, prioritize based on Bluetooth exposure and physical accessibility rather than treating all Linux assets equally.