CVE-2026-31773
Awaiting Analysis Awaiting Analysis - Queue
Bluetooth SMP STK Authentication Bypass in Linux Kernel

Publication date: 2026-05-01

Last updated on: 2026-05-03

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-01
Last Modified
2026-05-03
Generated
2026-05-06
AI Q&A
2026-05-01
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's Bluetooth Secure Simple Pairing (SMP) implementation. Specifically, the legacy responder path in the smp_random() function incorrectly labels the stored Short Term Key (STK) as authenticated whenever the pending security level is set to BT_SECURITY_HIGH. However, this reflects only what the local service requested, not the actual outcome of the pairing process.

For Just Works or Confirm legacy pairing methods, the SMP_FLAG_MITM_AUTH flag remains clear, meaning the resulting STK should be considered unauthenticated even if the local side requested high security. The vulnerability is that the code did not properly use the established Man-In-The-Middle (MITM) state when storing the responder STK, causing a mismatch between key metadata and the actual pairing result.

The fix aligns the legacy pairing path with the Secure Connections code, which already treats Just Works and Just Confirm pairing methods as unauthenticated, ensuring the STK's authentication status correctly reflects the pairing method's security.


How can this vulnerability impact me? :

This vulnerability can lead to a false sense of security by incorrectly marking a Bluetooth pairing key as authenticated when it is not. This means that devices might believe they have a higher level of protection against man-in-the-middle attacks than they actually do.

As a result, attackers could potentially exploit this mislabeling to intercept or manipulate Bluetooth communications that were assumed to be secure, increasing the risk of unauthorized access or data interception.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart