Unauthenticated Bluetooth Vulnerabilities Expose Redmi Buds Users to Data Leaks and Denial-of-Service Attacks

Product family: Xiaomi Redmi Buds (3 Pro through 6 Pro)

Chipset / firmware vendor: Airoha (Bluetooth Classic / RFCOMM stack)

Components affected: Bluetooth Classic firmware (RFCOMM control/data channels, HFP/service channels)

Typical user impact: Paired or unpaired earbuds may leak small amounts of memory (sensitive metadata) and can be repeatedly crashed, dropping connections and requiring a physical reset.

Exploit preconditions: Attacker must be within Bluetooth radio range (roughly up to ~20 meters), be able to discover the target device MAC address (simple Bluetooth scan), and send crafted RFCOMM frames to the target device. No pairing or user interaction required.

Comparison table

Field	CVE-2025-13834 (Info Disclosure)	CVE-2025-13328 (DoS / Crash)
Common name	“RFCOMM information leak” (Redmi Buds)	“RFCOMM flooding / resource exhaustion” (Redmi Buds)
CVE	CVE-2025-13834	CVE-2025-13328
CVSS (base)	Not universally published; high/critical in vendor advisories	Not universally published; high severity for availability impact
Severity	Critical (data exposure)	High (availability/DoS)
Exploitability	Remote, unauthenticated, Bluetooth range	Remote, unauthenticated, Bluetooth range
Exploit availability	Proof-of-concept level techniques publicly described (RFCOMM TEST malformed requests)	Public descriptions of flooding technique; repeatable crash reported
Impact	Returns up to ~127 bytes of uninitialized memory — may include call peer info, metadata	Crash/hang of Bluetooth firmware; all connections dropped, device unresponsive until reset
Authentication required	No	No
Persistence / lateral movement	Limited — ephemeral memory leakage; could reveal secrets useful for follow-on attacks	Could be used to create availability attacks or repeated nuisance at scale
Mitigation status	No official vendor patch available at time of reporting	No official vendor patch available at time of reporting

CVE-2025-13834 (Information Disclosure)

This flaw is a classic case of the firmware trusting a length field from an incoming Bluetooth control message. When an attacker sends a specially crafted RFCOMM TEST command that claims a long payload but actually omits it, the device answers with data taken from memory that wasn’t properly initialized or cleared. That means the attacker can steal small chunks of whatever happens to be sitting nearby in memory — sometimes sensitive details like metadata about ongoing calls.

How an attacker would exploit it:

Discover the target device with a Bluetooth scan to learn its MAC address. This requires only a simple Bluetooth adapter and is noisy but easy.
Craft an RFCOMM TEST frame with a manipulated length header (claiming N bytes but providing fewer or no bytes), and send it to the control channel (DLCI 0) or the specific service channel the earbuds expose.
The firmware responds and, due to bad bounds checking, returns up to ~127 bytes of uninitialized RAM which the attacker records.

What can be exposed:
Small memory fragments — the reporting showed up to about 127 bytes per response. Depending on what the device was doing, that can include:

Call peer phone numbers or call metadata
Tiny fragments of in-memory buffers (session identifiers, temporary data)
Other unpredictable contents of RAM (not guaranteed and noisy)

Why this is scary (layman’s analogy):
Think of Heartbleed in web servers: a form submission asks for 64 bytes back and the server hands over more than it should because it blindly trusts that length field. Here, your earbuds can be forced to hand back bits of memory.

Mitre ATT&CK mapping (approximate):

Initial Access: Network (Bluetooth) — unauthenticated.
Impact: Data Leak / Exfiltration.
TTPs: Exploit public-facing service; Information Disclosure.

Is there a public PoC?
Reports and researchers have described the exact mechanism (malformed RFCOMM TEST commands and how to trigger responses). At the time of writing there is public technical write-ups describing the method and demonstration of leakage; full weaponized exploit code may be limited or restricted in public repositories.

Detection ideas and artifacts:

Repeated inbound RFCOMM TEST frames from a single remote MAC (higher-than-normal frequency).
Unusual control-channel traffic where length fields are inconsistent with actual payload sizes.
Device-side HCI or firmware logs (if accessible) that show responses containing unexpected payloads or recoverable memory dumps.

Example detection heuristics (SIEM-like rules — adapt fields to your telemetry):

Splunk (pseudo): index=bluetooth OR index=wireless "rfcomm_test" OR "RFCOMM" | stats count by src_mac, dest_mac | where count > 50 — flag devices receiving >50 RFComm TEST frames in 10 minutes.
Generic host-based: Monitor device logs for unplanned RFCOMM responses containing binary data blobs longer than expected; escalate on repeated occurrences.

Network capture filter to surface suspicious traffic (pcap/tshark):

Look for frequent RFCOMM control frames to the device: bluetooth && rfcomm (depending on your Wireshark/tshark build and Bluetooth capture setup).

Detection rules / IDS signature (conceptual)

Rule: If the same unpaired remote MAC sends RFCOMM TEST frames with anomalous length headers > X and the target replies, raise an alert.
Rule: If there are repeated control-channel exchanges that return binary blobs but no associated paired session, flag for investigation.

Logs / sources to monitor:

Bluetooth packet captures (pcap) from sniffers
Mobile device HCI logs (developer / debug logs) when available
Endpoint telemetry that records Bluetooth connect/disconnect and unusual packet counts

Recommended immediate mitigations:

Turn off Bluetooth or disable device discovery when not in use.
Avoid using earbuds in public or crowded areas where attackers can get in Bluetooth range.
Monitor vendor channels for firmware updates and apply vendor-supplied fixes when available.

