Your headphones – a backdoor to your phone?

A couple of vulnerabilities were added to the CVE database last year that could have devastating effects on mobile phone users who listen to music via Bluetooth headphones

The CVEs in question are:

• CVE-2025-20700: No authentication on Bluetooth Low Energy
• CVE-2025-20701: No authentication on Bluetooth Classic
• CVE-2025-20702: Debug protocol exposed that should never be accessible

As stand-alone CVE’s they might not be much of an issue, the three CVE’s each have CVSS scores of 4.0 which isn’t really something to get all excited about – however, at the recent 39C3 (39th Chaos Communications Congress) it was demonstrated that these vulnerabilities could allow an attacker to silently subvert a vulnerable device via their headphones, and do things such as:

• Obtain your phone number
• Access your contacts and call logs
• Trigger Siri / Google assistant
• Silently accept incoming calls
• Silently make outgoing calls to premium numbers
• Activate the phones microphone and eavesdrop on you

How does it work?

The researchers behind this discovery found that Bluetooth audio chips developed by a company called Airoha Technology if not patched, can allow a nearby hacker to fully compromise the device and then piggyback to the paired system (your phone)

Airoha Technology are a chip manufacturer based in Taiwan who provide Bluetooth chips for hundreds of manufacturers. Some manufacturers may not even know they use Airoha chips, as the company also produces them for other suppliers. These vulnerable chips could potentially be embedded within thousands of devices.

A proprietary Bluetooth protocol called RACE is implemented by Airhoa that allows for reading and writing to arbitrary locations in flash memory and RAM, and is exposed over Bluetooth BR/EDR (classic Bluetooth) and Bluetooth LE (Bluetooth Low Energy). In both situations, connections can be established with RACE without pairing – hence the issue whereby threat actors can connect and manipulate vulnerable devices.

The RACE protocol has a 6-byte header and a variable length payload depending on what the command is. The header is structured as follows:

The commands in the payload can vary, but the interesting ones are:

• GetBuildVersion (0x1E08) – Returns the SoC model, SDK version, and build time stamp (used to fingerprint device)
• ReadFlash (0x0403) – Allows reading pages from the flash memory. The arguments typically include a storage type, size (in pages, not bytes), and a 4-byte address
• Read/WriteRAM (0x1680 / 0x1681) – Provides arbitrary read/write access to the entire memory map, including memory-mapped I/O (MMIO) registers and RAM
• GetBD_ADDR (0x0CD5) – Retrieves the device’s public Bluetooth Classic address

These commands are what allows an attacker to manipulate the paired device

So the attack works like this:

• CVE-2025-20700: Missing authentication for GATT (BLE) allows the attacker to discover and connect to headphones just by being within Bluetooth range of a vulnerable device
• CVE-2025-20701: Missing Authentication for Bluetooth classic (BR/EDR) – as above, allows the attacker to discover and connect to headphones just by being in range
• CVE-2025-20702: Critical capabilities in the RACE protocol – allows reading and writing to the device’s Flash memory and RAM. It is therefore possible to permanently alter devices and extract sensitive configuration data

So, to compromise a pair of headphones, an attacker first needs to connect to them by taking advantage of either CVE-2025-20700 or CVE-2025-20701. Headphones typically advertise their presence via BLE, so anyone in range can scan for BLE devices, connect to them and use the appropriate GATT service to speak the RACE protocol.

In contrast, devices using Bluetooth classic will not typically announce their presence or respond to inquires, except when they are explicitly set to discoverable or in pairing mode, so to establish a connection the device’s Bluetooth Classic address has to be known. Finding the address of headphones in proximity to the attacker requires special purpose hardware (such as the Ubertooth One). It is however worth noting, that for many affected devices the Bluetooth Classic address can be inquired via RACE. This means attackers that want to establish a Bluetooth Classic connection can simply connect via BLE first and use RACE to find out the Classic address.

Once connected, The attacker can leverage CVE-2025-20702 to abuse the RACE protocol to dump the flash memory of the headphones. Inside the data will be a connection table which includes the names and addresses of paired devices, and the Bluetooth link key which is the cryptographic key that enables the trust between the headphones and the device.

With this information, the attacker can now impersonate the headphones and interact with the paired device as a trusted peripheral.

By using different Bluetooth profiles (such as the Hands-free profile (HfP)) the attacker can access data from the compromised device

Due to the fact that many hands-free headphones are also able to be used to make and receive phone calls, the attacker can use the HfP AT+CNUM to obtain the victim’s phone number. If access to the phone book was granted during initial pairing, the attacker can also access contact lists and call history.

By using the HfP AT+BVRA command, the attacker can trigger voice assistants (e.g., Siri or Google Assistant). Depending on the settings on the phone, this can be used to send text messages, make calls, or perform other actions on the phone.

Fixes

Airoha released a fix to manufacturers back in June 2025. Six months later however, most devices still run vulnerable firmware.

Confirmed vulnerable devices are:

• Sony WH-1000XM4, WH-1000XM5, WH-1000XM6, WF-1000XM5, LinkBuds S
• Bose QuietComfort Earbuds
• Marshall Major V, Minor IV, Acton III, Stanmore III
• JBL Live Buds 3, Endurance Race 2
• Jabra Elite 8 Active (patched)
• Beyerdynamic Amiron 300
• Teufel Tatws2
• JLab Epic Air Sport ANC

Apple Airpods are NOT vulnerable to this attack as they don’t use the Airoha chips

Firmware updates come through the manufacturer apps, unfortunately most users never open these apps after setup, so whilst patches do exist, most are not reaching devices.

• Update firmware through your manufacturer’s app
• Remove old Bluetooth pairings from your phone, and re-pair with the updated apps
• Disable Bluetooth when not in use
• High-value targets: use wired headphones

More / full information about this attack

Watch the full 39C3 Bluetooth Headphone Hijacking event here

… or read the whitepaper here