Bluetooth
Monthly
A stack-based buffer overflow in the vCard parser of the Alpine iLX-F511 in-dash multimedia receiver (build 7.0.0000) lets an attacker within Bluetooth range execute arbitrary code as root on the head unit. The attacker must operate a malicious Bluetooth device and convince the user to connect the iLX-F511 to it, after which a crafted vCard containing contact data is parsed without adequate length validation and overruns a fixed-length stack buffer; no authentication is required on the attacker's side. Reach is proximity-bound and dependent on that deliberate user-initiated pairing, and no public exploit code was identified at time of analysis, so this is a patch-priority issue rather than a mass-exploitation emergency. The flaw was reported through the Zero Day Initiative as ZDI-CAN-29017 / ZDI-26-821.
Concurrent listen() calls on the same Linux kernel Bluetooth ISO broadcast (BIS) socket can overwrite the socket's connection pointer, leaking the first connection and leaving a stale socket reference that is later dereferenced after free, producing a slab use-after-free in iso_sock_hold() when an HCI disconnect event is processed. The race requires a local authenticated user able to create Bluetooth ISO broadcast sockets (CVSS AV:L/PR:L) and a narrow timing window (AC:H) in iso_sock_listen()/iso_listen_bis(), and is fixed in stable branches including 6.12.113 plus sibling commits. EPSS is 0.21% (11th percentile), the flaw is not in CISA KEV, and no public exploit was identified at time of analysis; the overall signal is a genuine but non-emergency local kernel flaw.
Use-after-free in the Linux kernel Bluetooth SCO receive path can let an unauthenticated Bluetooth-adjacent attacker corrupt or disclose kernel memory while an SCO/eSCO audio link is active. The flaw is a race between sco_recv_scodata() reading hcon->sco_data and sco_conn_free() clearing that pointer without hdev->lock, so reliable exploitation is timing-dependent and requires user interaction to establish the SCO session. Vendor patches are listed for Linux 6.18.57, 7.2.11, and 7.3, EPSS is 0.21% (10th percentile), and no public exploit has been identified at time of analysis.
Use-after-free in the Zephyr RTOS Bluetooth LE host lets an adjacent, unauthenticated peer with an established L2CAP connection-oriented channel (CoC) on a dynamic PSM (0x0080-0x00FF) leave a pending work item pointing into channel memory that the application has already been told it may free. The attacker only needs to send a data K-frame immediately followed by an L2CAP Disconnect Request; because the Bluetooth RX workqueue outranks the system workqueue under cooperative scheduling, the deferred rx_work item cannot run before teardown, so the stack's released() callback fires while the system workqueue still holds a reference, producing memory corruption, information disclosure, or a corrupted workqueue pending list. The vector (CVSS:3.1/AV:A/AC:H/PR:N/UI:N) reflects adjacent-only access, no privileges, and a scheduling race that must be won, and realistic exploitability is further reduced by the requirement that the application free or re-accept the channel in released(). No public exploit code has been identified at time of analysis and the flaw is not in CISA KEV; an upstream fix commit is available.
Bluetooth authentication bypass in SwitchBot Door Lock Series allows an attacker within BLE range to manipulate the lock's communication protocol and bypass electronic lock and access controls without valid credentials, a PIN, or app pairing (PR:N, UI:N). The root cause is CWE-1204 cryptographic misuse, specifically weak initialization vector or related BLE protocol weaknesses, and exploitation is non-remote and does not scale because it requires per-target physical proximity within roughly 10 meters and interaction with live Bluetooth traffic. No public exploit identified at time of analysis; the risk is a targeted physical-intrusion issue that is narrower in reach than the 8.5 score alone suggests.
Memory corruption in the Zephyr RTOS LE Audio Broadcast Sink (subsys/bluetooth/audio/bap_broadcast_sink.c) lets an attacker within Bluetooth radio range write attacker-chosen bytes into static .bss state by broadcasting a crafted Basic Audio Announcement (BASE) with more subgroups or a larger metadata LTV than the sink's fixed arrays can hold. No pairing, bonding, GATT connection, or user interaction is required (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 8.8); the target must be a build with CONFIG_BT_BAP_BROADCAST_SINK enabled and must be periodic-advertising-synced to the attacker's source, or to an advertiser whose address and SID the attacker impersonates (periodic advertising data is unauthenticated). Impact includes corruption of adjacent Bluetooth-audio state with potential remote code execution in the Bluetooth RX thread, plus out-of-bounds disclosure via the BAS receive-state notification; no public exploit code or confirmed active exploitation was identified at time of analysis. The issue is a genuine high-priority flaw rather than a CVSS-inflated paper risk, and an upstream fix is available.
A use-after-free in the Android Bluetooth stack (bluetooth_ccc.cc, function BluetoothCccHandlerCallbackImpl) lets an attacker within Bluetooth radio range execute arbitrary code on unpatched Android devices, with no user interaction and no additional execution privileges required. The flaw is rated CVSS 9.8 under the vendor's AV:N vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H); our independent assessment re-scores it AV:A because exploitation realistically requires the device's Bluetooth to be enabled and the attacker to be within radio range to deliver crafted CCC/GATT traffic, while agreeing that no authentication or victim action limits the attack. No public exploit code and no confirmed in-the-wild exploitation have been identified at time of analysis, and a fix is published in the Android/Pixel security bulletin dated 2026-10-01.
A possible kernel deadlock in the Linux kernel's Bluetooth RFCOMM listener teardown path can be reached by an unauthenticated attacker within Bluetooth radio range (AV:A, PR:N per the vector) who races a new incoming RFCOMM connection against the cleanup of a listening socket. Triggering requires Bluetooth to be enabled on the target, a live application listening on an RFCOMM channel, proximity, and a narrow timing window (AC:H); the condition was reported by lockdep as a POSSIBLE lock-order inversion between a child socket lock and rfcomm_mutex, not a confirmed and reliably reproducible crash, and the assessed impact is availability only (C:N/I:N/A:H). No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and EPSS is very low at 0.18% (7th percentile); vendors have released fixes.
Code execution via local privilege escalation is possible in Google Android's Bluetooth AVRCP handling (handle_app_val_response in btif_rc.cc) because of a race condition (CWE-362) that can corrupt shared state in the Bluetooth stack. The flaw is rated CVSS 7.0 (AV:L/AC:H/PR:L/UI:N) and affects Android 16, Android 16-qpr2, and Android 17; an attacker must already have a low-privilege app installed on the device and must repeatedly drive the AVRCP remote-control code path to win a narrow timing window, with no user interaction required. No public exploit code has been identified and CISA's SSVC assessment records no observed exploitation, so while the technical impact is total if the race is won, the high attack complexity and local-only prerequisites keep this a lower-urgency item than a remotely reachable, deterministic bug.
A race condition in the Linux kernel's Bluetooth L2CAP subsystem allows a use-after-free of the hci_conn::l2cap_data pointer: the disconnect-work handler (disc_work) reaches l2cap_disconn_ind via hci_conn_timeout and hci_proto_disconn_ind and dereferences l2cap_data without locking, so a concurrent teardown that deletes the associated l2cap_conn can free the structure out from under that read, crashing or corrupting kernel memory. Affected systems run kernel builds in the 6.6.84 through 6.14 ranges listed by EUVD that lack the proto_lock fix, and the attacker must be within Bluetooth radio range (AV:A) and unauthenticated (PR:N); the trigger is timing-dependent, requiring a race to be won rather than a deterministic sequence. Independent assessment rates real-world impact as availability-only (C:N/I:N/A:H) at high attack complexity (AC:H), well below the vendor's 8.8 vector, and no public exploit code or CISA KEV listing has been identified at time of analysis; headless servers and systems without Bluetooth hardware or an enabled Bluetooth stack are not exposed.
A memory leak combined with a use-after-free in the Linux kernel's Bluetooth HCI connection-setup path can crash the kernel or gradually exhaust kernel memory when a synchronous (SCO/eSCO) audio connection setup entry is cancelled instead of executed. The defect is in hci_setup_sync(), which queues a wrapper context (conn_handle_t) carrying a NULL destroy callback and a bare hci_conn pointer, so cancelling the entry leaks the context and freeing the connection while its setup work is still queued leaves the driver dereferencing memory it no longer owns. Kernels built with the Bluetooth HCI sync path and containing the introducing commit across the 6.1, 6.6, 6.12, 6.18 and 7.x stable branches are affected; exploitation is timing- and teardown-dependent and practically limited to denial of service, with no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV). Note that the vendor CVSS 3.1 base of 8.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) is judged to overstate real-world risk; an independent assessment scores it CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, i.e. an availability-only impact.
Local users on Linux hosts running the kernel Bluetooth stack (CONFIG_BT) can crash the system by racing an hci_conn teardown against L2CAP getsockopt()/setsockopt() calls, producing a KASAN-detected use-after-free in l2cap_sock.c. Since commit b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref"), l2cap_chan::conn keeps a reference and remains non-NULL after the underlying hci_conn is freed, so dereferencing conn->hcon->hdev reads released memory. Impact is a kernel denial of service rather than confirmed information disclosure or privilege escalation, and the assessed vector (AV:L/AC:H/PR:L/UI:N, A:H) reflects that exploitation is local-only and requires winning a teardown race; no public exploit code or CISA KEV entry was identified at time of analysis. Vendor-released patches are available in the stable kernel versions listed below.
Use-after-free in the Linux kernel Bluetooth L2CAP stack lets a Bluetooth-adjacent attacker corrupt kernel memory by racing an inbound L2CAP connection against the teardown of a parent listening socket, causing dereference of a dangling bt_sk(sk)->parent pointer. Kernels across the 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 and 7.x stable lines are affected (EUVD lists fixed points at 6.1.188, 6.6.157, 6.12.110, 6.18.52 and 7.2.6), and exploitation requires a local process actively managing an L2CAP listener plus an attacker within Bluetooth radio range; the assessed vector is AV:A/AC:H/PR:L, so this is not default-configuration remote exploitation and hinges on winning a narrow timing window. No public exploit code has been identified at time of analysis, and the flaw is not confirmed actively exploited (CISA KEV), but vendor-released patches are available.
Kernel crashes with a NULL-pointer dereference in the Linux kernel's Bluetooth L2CAP socket layer when l2cap_sock_cleanup_listen() performs an unsafe lockless read of l2cap_pi(sk)->chan that races with l2cap_sock_kill() -> l2cap_sock_put_chan() executing on the hdev workqueue after a Bluetooth disconnect. Affected are systems built with Bluetooth support (CONFIG_BT) running unpatched Linux 6.1.x before 6.1.188, 6.6.x before 6.6.157, 6.12.x before 6.12.110, 6.18.x before 6.18.52, or 7.1.5 before 7.2; triggering requires a user able to create/operate a listening L2CAP socket (PR:L) plus an adjacent Bluetooth peer (AV:A) capable of inducing disconnect/teardown, and the timing window is narrow so the race is hard to win deterministically. Consistent with our independent assessment, the impact is confined to a kernel crash (availability only, AC:H) rather than the confidentiality/integrity impact suggested by the higher NVD-published score, and no public exploit code or confirmed active exploitation has been identified at time of analysis while vendor patches are available.
Memory corruption in BlueKitchen BTstack through 1.8.2 allows a bonded Bluetooth peer to overflow the fixed AVDTP stream-endpoint table during A2DP SEP discovery, corrupting adjacent static objects and crashing the stack or severing event delivery on the host device. The flaw is reachable only by an authenticated, already-paired peer that is within Bluetooth radio range and is participating in A2DP stream-endpoint discovery (assessed CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H) - unpaired or purely network-remote attackers cannot trigger it, and no user interaction is required. Confidentiality is not affected; the practical impact is low integrity and high availability loss, making this a moderate-priority memory-safety availability bug. No public exploit code and no confirmed actively exploited status were identified at time of analysis, and a vendor patch is available.
Bluetooth denial of service in Qualcomm Snapdragon firmware allows an attacker within Bluetooth radio range (adjacent network, CVSS 7.4, AV:A/AC:L/PR:N/UI:N, S:C) to trigger a transient crash of the Bluetooth subsystem by supplying a crafted channel map that declares an insufficient number of used channels while adaptive frequency hopping (AFH) is fully enabled on the target. The impact is availability-only (C:N/I:N/A:H) and lasts only while the device is processing the malformed channel map; no confidentiality, integrity, code-execution, or authentication preconditions are present in the assessed vector. No public exploit code exists and there is no confirmed active exploitation (not in CISA KEV) at time of analysis, and exploitation is bounded by physical radio proximity rather than internet reachability. Affected devices are Qualcomm Snapdragon platforms identified by the wildcard CPE cpe:2.3:a:qualcomm,_inc.:snapdragon:*:*:*:*:*:*:*:* and addressed by the Qualcomm September 2026 security bulletin.
Any attacker within Bluetooth Low Energy range can connect to a TCH QRing model R20_B006 smart ring running firmware RT09R20_1.00.00_250318 without pairing, authentication, or user approval, because the device exposes the Nordic UART Service with no client authentication or command authorization. From roughly 10 meters of a worn, powered ring, the attacker bypasses the official companion app and its cloud authentication to read battery status, activate live heart-rate monitoring, and pull stored historical heart-rate and blood-oxygen records. The impact is confidentiality-only (adjacent-vector, unauthenticated per PR:N) with no described ability to modify device state or cause denial of service; no public exploit identified at time of analysis and no vendor-released patch identified.
Out-of-bounds read in the Linux kernel Bluetooth subsystem's eir_get_service_data() leaks kernel heap memory into userspace for ISO broadcast sink configurations. When an ISO broadcast sink processes periodic advertising (PA) reports from a remote Bluetooth broadcaster, a PA payload packed with multiple mismatching Service Data fields causes eir_len to undercount by 2 bytes per field iteration - the subtraction uses only the data length (dlen), omitting the 2-byte length+type header - so the pointer eventually reads past hcon->le_per_adv_data[] into the surrounding struct hci_conn; a drifted field matching the BAA UUID causes those bytes to be copied into iso_pi(sk)->base, recoverable by a local or remote-assisted userspace process via getsockopt(BT_ISO_BASE). No public exploit or CISA KEV listing exists; EPSS of 0.17% (6th percentile) reflects low opportunistic risk, though the Bluetooth adjacent-network constraint caps mass exploitation potential.
An out-of-bounds read in the Bluetooth RFCOMM control-channel handler prh_rfcomm_cc_process_test (inside libanwbtstack.so) on Alpine iLX-F511 in-dash units running firmware 7.0.000 lets a network-adjacent attacker leak limited process memory. The attacker must first pair a malicious Bluetooth device with the head unit - a user-interaction prerequisite (UI:R) - after which a crafted message reaches the vulnerable handler without further authentication (PR:N). Impact of the primitive alone is confined to low-confidentiality disclosure (C:L) for an assessed CVSS of 3.5; the ZDI advisory and CVE description note that chaining with other flaws would be needed to reach arbitrary code execution as root. No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and the vuln.today decision label is 'monitor'.
A use-after-free in the Zephyr RTOS Bluetooth Classic host lets an adjacent, unauthenticated remote Audio Gateway crash or permanently hang the Bluetooth host thread on devices running 4.4.0 through 4.4.2 as an HFP Hands-Free unit (CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled). When bt_hfp_hf_connect() starts an SDP discovery and the following bt_rfcomm_dlc_connect() fails, the old code wiped the live HFP HF object with memset(), destroying a node still linked into the SDP client's request list and a possibly-queued work item; the host later dereferences the NULL pool and function pointers or walks a self-referential list. Impact is denial of service only (CVSS 5.3, AV:A/AC:H/PR:N/UI:N/C:N/I:N/A:H, CWE-416) - the stray indirect call goes through an all-zero pointer the attacker does not control, so there is no code execution. No public exploit code was identified at time of analysis, but reachability depends on product application code that feeds a peer-discovered RFCOMM channel into bt_hfp_hf_connect(); the only in-tree caller is the shell sample, which limits exposure in default builds.
Zephyr's Bluetooth host (subsys/bluetooth/host, versions 2.3.0 through 4.4.2) can be driven to permanently strand connection reservations: when CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1 and an application runs a directed and an undirected connectable extended advertising set on the same identity, an adjacent, unauthenticated attacker who freely chooses an initiator address mapping to the directed set's target causes the wrong bt_conn to be consumed, leaving the undirected set's reservation unreleasable. Each occurrence burns one CONFIG_BT_MAX_CONN slot until bt_disable() or reboot, and repeated attempts against applications that restart the directed set after each disconnect exhaust the pool so connectable advertising fails with -ENOMEM; the directed set also keeps advertising without a reservation, so genuine connections on it are dropped. Impact is availability only (no memory corruption or information disclosure), the vulnerable configuration is non-default on both Kconfig options, and no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Denial of service in the Zephyr RTOS Bluetooth Classic Hands-Free Profile (HF role) allows a remote Audio Gateway peer to permanently leak entries from the fixed HFP TX buffer pool and then deadlock the Bluetooth RX thread, hanging the device until reboot. The bug lives in subsys/bluetooth/host/classic/hfp_hf.c: hfp_hf_disconnected() cancels work items and clears hf->acl but never drains the AT-command buffers queued on hf->tx_pending, and it leaves BT_HFP_HF_FLAG_CONNECTED set, while hfp_hf_create() memsets a reused HF slot without checking whether any work item is still pending or running. Only builds with CONFIG_BT_HFP_HF enabled are affected, and the attacker must reach an established, authenticated HFP session (paired/SSP devices have L2CAP authentication enforced before the RFCOMM channel is reachable), so this is an adjacent-range, authenticated-session availability issue rather than a drive-by one. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but the per-cycle leak is trivially repeatable by any connected AG.
Memory corruption in Zephyr's Bluetooth Classic A2DP/AVDTP host stack allows an adjacent, paired BR/EDR peer to crash or hang the entire device by forcing a delayable work item to survive a session teardown. The attacker opens the AVDTP signalling channel, lets the local application issue an AVDTP procedure (the standard A2DP flow calls bt_a2dp_discover(), arming the 6-second AVDTP_TIMEOUT), then tears the channel down without responding and re-opens it within the remaining window, so that a2dp_get_connection() memsets the session while its timeout node is still linked into the kernel's global timeout list. Preconditions are narrow - the victim must run the experimental CONFIG_BT_A2DP option with the default CONFIG_TIMEOUT_BACKEND_DLIST backend and accept an encrypted (paired) BR/EDR link, which is why the assessed severity is a bounded denial-of-service rather than a remote pre-auth compromise; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
An out-of-bounds read in the ESP-IDF BlueDroid L2CAP configuration-option parser lets an unauthenticated Bluetooth BR/EDR peer within radio range send a malformed configuration request that reads past the end of the received packet, and under some runtime conditions limited adjacent Bluetooth stack memory can be echoed back in an outbound L2CAP Configuration Response. Only ESP32-class devices built with the BlueDroid host stack and Classic Bluetooth (BR/EDR) enabled are affected; builds using the NimBLE stack or with Classic Bluetooth disabled are not exposed. Assessed as CVSS 3.1 6.5 (Medium, AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L), with no public exploit identified at time of analysis and no confirmed active exploitation - a genuine but moderate-priority issue rather than an emergency, addressed in 5.2.8, 5.3.6, 5.5.5, 6.0.3, and 6.1-rc1.
Memory corruption in the Zephyr RTOS Bluetooth host ATT transmit path can be triggered by a peer in Bluetooth radio range whenever an application issues an ATT Signed Write Command over an unencrypted link. In chan_send(), the BT_ATT_OP_SIGNED_WRITE_CMD branch unrefers a net_buf it does not own after bt_smp_sign() fails (no local CSRK exists for the peer - a state the remote peer controls by pairing without requesting the signing key, pairing with No Bonding, staying unpaired, or keeping the link unencrypted); the callers honor the opposite ownership contract, so the already-freed buffer is re-queued, dereferenced and freed a second time, corrupting the ATT TX FIFO, deferred-destroy and pool free lists, while a related retry path can append a second 12-octet signature into a pooled buffer sized for one. Exploitation requires the deprecated, non-default CONFIG_BT_SIGNING build option plus a victim application that actually performs signed writes, giving CVSS 5.9 (AV:A/AC:H/PR:N, no confidentiality impact, high availability impact, low integrity impact); a vendor fix commit and GHSA-p3r4-qw98-j59m are available, and no public exploit was identified at time of analysis.
Zephyr RTOS Bluetooth Mesh nodes built with the default Access-layer delayed-message feature can be persistently muted by a mesh peer that is already provisioned into the same network and within Bluetooth radio range. By flooding the victim with requests that elicit segmented responses while withholding Segment Acknowledgments, the attacker forces bt_mesh_delayable_msg_manage() down an error path that returns a message context to neither the free nor the busy list, permanently shrinking the default four-entry context pool until every reply from Configuration Server, Health Server and application server models fails with -ENOMEM and is silently dropped. The impact is availability-only (CVSS 5.7, CWE-772, authenticated/PR:L and adjacent/AV:A per the assessed vector); the defect is cleared only by a reboot, the upstream fix is a committed source change, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Availability loss in Zephyr RTOS Bluetooth Mesh affects nodes built with the default access-layer delayable message queue, where an unsynchronized race between the host RX thread and the system workqueue lets the handler touch a context slot that has already been purged. The attacker must be a provisioned mesh member - holding the NetKey and a bound AppKey - within Bluetooth radio range, who can control arrival rate, response size and destination address to exhaust the 4-entry context pool and 40-entry chunk pool and force the purge path; the trigger is a narrow, high-complexity race. Winning it produces a read-modify-write through a NULL-based pointer on the system workqueue thread, which on typical targets faults and aborts that thread (stopping all workqueue-driven functionality, including the mesh timing machinery) or resets the node, so impact is availability only - the write value and address are fixed, so there is no memory corruption or code execution path. Scoring is CVSS 3.1 4.8 (AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H); no public exploit identified at time of analysis, and there is no KEV listing.
Notification injection in Fire-Boltt BSW013 smartwatches (firmware through V0.0.8) allows unpaired attackers within Bluetooth Low Energy range to send spoofed alerts and vibrate the device, enabling phishing via fake notifications. The vulnerability stems from missing authentication on a proprietary BLE command characteristic, with only a non-cryptographic CRC-16 checksum protecting commands. No public exploit code has been identified at the time of analysis, and the impact is limited to integrity (spoofed notifications) without confidentiality or availability loss.
The Bluetooth LE Controller in Zephyr RTOS can be faulted or have its receive PDU pool exhausted by a radio-range peer that drives the Link Layer PHY Update procedure into the retained-RX-node state and then sends an unexpected LL Control PDU before the update instant arrives; the invalid-PDU branches of llcp_lp_pu_rx() and llcp_rp_pu_rx() complete the procedure without releasing the retained node, so the procedure context is freed while the node stays out of the receive pool. In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both y) the violated invariant trips llcp_lr_check_done()/llcp_rr_check_done() and terminates in k_oops()/k_panic() from a single crafted PDU sequence, while on releases v3.4.0 through v3.7.x the assertion is never reached and each attempt silently leaks one PDU node from a pool that defaults to a single buffer (CONFIG_BT_CTLR_RX_BUFFERS=1), allowing a few reconnects to render Bluetooth inoperable until reboot. No pairing or encryption is required of the attacking peer (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 6.5), and no public exploit identified at time of analysis.
Denial of service affects Zephyr RTOS builds that include the Bluetooth Link Layer controller, where an over-the-air peer within Bluetooth radio range can trigger a retained RX node leak without pairing, bonding, or encryption. The peer sends a well-formed LL_CONNECTION_UPDATE_IND with a future instant (or reaches the same state as a central via LL_CONNECTION_PARAM_REQ, or through the local procedure via LL_REJECT_IND) and then, before that instant is reached, any other LL Control PDU such as LL_LENGTH_REQ; the invalid-PDU termination path completes the procedure without releasing the retained node, so llcp_rr_check_done() drops the last reference to it. With the default CONFIG_BT_CTLR_ASSERT_DEBUG enabled this produces an immediate fatal assertion in the controller, and with asserts disabled each occurrence permanently consumes a node from the small fixed RX pool until the receive path operates on NULL, with the impact being availability-only, limited to Bluetooth proximity, and persisting until reboot; no public exploit code was identified at time of analysis and there is no CISA KEV listing.
Any Bluetooth device within radio range of a Reachy Mini robot can send CMD_ commands by piggybacking on another operator's completed PIN authentication, because the Bluetooth service keeps its authenticated state in a single shared flag on the service instance rather than binding it to the calling device - the WriteValue handler ignores the BlueZ options argument that carries the caller's identity. The CVSS 3.1 vector AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L (6.3, Medium) reflects that Bluetooth proximity and a genuine user completing the PIN exchange are both required, and that standalone impact is limited to command access; root code execution only follows from chaining with CVE-2026-55419 (unrestricted file upload) and CVE-2026-62661 (path traversal in the Bluetooth command handler). No CISA KEV listing, no EPSS score, and no independently published standalone exploit code were identified at time of analysis - the only public documentation is JFrog's description of this as the second step in a three-step attack chain, with no public exploit identified at time of analysis for this issue alone.
A NULL pointer dereference in the Linux kernel's Bluetooth 6LoWPAN transmit path allows a local user with low privileges to crash the kernel when memory allocation pressure causes skb_clone() to fail inside send_mcast_pkt(). Only systems with the Bluetooth 6LoWPAN subsystem compiled in and actively transmitting multicast packets to a connected peer are affected; the impact is limited to availability (denial of service via kernel crash), with no confidentiality or integrity effect. Exploitation is gated by a non-attacker-controlled precondition (allocation failure), EPSS is negligible at 0.18% (7th percentile), and no public exploit code has been identified at time of analysis, though vendor patches have been released across multiple stable branches.
An out-of-bounds write in the BlueDroid AVRCP implementation of Espressif's ESP-IDF (avrc_vendor_msg) allows an attacker within Bluetooth Classic radio range to corrupt memory on affected ESP32-class devices, potentially causing crashes, undefined behavior, or controlled memory modification. The flaw affects ESP-IDF 5.5.1, 5.4.3, 5.3.4, 5.2.6, 5.1.6 and earlier, but only firmware that actually uses the BlueDroid Bluetooth Classic host stack with the AVRCP profile active and that constructs or passes through vendor-dependent AVRCP commands with a large vendor_len; the CVE carries a CVSS 4.0 base score of 6.1 (AV:A/AC:L/AT:P/PR:N/UI:N) from the GitHub advisory, and an independent mapping to CVSS 3.1 (AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H) rates it moderate rather than critical because exploitation is proximity-bound and profile-dependent. No public exploit code has been identified at time of analysis, and vendor fixes are available through upstream commits referenced in GitHub advisory GHSA-43gh-7r4f-qp57. Note that the vulnerability's impact is worst on builds where assertions are disabled, since the original length check was implemented as an assert; mitigation is an update, not a configuration change, for devices that require AVRCP.
Out-of-bounds write in the BlueDroid Bluetooth host stack shipped with Espressif ESP-IDF 5.5.1, 5.4.3, 5.3.4, 5.2.6, 5.1.6 and earlier allows a nearby attacker-controlled Bluetooth Classic device to corrupt memory on a target during SDP service discovery. The flaw is unauthenticated and requires only Bluetooth radio proximity (assessed CVSS:3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H), because a peer advertising more than 32 service UUIDs overflows the fixed-size uuid_list[32][MAX_UUID_SIZE] buffer in bta_dm_sdp_result(). No public exploit has been identified at time of analysis; upstream fixes are already committed and documented in GitHub advisory GHSA-hmjj-rjvv-w8pq.
Integer overflow in the Zephyr Bluetooth Host stack's bt_br_acl_recv routine lets an attacker within Bluetooth radio range crash or hang devices that process inbound BR/EDR L2CAP ACL traffic, producing an availability-only denial of service. Only builds compiled with the Bluetooth Classic (BR/EDR) host stack enabled and actively handling L2CAP/ACL data are exposed; BLE-only or Bluetooth-disabled configurations are unaffected. No public exploit has been identified at time of analysis, the CVE is not in CISA KEV, and EPSS is 0.20% (9th percentile), making this a moderate, availability-only issue with no confidentiality or integrity impact.
Unauthenticated Bluetooth Low Energy OTA firmware upgrade in the Meatmeet Pro WiFi & Bluetooth Meat Thermometer firmware 1.0.34.4 allows a nearby attacker within BLE radio range to overwrite the device firmware with arbitrary code, achieving remote code execution and causing the owner to lose complete access to the device. The CVSS 3.1 vector is AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8 HIGH), reflecting an adjacent, unauthenticated attack with no user interaction. Publicly available exploit code exists, but no CISA KEV confirmation is present; EPSS is 0.56% (44th percentile).
Cleartext transmission of sensitive information over Bluetooth Low Energy in Tomofun Furbo 360 and Furbo Mini firmware (Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074) gives an attacker within BLE radio range access to limited confidential data. The issue is rated CVSS 2.3 because exploitation requires adjacent proximity and is highly complex, and only confidentiality is affected. No public exploit identified at time of analysis, EPSS is 0.22% (11th percentile), and the vendor did not respond to the disclosure.
Zephyr's Bluetooth Low Energy connection-response handler fails to verify that a connection request was actually initiated, relying only on identifier matching, so an attacker positioned within BLE radio range can inject unsolicited connection responses against affected devices. Successful exploitation corrupts connection state, yielding high integrity and availability impact with no confidentiality impact (CVSS 3.1 base 8.1, AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, CWE-358). Publicly available exploit code exists, but there is no evidence of active exploitation and EPSS is low at roughly 0.04% (11th percentile); the vendor advisory GHSA-xqj6-vh76-2vv8 is the authoritative reference.
CVE-2025-32879 is a security vulnerability (CVSS 8.8) that allows an attacker. Risk factors: public PoC available.
Heap OOB write in Android Bluetooth driver via incorrect bounds check.
Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key. Rated medium severity (CVSS 6.8), this vulnerability is no authentication required. No vendor patch available.
Bluetooth® Pairing in Bluetooth Core Specification v1.0B through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when at least one device. Rated high severity (CVSS 7.5), this vulnerability is no authentication required. No vendor patch available.
Bluetooth® Low Energy Pairing in Bluetooth Core Specification v4.0 through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when the MITM. Rated high severity (CVSS 7.5), this vulnerability is no authentication required. No vendor patch available.
Unencrypted Bluetooth Low Energy baseband links in Bluetooth Core Specifications 4.0 through 5.2 may permit an adjacent device to inject a crafted packet during the receive window of the listening. Rated medium severity (CVSS 5.3), this vulnerability is no authentication required. No vendor patch available.
Devices supporting Bluetooth before 5.1 may allow man-in-the-middle attacks, aka BLURtooth. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may allow an unauthenticated user to complete authentication without pairing. Rated medium severity (CVSS 5.4), this vulnerability is no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Pairing in Bluetooth® Core v5.2 and earlier may permit an unauthenticated attacker to acquire credentials with two pairing devices via adjacent access when the unauthenticated user initiates. Rated medium severity (CVSS 6.3), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
A stack-based buffer overflow in the vCard parser of the Alpine iLX-F511 in-dash multimedia receiver (build 7.0.0000) lets an attacker within Bluetooth range execute arbitrary code as root on the head unit. The attacker must operate a malicious Bluetooth device and convince the user to connect the iLX-F511 to it, after which a crafted vCard containing contact data is parsed without adequate length validation and overruns a fixed-length stack buffer; no authentication is required on the attacker's side. Reach is proximity-bound and dependent on that deliberate user-initiated pairing, and no public exploit code was identified at time of analysis, so this is a patch-priority issue rather than a mass-exploitation emergency. The flaw was reported through the Zero Day Initiative as ZDI-CAN-29017 / ZDI-26-821.
Concurrent listen() calls on the same Linux kernel Bluetooth ISO broadcast (BIS) socket can overwrite the socket's connection pointer, leaking the first connection and leaving a stale socket reference that is later dereferenced after free, producing a slab use-after-free in iso_sock_hold() when an HCI disconnect event is processed. The race requires a local authenticated user able to create Bluetooth ISO broadcast sockets (CVSS AV:L/PR:L) and a narrow timing window (AC:H) in iso_sock_listen()/iso_listen_bis(), and is fixed in stable branches including 6.12.113 plus sibling commits. EPSS is 0.21% (11th percentile), the flaw is not in CISA KEV, and no public exploit was identified at time of analysis; the overall signal is a genuine but non-emergency local kernel flaw.
Use-after-free in the Linux kernel Bluetooth SCO receive path can let an unauthenticated Bluetooth-adjacent attacker corrupt or disclose kernel memory while an SCO/eSCO audio link is active. The flaw is a race between sco_recv_scodata() reading hcon->sco_data and sco_conn_free() clearing that pointer without hdev->lock, so reliable exploitation is timing-dependent and requires user interaction to establish the SCO session. Vendor patches are listed for Linux 6.18.57, 7.2.11, and 7.3, EPSS is 0.21% (10th percentile), and no public exploit has been identified at time of analysis.
Use-after-free in the Zephyr RTOS Bluetooth LE host lets an adjacent, unauthenticated peer with an established L2CAP connection-oriented channel (CoC) on a dynamic PSM (0x0080-0x00FF) leave a pending work item pointing into channel memory that the application has already been told it may free. The attacker only needs to send a data K-frame immediately followed by an L2CAP Disconnect Request; because the Bluetooth RX workqueue outranks the system workqueue under cooperative scheduling, the deferred rx_work item cannot run before teardown, so the stack's released() callback fires while the system workqueue still holds a reference, producing memory corruption, information disclosure, or a corrupted workqueue pending list. The vector (CVSS:3.1/AV:A/AC:H/PR:N/UI:N) reflects adjacent-only access, no privileges, and a scheduling race that must be won, and realistic exploitability is further reduced by the requirement that the application free or re-accept the channel in released(). No public exploit code has been identified at time of analysis and the flaw is not in CISA KEV; an upstream fix commit is available.
Bluetooth authentication bypass in SwitchBot Door Lock Series allows an attacker within BLE range to manipulate the lock's communication protocol and bypass electronic lock and access controls without valid credentials, a PIN, or app pairing (PR:N, UI:N). The root cause is CWE-1204 cryptographic misuse, specifically weak initialization vector or related BLE protocol weaknesses, and exploitation is non-remote and does not scale because it requires per-target physical proximity within roughly 10 meters and interaction with live Bluetooth traffic. No public exploit identified at time of analysis; the risk is a targeted physical-intrusion issue that is narrower in reach than the 8.5 score alone suggests.
Memory corruption in the Zephyr RTOS LE Audio Broadcast Sink (subsys/bluetooth/audio/bap_broadcast_sink.c) lets an attacker within Bluetooth radio range write attacker-chosen bytes into static .bss state by broadcasting a crafted Basic Audio Announcement (BASE) with more subgroups or a larger metadata LTV than the sink's fixed arrays can hold. No pairing, bonding, GATT connection, or user interaction is required (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 8.8); the target must be a build with CONFIG_BT_BAP_BROADCAST_SINK enabled and must be periodic-advertising-synced to the attacker's source, or to an advertiser whose address and SID the attacker impersonates (periodic advertising data is unauthenticated). Impact includes corruption of adjacent Bluetooth-audio state with potential remote code execution in the Bluetooth RX thread, plus out-of-bounds disclosure via the BAS receive-state notification; no public exploit code or confirmed active exploitation was identified at time of analysis. The issue is a genuine high-priority flaw rather than a CVSS-inflated paper risk, and an upstream fix is available.
A use-after-free in the Android Bluetooth stack (bluetooth_ccc.cc, function BluetoothCccHandlerCallbackImpl) lets an attacker within Bluetooth radio range execute arbitrary code on unpatched Android devices, with no user interaction and no additional execution privileges required. The flaw is rated CVSS 9.8 under the vendor's AV:N vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H); our independent assessment re-scores it AV:A because exploitation realistically requires the device's Bluetooth to be enabled and the attacker to be within radio range to deliver crafted CCC/GATT traffic, while agreeing that no authentication or victim action limits the attack. No public exploit code and no confirmed in-the-wild exploitation have been identified at time of analysis, and a fix is published in the Android/Pixel security bulletin dated 2026-10-01.
A possible kernel deadlock in the Linux kernel's Bluetooth RFCOMM listener teardown path can be reached by an unauthenticated attacker within Bluetooth radio range (AV:A, PR:N per the vector) who races a new incoming RFCOMM connection against the cleanup of a listening socket. Triggering requires Bluetooth to be enabled on the target, a live application listening on an RFCOMM channel, proximity, and a narrow timing window (AC:H); the condition was reported by lockdep as a POSSIBLE lock-order inversion between a child socket lock and rfcomm_mutex, not a confirmed and reliably reproducible crash, and the assessed impact is availability only (C:N/I:N/A:H). No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and EPSS is very low at 0.18% (7th percentile); vendors have released fixes.
Code execution via local privilege escalation is possible in Google Android's Bluetooth AVRCP handling (handle_app_val_response in btif_rc.cc) because of a race condition (CWE-362) that can corrupt shared state in the Bluetooth stack. The flaw is rated CVSS 7.0 (AV:L/AC:H/PR:L/UI:N) and affects Android 16, Android 16-qpr2, and Android 17; an attacker must already have a low-privilege app installed on the device and must repeatedly drive the AVRCP remote-control code path to win a narrow timing window, with no user interaction required. No public exploit code has been identified and CISA's SSVC assessment records no observed exploitation, so while the technical impact is total if the race is won, the high attack complexity and local-only prerequisites keep this a lower-urgency item than a remotely reachable, deterministic bug.
A race condition in the Linux kernel's Bluetooth L2CAP subsystem allows a use-after-free of the hci_conn::l2cap_data pointer: the disconnect-work handler (disc_work) reaches l2cap_disconn_ind via hci_conn_timeout and hci_proto_disconn_ind and dereferences l2cap_data without locking, so a concurrent teardown that deletes the associated l2cap_conn can free the structure out from under that read, crashing or corrupting kernel memory. Affected systems run kernel builds in the 6.6.84 through 6.14 ranges listed by EUVD that lack the proto_lock fix, and the attacker must be within Bluetooth radio range (AV:A) and unauthenticated (PR:N); the trigger is timing-dependent, requiring a race to be won rather than a deterministic sequence. Independent assessment rates real-world impact as availability-only (C:N/I:N/A:H) at high attack complexity (AC:H), well below the vendor's 8.8 vector, and no public exploit code or CISA KEV listing has been identified at time of analysis; headless servers and systems without Bluetooth hardware or an enabled Bluetooth stack are not exposed.
A memory leak combined with a use-after-free in the Linux kernel's Bluetooth HCI connection-setup path can crash the kernel or gradually exhaust kernel memory when a synchronous (SCO/eSCO) audio connection setup entry is cancelled instead of executed. The defect is in hci_setup_sync(), which queues a wrapper context (conn_handle_t) carrying a NULL destroy callback and a bare hci_conn pointer, so cancelling the entry leaks the context and freeing the connection while its setup work is still queued leaves the driver dereferencing memory it no longer owns. Kernels built with the Bluetooth HCI sync path and containing the introducing commit across the 6.1, 6.6, 6.12, 6.18 and 7.x stable branches are affected; exploitation is timing- and teardown-dependent and practically limited to denial of service, with no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV). Note that the vendor CVSS 3.1 base of 8.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) is judged to overstate real-world risk; an independent assessment scores it CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, i.e. an availability-only impact.
Local users on Linux hosts running the kernel Bluetooth stack (CONFIG_BT) can crash the system by racing an hci_conn teardown against L2CAP getsockopt()/setsockopt() calls, producing a KASAN-detected use-after-free in l2cap_sock.c. Since commit b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref"), l2cap_chan::conn keeps a reference and remains non-NULL after the underlying hci_conn is freed, so dereferencing conn->hcon->hdev reads released memory. Impact is a kernel denial of service rather than confirmed information disclosure or privilege escalation, and the assessed vector (AV:L/AC:H/PR:L/UI:N, A:H) reflects that exploitation is local-only and requires winning a teardown race; no public exploit code or CISA KEV entry was identified at time of analysis. Vendor-released patches are available in the stable kernel versions listed below.
Use-after-free in the Linux kernel Bluetooth L2CAP stack lets a Bluetooth-adjacent attacker corrupt kernel memory by racing an inbound L2CAP connection against the teardown of a parent listening socket, causing dereference of a dangling bt_sk(sk)->parent pointer. Kernels across the 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 and 7.x stable lines are affected (EUVD lists fixed points at 6.1.188, 6.6.157, 6.12.110, 6.18.52 and 7.2.6), and exploitation requires a local process actively managing an L2CAP listener plus an attacker within Bluetooth radio range; the assessed vector is AV:A/AC:H/PR:L, so this is not default-configuration remote exploitation and hinges on winning a narrow timing window. No public exploit code has been identified at time of analysis, and the flaw is not confirmed actively exploited (CISA KEV), but vendor-released patches are available.
Kernel crashes with a NULL-pointer dereference in the Linux kernel's Bluetooth L2CAP socket layer when l2cap_sock_cleanup_listen() performs an unsafe lockless read of l2cap_pi(sk)->chan that races with l2cap_sock_kill() -> l2cap_sock_put_chan() executing on the hdev workqueue after a Bluetooth disconnect. Affected are systems built with Bluetooth support (CONFIG_BT) running unpatched Linux 6.1.x before 6.1.188, 6.6.x before 6.6.157, 6.12.x before 6.12.110, 6.18.x before 6.18.52, or 7.1.5 before 7.2; triggering requires a user able to create/operate a listening L2CAP socket (PR:L) plus an adjacent Bluetooth peer (AV:A) capable of inducing disconnect/teardown, and the timing window is narrow so the race is hard to win deterministically. Consistent with our independent assessment, the impact is confined to a kernel crash (availability only, AC:H) rather than the confidentiality/integrity impact suggested by the higher NVD-published score, and no public exploit code or confirmed active exploitation has been identified at time of analysis while vendor patches are available.
Memory corruption in BlueKitchen BTstack through 1.8.2 allows a bonded Bluetooth peer to overflow the fixed AVDTP stream-endpoint table during A2DP SEP discovery, corrupting adjacent static objects and crashing the stack or severing event delivery on the host device. The flaw is reachable only by an authenticated, already-paired peer that is within Bluetooth radio range and is participating in A2DP stream-endpoint discovery (assessed CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H) - unpaired or purely network-remote attackers cannot trigger it, and no user interaction is required. Confidentiality is not affected; the practical impact is low integrity and high availability loss, making this a moderate-priority memory-safety availability bug. No public exploit code and no confirmed actively exploited status were identified at time of analysis, and a vendor patch is available.
Bluetooth denial of service in Qualcomm Snapdragon firmware allows an attacker within Bluetooth radio range (adjacent network, CVSS 7.4, AV:A/AC:L/PR:N/UI:N, S:C) to trigger a transient crash of the Bluetooth subsystem by supplying a crafted channel map that declares an insufficient number of used channels while adaptive frequency hopping (AFH) is fully enabled on the target. The impact is availability-only (C:N/I:N/A:H) and lasts only while the device is processing the malformed channel map; no confidentiality, integrity, code-execution, or authentication preconditions are present in the assessed vector. No public exploit code exists and there is no confirmed active exploitation (not in CISA KEV) at time of analysis, and exploitation is bounded by physical radio proximity rather than internet reachability. Affected devices are Qualcomm Snapdragon platforms identified by the wildcard CPE cpe:2.3:a:qualcomm,_inc.:snapdragon:*:*:*:*:*:*:*:* and addressed by the Qualcomm September 2026 security bulletin.
Any attacker within Bluetooth Low Energy range can connect to a TCH QRing model R20_B006 smart ring running firmware RT09R20_1.00.00_250318 without pairing, authentication, or user approval, because the device exposes the Nordic UART Service with no client authentication or command authorization. From roughly 10 meters of a worn, powered ring, the attacker bypasses the official companion app and its cloud authentication to read battery status, activate live heart-rate monitoring, and pull stored historical heart-rate and blood-oxygen records. The impact is confidentiality-only (adjacent-vector, unauthenticated per PR:N) with no described ability to modify device state or cause denial of service; no public exploit identified at time of analysis and no vendor-released patch identified.
Out-of-bounds read in the Linux kernel Bluetooth subsystem's eir_get_service_data() leaks kernel heap memory into userspace for ISO broadcast sink configurations. When an ISO broadcast sink processes periodic advertising (PA) reports from a remote Bluetooth broadcaster, a PA payload packed with multiple mismatching Service Data fields causes eir_len to undercount by 2 bytes per field iteration - the subtraction uses only the data length (dlen), omitting the 2-byte length+type header - so the pointer eventually reads past hcon->le_per_adv_data[] into the surrounding struct hci_conn; a drifted field matching the BAA UUID causes those bytes to be copied into iso_pi(sk)->base, recoverable by a local or remote-assisted userspace process via getsockopt(BT_ISO_BASE). No public exploit or CISA KEV listing exists; EPSS of 0.17% (6th percentile) reflects low opportunistic risk, though the Bluetooth adjacent-network constraint caps mass exploitation potential.
An out-of-bounds read in the Bluetooth RFCOMM control-channel handler prh_rfcomm_cc_process_test (inside libanwbtstack.so) on Alpine iLX-F511 in-dash units running firmware 7.0.000 lets a network-adjacent attacker leak limited process memory. The attacker must first pair a malicious Bluetooth device with the head unit - a user-interaction prerequisite (UI:R) - after which a crafted message reaches the vulnerable handler without further authentication (PR:N). Impact of the primitive alone is confined to low-confidentiality disclosure (C:L) for an assessed CVSS of 3.5; the ZDI advisory and CVE description note that chaining with other flaws would be needed to reach arbitrary code execution as root. No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and the vuln.today decision label is 'monitor'.
A use-after-free in the Zephyr RTOS Bluetooth Classic host lets an adjacent, unauthenticated remote Audio Gateway crash or permanently hang the Bluetooth host thread on devices running 4.4.0 through 4.4.2 as an HFP Hands-Free unit (CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled). When bt_hfp_hf_connect() starts an SDP discovery and the following bt_rfcomm_dlc_connect() fails, the old code wiped the live HFP HF object with memset(), destroying a node still linked into the SDP client's request list and a possibly-queued work item; the host later dereferences the NULL pool and function pointers or walks a self-referential list. Impact is denial of service only (CVSS 5.3, AV:A/AC:H/PR:N/UI:N/C:N/I:N/A:H, CWE-416) - the stray indirect call goes through an all-zero pointer the attacker does not control, so there is no code execution. No public exploit code was identified at time of analysis, but reachability depends on product application code that feeds a peer-discovered RFCOMM channel into bt_hfp_hf_connect(); the only in-tree caller is the shell sample, which limits exposure in default builds.
Zephyr's Bluetooth host (subsys/bluetooth/host, versions 2.3.0 through 4.4.2) can be driven to permanently strand connection reservations: when CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1 and an application runs a directed and an undirected connectable extended advertising set on the same identity, an adjacent, unauthenticated attacker who freely chooses an initiator address mapping to the directed set's target causes the wrong bt_conn to be consumed, leaving the undirected set's reservation unreleasable. Each occurrence burns one CONFIG_BT_MAX_CONN slot until bt_disable() or reboot, and repeated attempts against applications that restart the directed set after each disconnect exhaust the pool so connectable advertising fails with -ENOMEM; the directed set also keeps advertising without a reservation, so genuine connections on it are dropped. Impact is availability only (no memory corruption or information disclosure), the vulnerable configuration is non-default on both Kconfig options, and no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Denial of service in the Zephyr RTOS Bluetooth Classic Hands-Free Profile (HF role) allows a remote Audio Gateway peer to permanently leak entries from the fixed HFP TX buffer pool and then deadlock the Bluetooth RX thread, hanging the device until reboot. The bug lives in subsys/bluetooth/host/classic/hfp_hf.c: hfp_hf_disconnected() cancels work items and clears hf->acl but never drains the AT-command buffers queued on hf->tx_pending, and it leaves BT_HFP_HF_FLAG_CONNECTED set, while hfp_hf_create() memsets a reused HF slot without checking whether any work item is still pending or running. Only builds with CONFIG_BT_HFP_HF enabled are affected, and the attacker must reach an established, authenticated HFP session (paired/SSP devices have L2CAP authentication enforced before the RFCOMM channel is reachable), so this is an adjacent-range, authenticated-session availability issue rather than a drive-by one. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but the per-cycle leak is trivially repeatable by any connected AG.
Memory corruption in Zephyr's Bluetooth Classic A2DP/AVDTP host stack allows an adjacent, paired BR/EDR peer to crash or hang the entire device by forcing a delayable work item to survive a session teardown. The attacker opens the AVDTP signalling channel, lets the local application issue an AVDTP procedure (the standard A2DP flow calls bt_a2dp_discover(), arming the 6-second AVDTP_TIMEOUT), then tears the channel down without responding and re-opens it within the remaining window, so that a2dp_get_connection() memsets the session while its timeout node is still linked into the kernel's global timeout list. Preconditions are narrow - the victim must run the experimental CONFIG_BT_A2DP option with the default CONFIG_TIMEOUT_BACKEND_DLIST backend and accept an encrypted (paired) BR/EDR link, which is why the assessed severity is a bounded denial-of-service rather than a remote pre-auth compromise; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
An out-of-bounds read in the ESP-IDF BlueDroid L2CAP configuration-option parser lets an unauthenticated Bluetooth BR/EDR peer within radio range send a malformed configuration request that reads past the end of the received packet, and under some runtime conditions limited adjacent Bluetooth stack memory can be echoed back in an outbound L2CAP Configuration Response. Only ESP32-class devices built with the BlueDroid host stack and Classic Bluetooth (BR/EDR) enabled are affected; builds using the NimBLE stack or with Classic Bluetooth disabled are not exposed. Assessed as CVSS 3.1 6.5 (Medium, AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L), with no public exploit identified at time of analysis and no confirmed active exploitation - a genuine but moderate-priority issue rather than an emergency, addressed in 5.2.8, 5.3.6, 5.5.5, 6.0.3, and 6.1-rc1.
Memory corruption in the Zephyr RTOS Bluetooth host ATT transmit path can be triggered by a peer in Bluetooth radio range whenever an application issues an ATT Signed Write Command over an unencrypted link. In chan_send(), the BT_ATT_OP_SIGNED_WRITE_CMD branch unrefers a net_buf it does not own after bt_smp_sign() fails (no local CSRK exists for the peer - a state the remote peer controls by pairing without requesting the signing key, pairing with No Bonding, staying unpaired, or keeping the link unencrypted); the callers honor the opposite ownership contract, so the already-freed buffer is re-queued, dereferenced and freed a second time, corrupting the ATT TX FIFO, deferred-destroy and pool free lists, while a related retry path can append a second 12-octet signature into a pooled buffer sized for one. Exploitation requires the deprecated, non-default CONFIG_BT_SIGNING build option plus a victim application that actually performs signed writes, giving CVSS 5.9 (AV:A/AC:H/PR:N, no confidentiality impact, high availability impact, low integrity impact); a vendor fix commit and GHSA-p3r4-qw98-j59m are available, and no public exploit was identified at time of analysis.
Zephyr RTOS Bluetooth Mesh nodes built with the default Access-layer delayed-message feature can be persistently muted by a mesh peer that is already provisioned into the same network and within Bluetooth radio range. By flooding the victim with requests that elicit segmented responses while withholding Segment Acknowledgments, the attacker forces bt_mesh_delayable_msg_manage() down an error path that returns a message context to neither the free nor the busy list, permanently shrinking the default four-entry context pool until every reply from Configuration Server, Health Server and application server models fails with -ENOMEM and is silently dropped. The impact is availability-only (CVSS 5.7, CWE-772, authenticated/PR:L and adjacent/AV:A per the assessed vector); the defect is cleared only by a reboot, the upstream fix is a committed source change, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Availability loss in Zephyr RTOS Bluetooth Mesh affects nodes built with the default access-layer delayable message queue, where an unsynchronized race between the host RX thread and the system workqueue lets the handler touch a context slot that has already been purged. The attacker must be a provisioned mesh member - holding the NetKey and a bound AppKey - within Bluetooth radio range, who can control arrival rate, response size and destination address to exhaust the 4-entry context pool and 40-entry chunk pool and force the purge path; the trigger is a narrow, high-complexity race. Winning it produces a read-modify-write through a NULL-based pointer on the system workqueue thread, which on typical targets faults and aborts that thread (stopping all workqueue-driven functionality, including the mesh timing machinery) or resets the node, so impact is availability only - the write value and address are fixed, so there is no memory corruption or code execution path. Scoring is CVSS 3.1 4.8 (AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H); no public exploit identified at time of analysis, and there is no KEV listing.
Notification injection in Fire-Boltt BSW013 smartwatches (firmware through V0.0.8) allows unpaired attackers within Bluetooth Low Energy range to send spoofed alerts and vibrate the device, enabling phishing via fake notifications. The vulnerability stems from missing authentication on a proprietary BLE command characteristic, with only a non-cryptographic CRC-16 checksum protecting commands. No public exploit code has been identified at the time of analysis, and the impact is limited to integrity (spoofed notifications) without confidentiality or availability loss.
The Bluetooth LE Controller in Zephyr RTOS can be faulted or have its receive PDU pool exhausted by a radio-range peer that drives the Link Layer PHY Update procedure into the retained-RX-node state and then sends an unexpected LL Control PDU before the update instant arrives; the invalid-PDU branches of llcp_lp_pu_rx() and llcp_rp_pu_rx() complete the procedure without releasing the retained node, so the procedure context is freed while the node stays out of the receive pool. In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both y) the violated invariant trips llcp_lr_check_done()/llcp_rr_check_done() and terminates in k_oops()/k_panic() from a single crafted PDU sequence, while on releases v3.4.0 through v3.7.x the assertion is never reached and each attempt silently leaks one PDU node from a pool that defaults to a single buffer (CONFIG_BT_CTLR_RX_BUFFERS=1), allowing a few reconnects to render Bluetooth inoperable until reboot. No pairing or encryption is required of the attacking peer (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 6.5), and no public exploit identified at time of analysis.
Denial of service affects Zephyr RTOS builds that include the Bluetooth Link Layer controller, where an over-the-air peer within Bluetooth radio range can trigger a retained RX node leak without pairing, bonding, or encryption. The peer sends a well-formed LL_CONNECTION_UPDATE_IND with a future instant (or reaches the same state as a central via LL_CONNECTION_PARAM_REQ, or through the local procedure via LL_REJECT_IND) and then, before that instant is reached, any other LL Control PDU such as LL_LENGTH_REQ; the invalid-PDU termination path completes the procedure without releasing the retained node, so llcp_rr_check_done() drops the last reference to it. With the default CONFIG_BT_CTLR_ASSERT_DEBUG enabled this produces an immediate fatal assertion in the controller, and with asserts disabled each occurrence permanently consumes a node from the small fixed RX pool until the receive path operates on NULL, with the impact being availability-only, limited to Bluetooth proximity, and persisting until reboot; no public exploit code was identified at time of analysis and there is no CISA KEV listing.
Any Bluetooth device within radio range of a Reachy Mini robot can send CMD_ commands by piggybacking on another operator's completed PIN authentication, because the Bluetooth service keeps its authenticated state in a single shared flag on the service instance rather than binding it to the calling device - the WriteValue handler ignores the BlueZ options argument that carries the caller's identity. The CVSS 3.1 vector AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L (6.3, Medium) reflects that Bluetooth proximity and a genuine user completing the PIN exchange are both required, and that standalone impact is limited to command access; root code execution only follows from chaining with CVE-2026-55419 (unrestricted file upload) and CVE-2026-62661 (path traversal in the Bluetooth command handler). No CISA KEV listing, no EPSS score, and no independently published standalone exploit code were identified at time of analysis - the only public documentation is JFrog's description of this as the second step in a three-step attack chain, with no public exploit identified at time of analysis for this issue alone.
A NULL pointer dereference in the Linux kernel's Bluetooth 6LoWPAN transmit path allows a local user with low privileges to crash the kernel when memory allocation pressure causes skb_clone() to fail inside send_mcast_pkt(). Only systems with the Bluetooth 6LoWPAN subsystem compiled in and actively transmitting multicast packets to a connected peer are affected; the impact is limited to availability (denial of service via kernel crash), with no confidentiality or integrity effect. Exploitation is gated by a non-attacker-controlled precondition (allocation failure), EPSS is negligible at 0.18% (7th percentile), and no public exploit code has been identified at time of analysis, though vendor patches have been released across multiple stable branches.
An out-of-bounds write in the BlueDroid AVRCP implementation of Espressif's ESP-IDF (avrc_vendor_msg) allows an attacker within Bluetooth Classic radio range to corrupt memory on affected ESP32-class devices, potentially causing crashes, undefined behavior, or controlled memory modification. The flaw affects ESP-IDF 5.5.1, 5.4.3, 5.3.4, 5.2.6, 5.1.6 and earlier, but only firmware that actually uses the BlueDroid Bluetooth Classic host stack with the AVRCP profile active and that constructs or passes through vendor-dependent AVRCP commands with a large vendor_len; the CVE carries a CVSS 4.0 base score of 6.1 (AV:A/AC:L/AT:P/PR:N/UI:N) from the GitHub advisory, and an independent mapping to CVSS 3.1 (AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H) rates it moderate rather than critical because exploitation is proximity-bound and profile-dependent. No public exploit code has been identified at time of analysis, and vendor fixes are available through upstream commits referenced in GitHub advisory GHSA-43gh-7r4f-qp57. Note that the vulnerability's impact is worst on builds where assertions are disabled, since the original length check was implemented as an assert; mitigation is an update, not a configuration change, for devices that require AVRCP.
Out-of-bounds write in the BlueDroid Bluetooth host stack shipped with Espressif ESP-IDF 5.5.1, 5.4.3, 5.3.4, 5.2.6, 5.1.6 and earlier allows a nearby attacker-controlled Bluetooth Classic device to corrupt memory on a target during SDP service discovery. The flaw is unauthenticated and requires only Bluetooth radio proximity (assessed CVSS:3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H), because a peer advertising more than 32 service UUIDs overflows the fixed-size uuid_list[32][MAX_UUID_SIZE] buffer in bta_dm_sdp_result(). No public exploit has been identified at time of analysis; upstream fixes are already committed and documented in GitHub advisory GHSA-hmjj-rjvv-w8pq.
Integer overflow in the Zephyr Bluetooth Host stack's bt_br_acl_recv routine lets an attacker within Bluetooth radio range crash or hang devices that process inbound BR/EDR L2CAP ACL traffic, producing an availability-only denial of service. Only builds compiled with the Bluetooth Classic (BR/EDR) host stack enabled and actively handling L2CAP/ACL data are exposed; BLE-only or Bluetooth-disabled configurations are unaffected. No public exploit has been identified at time of analysis, the CVE is not in CISA KEV, and EPSS is 0.20% (9th percentile), making this a moderate, availability-only issue with no confidentiality or integrity impact.
Unauthenticated Bluetooth Low Energy OTA firmware upgrade in the Meatmeet Pro WiFi & Bluetooth Meat Thermometer firmware 1.0.34.4 allows a nearby attacker within BLE radio range to overwrite the device firmware with arbitrary code, achieving remote code execution and causing the owner to lose complete access to the device. The CVSS 3.1 vector is AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8 HIGH), reflecting an adjacent, unauthenticated attack with no user interaction. Publicly available exploit code exists, but no CISA KEV confirmation is present; EPSS is 0.56% (44th percentile).
Cleartext transmission of sensitive information over Bluetooth Low Energy in Tomofun Furbo 360 and Furbo Mini firmware (Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074) gives an attacker within BLE radio range access to limited confidential data. The issue is rated CVSS 2.3 because exploitation requires adjacent proximity and is highly complex, and only confidentiality is affected. No public exploit identified at time of analysis, EPSS is 0.22% (11th percentile), and the vendor did not respond to the disclosure.
Zephyr's Bluetooth Low Energy connection-response handler fails to verify that a connection request was actually initiated, relying only on identifier matching, so an attacker positioned within BLE radio range can inject unsolicited connection responses against affected devices. Successful exploitation corrupts connection state, yielding high integrity and availability impact with no confidentiality impact (CVSS 3.1 base 8.1, AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, CWE-358). Publicly available exploit code exists, but there is no evidence of active exploitation and EPSS is low at roughly 0.04% (11th percentile); the vendor advisory GHSA-xqj6-vh76-2vv8 is the authoritative reference.
CVE-2025-32879 is a security vulnerability (CVSS 8.8) that allows an attacker. Risk factors: public PoC available.
Heap OOB write in Android Bluetooth driver via incorrect bounds check.
Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key. Rated medium severity (CVSS 6.8), this vulnerability is no authentication required. No vendor patch available.
Bluetooth® Pairing in Bluetooth Core Specification v1.0B through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when at least one device. Rated high severity (CVSS 7.5), this vulnerability is no authentication required. No vendor patch available.
Bluetooth® Low Energy Pairing in Bluetooth Core Specification v4.0 through v5.3 may permit an unauthenticated MITM to acquire credentials with two pairing devices via adjacent access when the MITM. Rated high severity (CVSS 7.5), this vulnerability is no authentication required. No vendor patch available.
Unencrypted Bluetooth Low Energy baseband links in Bluetooth Core Specifications 4.0 through 5.2 may permit an adjacent device to inject a crafted packet during the receive window of the listening. Rated medium severity (CVSS 5.3), this vulnerability is no authentication required. No vendor patch available.
Devices supporting Bluetooth before 5.1 may allow man-in-the-middle attacks, aka BLURtooth. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may allow an unauthenticated user to complete authentication without pairing. Rated medium severity (CVSS 5.4), this vulnerability is no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Pairing in Bluetooth® Core v5.2 and earlier may permit an unauthenticated attacker to acquire credentials with two pairing devices via adjacent access when the unauthenticated user initiates. Rated medium severity (CVSS 6.3), this vulnerability is no authentication required, low attack complexity. No vendor patch available.