BlueZ and Linux Bluetooth vulnerabilities in embedded devices: find the versions, rank the CVEs, harden and patch

BlueZ is the standard Bluetooth stack on embedded Linux products with a radio, from IoT gateways and smart home hubs to Linux-based infotainment units and operator HMIs. A gateway uses it to read Bluetooth Low Energy sensors, a hub to pair locks and lights, an infotainment unit for phone audio and contacts, and an HMI for service tablets or barcode scanners. All three common build systems ship it: OpenEmbedded-Core has a bluez5 recipe at 5.88, and Buildroot's bluez5_utils package and OpenWrt's packages feed both carried 5.87 on 2026-11-14. The current release, 5.88, is dated 2026-11-05 on kernel.org's BlueZ tarball directory.

"BlueZ" names two pieces of code. The kernel half lives in the Linux source tree under net/bluetooth: HCI, L2CAP, SMP, the socket layer and, up to Linux 6.8, the A2MP and High Speed code. The userspace half is the BlueZ project's bluetoothd daemon with its profile plugins (input, HID over GATT, audio, network, OBEX), its D-Bus API and tools such as bluetoothctl and btmon. A third piece, the controller firmware inside the Bluetooth chip, comes from the chip vendor and is outside both.

This guide covers the stack implementation in a Linux image. Protocol-level weaknesses in Bluetooth Low Energy pairing and GATT, and the Zephyr side, are in our BLE protocol security guide, and NIST's checklist for Bluetooth security modes is explained in our NIST SP 800-121 guide.

A Bluetooth CVE on embedded Linux is a kernel problem when the vulnerable code sits in net/bluetooth, and a BlueZ problem when it sits in bluetoothd or its plugins. The CVE text does not always tell you which. Intel, which maintains BlueZ and was the CNA for BleedingTooth, wrote all three records as flaws "in BlueZ", and the CVE-2020-24490 record adds that it "affects all Linux kernel versions that support BlueZ", even though the Google advisories place every bug in kernel source files.

The distinction decides who ships the fix:

Since February 2024 the Linux kernel's own CNA has assigned CVEs for fixed kernel bugs, including Bluetooth ones, and publishes them in its vulns.git repository and on the linux-cve-announce list. Our Linux kernel CVEs in embedded devices guide covers how to triage that stream by kernel version, configuration and driver; the rest of this page covers what is specific to Bluetooth.

Four CVEs cover the best-known remote Bluetooth risks on embedded Linux, all reachable by an unauthenticated attacker within radio range. Scores below are NVD's, EPSS values are FIRST's for 2026-11-14, and none of the four, nor any other entry mentioning Bluetooth or BlueZ, is in CISA's KEV catalog version 2026.11.13.

The stable versions for BadKarma are the upper bounds of NVD's ranges, and Debian's tracker lists the same fixes in 4.9.240 and 4.19.152 packages. BlueZ itself has had other CVEs, such as CVE-2024-8805 in HID over GATT, which our BLE guide covers; the four above are the ones most often raised against embedded Linux images.

BleedingTooth is the name Google gave to three zero-click flaws in the Linux kernel's Bluetooth subsystem that, chained, allow remote code execution with kernel privileges from radio range. Andy Nguyen's write-up explains that L2CAP-based protocols such as A2MP are "exposed without authentication" in the Linux implementation, and shows a full exploit against x86-64 Ubuntu 20.04.1. BadKarma and BadChoice need the target's Bluetooth device address; BadVibes needs the target to be scanning with a Bluetooth 5 controller, which is exactly what a BLE sensor gateway does all day.

Disclosure was messy, which still matters for old BSP kernels. Google reported to Intel, as the BlueZ and kernel Bluetooth maintainers, instead of the kernel security team. Intel published its advisory on 2020-10-13 with patches that were in no released kernel at the time, then corrected the recommended fixed version from 5.9 to 5.10 the next day. The BadVibes fix had already landed in mainline on 2020-07-30 under the neutral title "fix kernel oops in store_pending_adv_report". A vendor kernel based on 4.19 or 5.4 is only fixed if someone pulled the matching stable release or cherry-picked the commits.

One kernel option reduces the A2MP part. The fix series included a commit that turned off Bluetooth High Speed (CONFIG_BT_HS) by default, and Google's timeline notes that informed parties were approved to disable BT_HS before disclosure. A2MP and the BT_HS option were removed entirely in Linux 6.9 by the commit "Bluetooth: Remove BT_HS". On older kernels, check that CONFIG_BT_HS is off; it only serves rare High Speed hardware.