CVE-2025-13328 (Denial of Service / Crash)

The firmware’s RFCOMM implementation does not properly limit or manage the rate and queuing of incoming control frames on the standard control channel (DLCI 0) and other RFCOMM channels. An attacker can simply flood the target with legitimate-looking TEST or MSC frames and exhaust the device’s processing queue, causing the Bluetooth firmware to crash or hang.

How an attacker would exploit it:

Discover the device MAC via Bluetooth scan.
Repeatedly send a high volume of RFCOMM TEST frames (or MSC frames) aimed at DLCI 0 and known service channels.
The device’s processing resources become exhausted; the firmware crashes or becomes unresponsive, dropping active audio connections. The earbuds usually need a physical reset (placing them in the charging case or pressing the reset sequence) to recover.

Why this matters:
This is a straightforward availability attack — no pairing needed — that allows an attacker to repeatedly disconnect users, interrupt calls, and render the device temporarily unusable. At scale (many attackers or automated devices), this becomes a practical denial-of-service against nearby users.

Mitre ATT&CK mapping (approximate):

Initial Access: Network (Bluetooth) — unauthenticated.
Impact: Denial of Service, Service Stop.
TTPs: Flooding, Resource Exhaustion.

Is there a public PoC?
Public advisories and technical posts describe the flooding method and that it causes consistent firmware crashes. Some security researchers have demonstrated the behavior; full exploit scripts might be withheld by some researchers but the technique is straightforward to reproduce with Bluetooth transmitters and appropriate frame crafting.

Detection ideas and artifacts:

Sudden spike in inbound RFCOMM control frames to a device, often without a correlating paired session.
Device disconnects or repeated reconnection attempts from the device to paired hosts.
Endpoint/mobile logs showing unexpected Bluetooth service restarts, firmware reboots, or the device entering an unresponsive state.

Example SIEM detection logic (Splunk-like pseudocode):

index=bluetooth_logs action=inbound frame_type=RFCOMM_TEST | stats count by src_mac, dest_mac | where count > 100 — flag if >100 RFCOMM_TEST frames within 5 minutes.
Correlate: If bluetooth_disconnect events spike for a particular dest_mac shortly after inbound RFCOMM flood, generate high-priority incident.

Recommended immediate mitigations:

Disable Bluetooth when not actively used.
Keep physical proximity controls in place (do not leave devices discoverable in public).
If suspecting an active attack, place earbuds in charging case to reset; avoid re-pairing until attack subsides or firmware is patched.

Detection rules and payload indicators — practical guidance

Below are pragmatic, adaptable detection rules and payload signatures you can implement in your environment. Tweak thresholds to your environment to reduce false positives.

1) Endpoint / Mobile rule (heuristic)

Trigger when a single remote MAC sends more than N control frames (RFCOMM TEST or MSC) to a local Bluetooth device within T minutes.
Suggested starting values: N = 30, T = 5 minutes (tune down in noisy environments).

2) Network sniffing (pcap) rule (tshark/wireshark)

Capture filter (conceptual): bluetooth && rfcomm or if your capture supports L2CAP: btl2cap && rfcomm.
Raise if the same source MAC issues many RFCOMM TEST frames or if length headers and payload sizes mismatch repeatedly.

3) SIEM correlation (example)

If bluetooth_inbound_packet_count(src_mac, dest_mac, 5m) > 100 AND device_disconnects(dest_mac, 5m) >= 1 THEN critical_alert.

4) Forensic payload indicator (what to look for in a pcap)

Repeated RFCOMM TEST frames with manipulated length fields (length > actual payload).
Sequences of MSC frames to different channels without successful higher-layer sessions.

5) Host-side logs

Look for firmware panic messages, HCI resets, or unexpected Bluetooth service restarts immediately after heavy control traffic.

Recommended log sources and telemetry to collect

Bluetooth packet captures (pcap) from sniffers placed in high-density environments (meeting rooms, public areas).
Device HCI logs (Android adb bugreport or platform debug logs; iOS has limited HCI visibility but MDM logs may show disconnects).
Endpoint security agents that can log Bluetooth connect/disconnect and volume of packets per remote MAC.
User reports / IT tickets about repeated disconnections or call metadata leakage should be cross-referenced to pcap and HCI logs.

PoC status and responsible disclosure notes

Researchers have publicly described both issues and demonstrated leakage and repeatable crash scenarios. That means the techniques required to exploit are known and have been shown in controlled conditions.
Full weaponized exploit code is not widely published in mainstream public code repositories, but the methods are straightforward to reproduce for someone with Bluetooth frame-crafting capability.

Official patch / vendor status

Official patch: No vendor-supplied firmware patch was available as of January 19, 2026. Users and organizations should regularly check the device vendor (Xiaomi) and chipset vendor (Airoha) support pages for firmware or OTA updates and apply them immediately when released.

Final recommendations

Short-term (immediate): Turn off Bluetooth when idle; keep devices out of discoverable mode in public; avoid using the earbuds in crowded places.
Medium-term (operational): Deploy Bluetooth packet capture in high-risk areas; add SIEM detections for unusual RFCOMM activity; train helpdesk to recognize mass disconnect symptoms.
Long-term (policy/engineering): Require vendors to perform more rigorous bounds checking, rate-limiting of RFCOMM control channels, and produce signed firmware updates. Consider inventorying all Airoha-based Bluetooth devices in the organisation and apply stricter network segmentation for devices that handle sensitive calls or data.