CVE-2026-43334

What it actually does

This flaw is an authentication-policy bypass in the Linux kernel Bluetooth Security Manager Protocol pairing responder logic. When a nearby Bluetooth initiator starts pairing without requesting man-in-the-middle protection, the vulnerable responder can construct its pairing response before enforcing the local high-security requirement. As a result, the responder may omit the MITM authentication bit and later select an unauthenticated “Just Works” confirmation path even though local policy requires authenticated pairing. A successful attacker within Bluetooth radio range may create or influence a bond that is weaker than intended, undermining confidentiality and integrity guarantees for Bluetooth services that rely on high-security pairing.

Why it matters to the business

Systems that depend on Bluetooth high-security pairing may accept weaker, unauthenticated pairings from nearby attackers, potentially allowing unauthorized device access, data exposure, command injection into Bluetooth-connected workflows, or disruption of devices and services. Because exploitation requires local Bluetooth proximity and no public exploit maturity is reported, broad internet-scale risk is low, but exposed workstations, kiosks, medical/industrial devices, embedded Linux appliances, and environments using Bluetooth for trusted access or peripheral control should treat this as a meaningful physical-proximity security risk.

How an attack unfolds

An attacker positions a Bluetooth-capable device within radio range of a vulnerable Linux system acting as the pairing responder. The attacker initiates SMP pairing and deliberately omits the MITM authentication requirement in the pairing request. Due to the vulnerable ordering in the kernel responder logic, the Linux system builds its pairing response based on the initiator-supplied authentication requirements before consistently enforcing its own high-security policy. The responder may therefore return authentication bits that do not require MITM protection. Later, when the temporary key or pairing method is selected, the responder may choose an unauthenticated confirmation method such as Just Works instead of a method that proves user presence or resists active interception. If pairing completes, the attacker obtains a bond or session with weaker authentication than policy intended and may then interact with Bluetooth profiles, services, or application-layer functionality that assumes the peer was strongly authenticated.

How to fix it

Apply the Linux kernel update from the relevant distribution, device vendor, or kernel maintenance stream that includes the Bluetooth SMP fix forcing responder MITM requirements before building the pairing response. No exact fixed kernel versions were provided in the input, so remediation should be tracked through vendor advisories and distribution security updates for the affected Linux kernel packages. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, disabling discoverability and automatic pairing, removing stale or unknown Bluetooth bonds, requiring user-mediated pairing workflows, restricting physical access to Bluetooth-enabled systems, and monitoring for unexpected pairing activity. Embedded or appliance vendors should backport the upstream Bluetooth SMP patch into supported firmware images.

How to confirm the fix worked

Confirm that the installed kernel package or firmware build includes the vendor fix for this Bluetooth SMP responder behavior. Validate operationally by attempting to pair with a controlled Bluetooth initiator that omits MITM in the pairing request while the Linux responder is configured to require high security; the fixed system should reject pairings that cannot meet MITM requirements or force MITM in the responder authentication bits before method selection. Packet-level validation can be performed with Bluetooth monitoring tools such as btmon to confirm that the pairing response aligns with local high-security policy. Also verify that Bluetooth is disabled or non-discoverable on systems where it is not required and that existing trusted bonds are known and authorized.

Typical attack path

1. Identify a Bluetooth-enabled Linux device that is discoverable, connectable, or otherwise reachable within Bluetooth range.
2. Initiate Bluetooth SMP pairing from an attacker-controlled device.
3. Send a pairing request that omits the SMP MITM authentication requirement.
4. Trigger the vulnerable responder behavior where the pairing response is built before local high-security MITM requirements are forced.
5. Complete pairing using a weaker method such as Just Works when the responder should have required MITM-protected pairing.
6. Use the resulting weakly authenticated Bluetooth relationship to access exposed Bluetooth profiles, trusted-device workflows, or application functionality.

How to detect it

To assess whether this was already exploited, review Bluetooth pairing and bonding activity on Linux hosts and appliances during the exposure window. Relevant sources include system journals, kernel logs, bluetoothd logs, btmon or HCI capture logs, endpoint telemetry, configuration-management records of paired devices, and application logs for Bluetooth-backed workflows. Look for new or unexpected Bluetooth bonds, pairing attempts from unknown device addresses, repeated pairing failures followed by successful Just Works pairing, pairing sessions where the local service expected high security but the negotiated method lacked MITM protection, and unusual Bluetooth profile activity immediately after a new bond was created. Because Bluetooth MAC addresses can be randomized and logs vary by distribution, detection should focus on behavioral mismatches: unauthenticated or Just Works pairings on systems that should require high-security pairing, new trusted devices added without an approved change, and activity from unknown nearby devices. If packet captures are available, inspect SMP Pairing Request and Pairing Response auth_req fields for sessions where the initiator omitted MITM and the responder also omitted MITM despite local high-security policy.

• Just Works
• JUST_CFM
• SMP: Pairing Request
• SMP: Pairing Response
• auth_req
• SMP_AUTH_MITM
• bluetoothd
• btmon
• New device
• Paired: yes
• Trusted: yes
• Pairing successful
• AuthenticationComplete
• /var/lib/bluetooth/

What your security team should do

• Inventory Linux systems, embedded devices, and appliances with Bluetooth enabled, prioritizing devices in physically accessible locations or environments where Bluetooth trust is used for access, control, or data exchange.
• Apply vendor kernel or firmware updates that include the Bluetooth SMP MITM enforcement fix as soon as available, especially on systems requiring Bluetooth high-security pairing.
• Temporarily disable Bluetooth or disable discoverability/pairing on systems that do not require active Bluetooth functionality.
• Review and prune existing Bluetooth bonds, removing unknown, stale, or unauthorized paired devices.
• Increase monitoring of Bluetooth pairing events and investigate pairings that used Just Works or lacked MITM protection where high-security pairing is expected.
• For sensitive deployments, require compensating controls such as physical access controls, device allowlisting, and application-layer authentication independent of Bluetooth pairing strength.