Skip to main content

Linux Kernel Bluetooth EUVDEUVD-2026-26586

| CVE-2026-31773 HIGH
2026-05-01 Linux
Red Hat Suse Information Disclosure Linux
8.8
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
8.8 HIGH
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
SUSE
HIGH
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Adjacent
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

7
Analysis Generated
May 03, 2026 - 07:31 vuln.today
CVSS changed
May 03, 2026 - 07:22 NVD
8.8 (HIGH)
Patch released
May 03, 2026 - 07:16 nvd
Patch available
Patch available
May 01, 2026 - 16:33 EUVD
EUVD ID Assigned
May 01, 2026 - 15:00 euvd
EUVD-2026-26586
Analysis Generated
May 01, 2026 - 15:00 vuln.today
CVE Published
May 01, 2026 - 14:15 nvd
HIGH 8.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SMP: derive legacy responder STK authentication from MITM state

The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved.

For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result.

This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.

AnalysisAI

Incorrect authentication labeling in Linux kernel's Bluetooth SMP legacy pairing allows adjacent attackers to bypass security controls and gain high-level access without proper authentication. The flaw affects the Short Term Key (STK) derivation in Just Works/Confirm pairing modes, where keys are incorrectly marked as authenticated even when Man-in-the-Middle (MITM) protection was not established. With CVSS 8.8 (AV:A/AC:L/PR:N/UI:N), this enables adjacent network attackers to exploit Bluetooth pairing flows without authentication. EPSS score of 0.05% suggests low widespread exploitation likelihood. Vendor patches available across multiple stable kernel branches (5.10.253, 5.15.203, 6.1.168, 6.6.134, 6.12.81, 6.18.22, 6.19.12, 7.0).

Technical ContextAI

The vulnerability resides in the Linux kernel's Bluetooth Security Manager Protocol (SMP) implementation, specifically in the legacy pairing responder path within the smp_random() function (net/bluetooth/smp.c). Bluetooth legacy pairing uses Short Term Keys (STK) for session encryption. The code incorrectly derives STK authentication status from the locally requested security level (pending_sec_level == BT_SECURITY_HIGH) rather than from the actual pairing method's MITM protection state (SMP_FLAG_MITM_AUTH). In Just Works and Numeric Comparison (Confirm) pairing modes-which provide no MITM protection-the STK should remain unauthenticated. However, the flawed logic marks these keys as authenticated when high security is requested locally, creating a mismatch between key metadata and actual security properties. This affects Linux kernel versions from 3.16 through various stable branches, with the vulnerable code introduced in commit fff3490f4781. Secure Connections pairing already handles this correctly; the issue is isolated to the legacy pairing code path.

RemediationAI

Upgrade to patched Linux kernel versions: 5.10.253+ (LTS), 5.15.203+ (LTS), 6.1.168+ (LTS), 6.6.134+ (stable), 6.12.81+ (stable), 6.18.22+ (stable), 6.19.12+ (stable), or 7.0+ (mainline). Upstream fix commits available at https://git.kernel.org/stable/c/929db734d12db41ca5f95424db4612397f1bd4a7 (mainline) and corresponding stable branch commits listed in references. For systems where kernel updates cannot be immediately applied, disable Bluetooth functionality entirely via 'rfkill block bluetooth' or blacklist the btusb/bluetooth kernel modules in /etc/modprobe.d/ (trade-off: loss of all Bluetooth functionality). For Bluetooth-dependent systems, restrict pairing to known devices via allowlisting in BlueZ configuration and disable Bluetooth discoverability when not actively pairing (trade-off: operational burden, does not prevent attacks against already-paired devices). Network-level mitigation is not applicable given the adjacent access requirement. Note that disabling Bluetooth at the application layer may not prevent radio operation; kernel-level or hardware rfkill is required for complete mitigation.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-26586 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy