Security Advisory: Airoha-Based Bluetooth Headphones and Earbuds

During our research on Bluetooth headphones and earbuds, we identified several vulnerabilities in devices that incorporate Airoha Systems on a Chip (SoCs). In this blog post, we briefly want to describe the vulnerabilities, point out their impact and provide some context to currently running patch delivery processes as described at this year’s TROOPERS Conference.

Introduction

Airoha is a vendor that, amongst other things, builds Bluetooth SoCs and offers reference designs and implementations incorporating these chips. They have become a large supplier in the Bluetooth audio space, especially in the area of True Wireless Stereo (TWS) earbuds. Several reputable headphone and earbud vendors have built products based on Airoha’s SoCs and reference implementations using Airoha’s Software Development Kit (SDK).

Vulnerability Description

At this point, we do not want to disclose too many details, such as proof of concept code (PoCs) or overly technical information. We want to inform about these vulnerabilities, especially their impact and the difficulties around patching them.

In short, these devices expose a powerful custom protocol that allows manipulating the device by, for example, reading and writing RAM or reading and writing to the flash. We found this protocol to be exposed via BLE GATT to an unpaired attacker. It is also exposed as RFCOMM channel via Bluetooth BD/EDR (also known as Bluetooth Classic). Missing authentication for Bluetooth Classic allows an attacker to use this protocol without pairing with the device. At this point, we decided not to disclose the name of the protocol.

The vulnerabilities are listed under the following CVE numbers that will be published in the future:

• CVE-2025-20700: Missing Authentication for GATT Services
• CVE-2025-20701: Missing Authentication for Bluetooth BR/EDR
• CVE-2025-20702: Critical Capabilities of a Custom Protocol

More information will follow in a detailed blog post and white paper later.

Affected Devices

The SoCs are used in devices such as headsets, earbuds, dongles, speakers, and wireless microphones. However, it is infeasible for us to comprehensively survey and identify all affected products.

During our research, we purchased a number of devices and analyzed devices from friends and colleagues. We can confirm that the issues are prevalent in many entry-level and flagship models. Vendors we confirmed ourselves are Beyerdynamic, Marshall, and Sony. Furthermore, we know of many more devices using the chips that we assume to be vulnerable, too.

The following devices were confirmed to be vulnerable:

• Beyerdynamic Amiron 300
• Bose QuietComfort Earbuds
• EarisMax Bluetooth Auracast Sender
• Jabra Elite 8 Active
• JBL Endurance Race 2
• JBL Live Buds 3
• Jlab Epic Air Sport ANC
• Marshall ACTON III
• Marshall MAJOR V
• Marshall MINOR IV
• Marshall MOTIF II
• Marshall STANMORE III
• Marshall WOBURN III
• MoerLabs EchoBeatz
• Sony CH-720N
• Sony Link Buds S
• Sony ULT Wear
• Sony WF-1000XM3
• Sony WF-1000XM4
• Sony WF-1000XM5
• Sony WF-C500
• Sony WF-C510-GFP
• Sony WH-1000XM4
• Sony WH-1000XM5
• Sony WH-1000XM6
• Sony WH-CH520
• Sony WH-XB910N
• Sony WI-C100
• Teufel Tatws2

Obviously, this approach does not provide a complete picture of all affected devices. What makes this even more difficult is the observation that some devices are only affected by a subset of these issues. There is at least one vendor that seems to have mitigated CVE-2025-20700 and CVE-2025-20701. Whether this was done on purpose or by accident is unknown to us.

One other issue we identified is that some vendors are not even aware that they are using an Airoha SoC. They have outsourced parts of the development of their device, such as the Bluetooth module. If you are a manufacturer of such a device and are unsure whether your devices might be affected, feel free to contact us.

Vulnerability Impact

In most cases, these vulnerabilities allow attackers to fully take over the headphones via Bluetooth. No authentication or pairing is required. The vulnerabilities can be triggered via Bluetooth BR/EDR or Bluetooth Low Energy (BLE). It is possible to read and write the device’s RAM and flash. These capabilities also allow attackers to hijack established trust relationships with other devices, such as the phone paired to the headphones. These capabilities allow for multiple attack scenarios. A few examples are briefly covered below.

Reading Memory: Currently Playing

One attack we implemented was reading out the currently playing media from the headphones via the RAM reading commands. This is a simple example of the RAM read capability. However, this attack needs to be implemented individually for each headphone model and firmware version, as memory addresses change in different firmware.

An example of the attack is shown below:

Media Info Exploit

Eavesdropping

The set of vulnerabilities opens up multiple eavesdropping scenarios. The most straightforward implementation of an eavesdropping attack exploits the broken BR/EDR paring. We have shown that it is possible to simply establish a Bluetooth HFP connection to vulnerable devices and listen to what their microphone is currently recording. However, as they can typically only handle one Bluetooth audio connection, any prior headphone connections will be dropped, making the attack not very clandestine. For it to go unnoticed, headphones have to be turned on, but not in active use.

A second vector for eavesdropping attacks involves exploiting the trust relationship between two paired Bluetooth devices. When a user pairs their headphones with a mobile phone, the phone establishes a trusted bond with the headphones. If an attacker can impersonate the headphones they could hijack this trust relationship in numerous ways. One of the possible attacks would be using the Bluetooth Hands-Free Profile (HFP) to issue commands to the mobile phone. The range of available commands depends on the mobile operating system, but all major platforms support at least initiating and receiving calls.

We demonstrated the full attack chain, starting with the extraction of Bluetooth link keys from the headphones’ flash memory. These keys were then used to impersonate the headphones to a previously paired phone and to trigger a call to an arbitrary number. Under the right conditions, the established call allowed us to successfully eavesdrop on conversations or sounds within earshot of the phone.

Extraction of Phone Number and Contacts

On mobile phones, the device’s own phone number and the numbers of incoming calls are typically accessible. Depending on the phone’s configuration, additional data, such as the call history and stored contacts, may also be retrievable.

Wormability

Due to the fact that devices can be identified via their GATT services and characteristics, and that it is possible to rewrite the firmware to gain code execution, these vulnerabilities allow for a wormable exploit.

What Now? Do I have to Panic?

So, is this serious?

Yes — technically, it is serious. There is a Proof-of-Concept in our lab. But whether it’s practically dangerous for you, a regular consumer, still depends on several factors. Because this is what’s technically possible if all conditions are met. Real attacks are complex to perform, they cannot be done over the Internet or randomly. An attack would require the following:

• Be physically very close to you (within ~10 meters). Bluetooth only works at short range. To exploit the vulnerability, an attacker must be physically near you, such as in the same room, café, or bus.
• Exploit multiple technical steps perfectly without being noticed, requiring a high technical skill set.

Yes — the idea that someone could hijack your headphones, impersonate them towards your phone, and potentially make calls or spy on you, sounds pretty alarming. But this kind of attack only makes sense for high-value targets:

• Journalists, diplomats, political dissidents
• People in sensitive industries
• VIPs under surveillance

Most people do not fall into those categories- so you are probably not a target. People in these categories are generally advised to not rely on Bluetooth headphones. If you see yourself under risk, and decide to wait for a patch until you use your headphones again, please ensure that you also remove the pairing between the headphones and your mobile phone.

End-users need to patch their headphone firmware. However, before that, a patch needs to be available.

Airoha has fixed the vulnerabilities in the SDK and supplied a new version to its customers (the device manufacturers) in the first week of June. Depending on how quickly these different vendors build and distribute firmware updates for their products, some products will be fixed much quicker than others. As of now, we are not aware of any fixed firmware release.

Notes to Hardware Supply Chains

When a vulnerability is discovered in SoCs, the challenge is not just fixing the vulnerability, it’s identifying all the affected products:

• The same Bluetooth SoC is used in dozens or hundreds of different products, often under different brand names.
• Vendors may not disclose which SoC is in use, making it hard to link CVEs to real-world devices.
• Even when patches exist, not all device manufacturers push updates, especially for lower-cost or end-of-life products.

This creates a huge blind spot in vulnerability management due to the nature of the supply chain.

Disclosure and Timeline

This is a shortened timeline. A more detailed timeline will follow.

• March 25, 2025: ERNW reports the vulnerabilities to Airoha via multiple means.
• April 24, 2025: ERNW has not yet received a response from Airoha after several contact attempts. ERNW contacts some confirmed vendors of affected products directly.
• May 27, 2025: Airoha’s first response to ERNW. Communication between ERNW and Airoha starts.
• June 4, 2025: Airoha supplies device manufacturers with an SDK update with mitigations. Manufacturers start developing and shipping patches for their products.
• June 26, 2025: Partial disclosure after 90+ days, TROOPERS talk, and publication of this blog post.

Cheers!

Dennis, Frieder & Julian