CVE-2026-43134

What it actually does

This is a Linux kernel Bluetooth Low Energy L2CAP flaw in which the kernel did not validate the negotiated encryption key size when processing an L2CAP_LE_CONN_REQ for LE Credit Based Flow Control channels. A nearby unauthenticated Bluetooth attacker could attempt to establish an encrypted L2CAP LE channel using a key size that should be rejected by the Bluetooth specification. If accepted, traffic on that channel may be protected with weaker-than-required encryption, undermining confidentiality and integrity guarantees for Bluetooth LE communications. The attack is adjacent-network only, requires Bluetooth radio proximity, and does not require user interaction or prior privileges.

Why it matters to the business

Systems using vulnerable Linux kernels with Bluetooth enabled may accept weaker Bluetooth encryption than intended, potentially exposing data exchanged over affected Bluetooth LE channels to interception or manipulation by an attacker within radio range. The operational risk is highest for laptops, mobile/embedded Linux devices, kiosks, medical/industrial devices, IoT gateways, and other systems that rely on Bluetooth LE for trusted peripheral or device communication. This issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low, flat EPSS score, so broad internet-scale exploitation is unlikely; however, proximity-based attacks can still matter in high-security, public, or unattended environments.

How an attack unfolds

An attacker positions a Bluetooth-capable device within radio range of a vulnerable Linux host or embedded device with Bluetooth enabled. The attacker initiates or manipulates a Bluetooth LE pairing/encryption state such that the resulting encryption key size is below the minimum expected for the L2CAP LE credit-based channel being opened. The attacker then sends an L2CAP_LE_CONN_REQ to request a LE Credit Based Flow Control channel. Because the vulnerable kernel path fails to check the encryption key size for this request, the channel may be accepted instead of returning the expected L2CAP_CR_LE_BAD_KEY_SIZE rejection. Once the weakly protected channel is established, the attacker may target confidentiality or integrity of application data carried over that Bluetooth LE channel, depending on the connected service and device role.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the Bluetooth L2CAP fix adding encryption key size validation for L2CAP_LE_CONN_REQ. Because exact fixed package versions were not provided, follow the relevant Linux distribution, device vendor, or kernel-stable advisory for CVE-2026-43134 and deploy the corrected kernel package across Bluetooth-capable systems. Reboot systems after kernel update so the patched Bluetooth stack is active. Where immediate patching is not possible, reduce exposure by disabling Bluetooth, blocking Bluetooth service startup, removing unneeded Bluetooth adapters, disabling discoverability/pairing, restricting physical access to devices, and applying device-management policies that prevent untrusted Bluetooth pairings. For embedded or appliance products, obtain firmware from the vendor that incorporates the fixed Linux kernel Bluetooth stack.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a build containing the L2CAP key-size validation fix. Validate with vendor package metadata, kernel changelog references for the Bluetooth L2CAP missing key size check, or source-level confirmation that L2CAP_LE_CONN_REQ handling rejects insufficient encryption key sizes with L2CAP_CR_LE_BAD_KEY_SIZE. Reboot after updating and verify the active kernel with uname or distribution package tools. For functional validation, use a controlled Bluetooth LE test harness or qualification test equivalent to L2CAP/LE/CFC/BV-15-C and confirm that LE Credit Based Connection Requests over links with insufficient encryption key size are rejected. Also confirm Bluetooth is disabled on systems where it is not required.

Typical attack path

1. Identify a Linux-based target with Bluetooth enabled and within radio range.
2. Enumerate Bluetooth LE advertising, pairing, or connection behavior exposed by the target.
3. Establish or influence a Bluetooth LE encrypted connection using an insufficient encryption key size.
4. Send an L2CAP LE Credit Based Connection Request, L2CAP_LE_CONN_REQ, over the weakly encrypted link.
5. Rely on the vulnerable kernel accepting the request instead of rejecting it with L2CAP_CR_LE_BAD_KEY_SIZE.
6. Interact with the resulting L2CAP channel to observe, intercept, or tamper with Bluetooth LE application data where service behavior permits.

How to detect it

Post-exploitation detection is difficult because the issue occurs inside Bluetooth link and L2CAP negotiation and may not produce standard system logs. Review Bluetooth telemetry from btmon, HCI snoop logs, BlueZ logs, endpoint EDR telemetry, and kernel logs around the time of suspicious proximity or device activity. Look for Bluetooth LE encrypted connections where the negotiated encryption key size is below policy expectations, followed by L2CAP LE Credit Based Connection Requests that are accepted rather than rejected for bad key size. Investigate unexpected Bluetooth pairings, new trusted devices, repeated short-lived LE connections, or unusual activity from nearby unknown Bluetooth addresses. On Linux systems using BlueZ, examine bluetoothd journal entries for pairing, bonding, connection, authorization, and profile activity. In packet captures, focus on L2CAP LE Credit Based Connection Request frames, weak encryption key size negotiation, and absence of the expected L2CAP_CR_LE_BAD_KEY_SIZE response. Because Bluetooth MAC addresses may be randomized, correlate timing, physical location, signal strength, and repeated behavior rather than relying only on device address.

• L2CAP_LE_CONN_REQ
• L2CAP_CR_LE_BAD_KEY_SIZE
• LE Credit Based Connection Request
• Bad Key Size
• Encryption Key Size
• btmon
• bluetoothd
• Bluetooth: L2CAP
• L2CAP/LE/CFC/BV-15-C
• journalctl -u bluetooth
• /var/log/bluetooth
• /sys/kernel/debug/bluetooth

What your security team should do

• Inventory Linux systems and embedded devices with Bluetooth enabled, prioritizing laptops, mobile/edge devices, kiosks, IoT gateways, and unattended systems in public or semi-public areas.
• Apply vendor kernel or firmware updates that include the Bluetooth L2CAP_LE_CONN_REQ encryption key size validation fix; reboot to activate the patched kernel.
• Temporarily disable Bluetooth on systems that do not require it, especially high-sensitivity systems and devices in physically accessible locations.
• Review Bluetooth pairing policies and remove stale or untrusted paired devices from managed endpoints.
• Monitor for unusual Bluetooth LE connection attempts, repeated L2CAP LE Credit Based Connection Requests, or unexpected pairings where Bluetooth telemetry is available.
• For high-risk environments, use Bluetooth monitoring tools or endpoint telemetry capable of capturing HCI/L2CAP events during the remediation window.
• Track vendor advisories because exact fixed versions vary by Linux distribution and downstream appliance firmware.