NVD's records need care here. The Google advisory for BadChoice gives Linux 3.6 and later, but NVD's configuration for CVE-2020-12352 only covers ranges from 5.4, so an NVD-based scan of a 4.14 or 4.19 kernel can miss it. NVD files CVE-2020-24490 under the application CPE for BlueZ with no version, not under the Linux kernel, so a version match can attach it to the userspace package instead of the kernel that contains the bug.

CVE-2023-45866 lets a nearby attacker pair an emulated Bluetooth keyboard with a BlueZ host without any user confirmation, then type commands as the logged-in user. Its finder, Marc Newlin, describes it in his CVE-2023-45866 write-up as tricking "the Bluetooth host state-machine into pairing with a fake keyboard without user-confirmation", and says Linux with BlueZ is vulnerable when Bluetooth is discoverable and connectable. He tested Ubuntu 18.04 to 23.10, and the attack needs only a Linux computer with a normal Bluetooth adapter.

The root cause is a default. BlueZ fixed a similar flaw, CVE-2020-0556, in version 5.54 by adding a ClassicBondedOnly option to the input profile, but, as the Debian tracker notes, that option defaulted to false. Newlin writes that the 2020 fix "was left disabled by default" and that ChromeOS was the only Linux-based OS known to have enabled it. The BlueZ fix, dated 2023-10-10, changes two lines so the default becomes true, citing the HID profile's requirement for Security Mode 4. It first shipped in BlueZ 5.71 on 2023-12-13.

The embedded risk depends on what the device does with HID input. A headless gateway that never registers an agent or shows a shell has less to lose than an infotainment unit or an HMI with a terminal, a browser or a privileged kiosk app, where typed input becomes commands. Ubuntu's CVE page gives the configuration mitigation: set ClassicBondedOnly=true in /etc/bluetooth/input.conf and restart the Bluetooth service, noting that setting it false re-enables legacy devices such as the PS3 controller and the vulnerability.

BlueZ fixes are published as commits in the bluez.git repository on git.kernel.org and then in the next release tarball, without a separate security advisory page from the project. The release notes are terse: the BlueZ ChangeLog entry for 5.71 lists three "Fix issue" lines and does not mention the ClassicBondedOnly change. The practical sources are therefore the commit log, the CVE record's references, and distribution trackers such as the Debian Security Tracker, which names the fix commit and the fixed package per release.

Kernel Bluetooth fixes go through the bluetooth and bluetooth-next trees into mainline, then into the stable and long-term branches. The Debian tracker entry for CVE-2020-24490 shows the pattern: it links the mainline commit and marks it as first released in 5.8, and lists the Debian kernel packages that carry the fix. For newer kernel CVEs, the kernel CNA's records list the fixing commit and the first fixed version for each stable branch.

SoftWSP's automated scan unpacks a firmware image, catalogs the software packages in the extracted file system with their versions (the inventory our firmware SBOM guide describes), and matches each one against CVE records, CISA's KEV catalog and FIRST's EPSS scores. Where the image records the kernel as a package, as OpenWrt's package database does, it is matched against NVD's Linux kernel entry. This is deterministic code: the code scores, and AI narrates. You can inspect the resulting CycloneDX file in the free SBOM viewer.

Version matching follows NVD's records and inherits their limits, which are significant for Bluetooth. CVE-2023-45866 names operating systems but no BlueZ product, CVE-2020-24490 is filed under BlueZ instead of the kernel, CVE-2020-12352's ranges start at 5.4, and a kernel version says nothing about whether CONFIG_BT is built. AI's part is the written explanation of what matched, citing the component, version and record behind each sentence. An engineer reviews every finding before the report is delivered. That review is where kernel configuration, enabled plugins, input.conf and main.conf settings and any distribution or BSP backport become a documented "affected" or "fixed" decision.

For where Bluetooth fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide and our KEV and EPSS prioritisation guide, or device & firmware security services to have a specific image reviewed.

This guide draws on Google's BleedingTooth write-up and advisories, Marc Newlin's CVE-2023-45866 write-up, BlueZ commits, ChangeLog, main.conf, input.conf and bluetoothd manual on git.kernel.org, the Linux kernel commits for each fix, kernel.org's BlueZ release directory, the Debian Security Tracker, Ubuntu's CVE page, the Buildroot, OpenEmbedded-Core and OpenWrt BlueZ build files, NVD, CISA's KEV catalog (version 2026.11.13) and FIRST EPSS data dated 2026-11-14, all read directly on 2026-11-14.