Skip to content
The bluetooth trust problem we carry in our ears

The bluetooth trust problem we carry in our ears

Jamf • November 6, 2026

Believe it or not, even wireless earbuds can present security issues. Read on to find out how.

Wireless earbuds are easy to underestimate because they feel like accessories. They are small, familiar and designed to disappear into daily life. You open the case, put them in your ears and they connect.

But modern wireless audio devices are not passive speakers. They are firmware-driven computers. They have radios, microphones, pairing logic and device-switching features.

That changes the security conversation.

As wireless earbuds, headphones and smart speakers become ubiquitous, they also become part of the privacy boundary around people and organizations. They sit close to conversations. They remember devices. They automatically reconnect. They often receive firmware updates quietly in the background.

And in many environments, users rarely think them as endpoints.

A useful reminder of that shift: in June 2026, Apple fixed CVE-2025-20701 in Beats Studio Buds with Beats Firmware Update 1B211. Apple’s advisory described the impact this way: "An attacker within Bluetooth range may be able to listen through the microphone of a device which is not yet paired and actively seeking pair requests." Apple also noted that this was "a vulnerability in open-source code" and that "Apple Software is among the affected projects."

That wording matters. This was not a remote internet attack. It was not a general "anyone can listen to your earbuds at any time" scenario. Based on Apple’s public advisory, the vulnerable condition involved Bluetooth range and a device that was not yet paired and actively seeking pair requests.

An Enno Rey Netzwerke (ERNW) technical writeup adds an important nuance: on Beats Studio Buds, a brief pairing window could appear each time the case was opened before the owner’s previously paired device reconnected. If an attacker won that race once, they could establish a valid bond and reconnect later.

That means the practical issue was not simply "new earbuds before first pairing." It was a narrow, local, timing-dependent flaw around a pairing window that could recur when the earbuds powered on.

The story is also more complicated than one firmware update. Apple referenced CVE-2025-20701, a CVE that also appears in Airoha’s 2025 Bluetooth audio SDK bulletin as a possible way to pair a Bluetooth audio device without user consent. But ERNW’s Beats-specific writeup adds caution: the researchers say the Beats Studio Buds did not respond to the Airoha RACE protocol and appeared to have RACE disabled, so they initially ruled the device out from the broader Airoha RACE issue. They later found a more specific pairing-window flaw in the Beats Studio Buds themselves.

Apple’s "open-source code" wording should also be read carefully. ERNW later questioned that characterization, noting that if Apple was referring to CVE-2025-20701, the relevant Airoha SDK is not an open-source project. For readers, the practical point is simpler: the issue was fixed in Beats Studio Buds firmware, but its CVE attribution and disclosure history connect it to broader Bluetooth audio research outside Apple.

That makes the Beats fix a useful example of the layered nature of wireless audio security. The risk was not only the phone or laptop. It depended on the accessory firmware, chipset behavior, Bluetooth pairing logic and the short trust window that opens when earbuds power on.

A small bug in a bigger wireless audio attack surface

CVE-2025-20701 is narrow in Apple’s public advisory, but it sits inside a much larger class of Bluetooth audio risks. Wireless earbuds, headphones, speakers, headsets and wireless microphones all depend on short-range radio, pairing flows, firmware, microphones and trust decisions that often happen automatically.

That pattern is not limited to one vendor or one operating system.

Beats Studio Buds / CVE-2025-20701

Affected layer: Beats Studio Buds pairing logic

Core security impact: Apple described a narrow microphone-access issue during an unpaired, pairing-seeking state; ERNW later showed a brief case-opening race window where an attacker could pair once, establish a bond, reconnect later, send or receive audio and potentially extract tracking material.

WhisperPair / CVE-2025-36911

Affected layer: Google Fast Pair accessory implementation

Core security impact: Vulnerable headphones, earbuds and speakers could be forcibly paired with an attacker-controlled device, enabling accessory control, audio playback, microphone recording, or tracking in some scenarios.

WhisperPair is a good example of the same theme outside Apple’s ecosystem. KU Leuven researchers described flaws in Bluetooth accessories that implemented Google Fast Pair incorrectly. According to the researchers, vulnerable wireless headphones and earbuds could be forcibly paired with an attacker-controlled device without user consent, giving the attacker control over the accessory, including audio playback and microphone recording.

This architectural boundary is critical: WhisperPair exploits flaws in the accessory’s Fast Pair implementation, not in the smartphone operating system itself. As a result, users outside the Android ecosystem can still be affected when they use vulnerable accessories. The tracking risk is narrower: if a Fast Pair accessory that supports Google’s Find Hub has never been paired with an Android device, an attacker may be able to register it to their own Google account and track it through the Find Hub network. Updating the host phone alone is not sufficient; the accessory firmware must be patched directly.

Airoha RACE vulnerabilities, 2025

Affected layer: Bluetooth audio chipsets / SDKs

Core security impact: CVE-2025-20700, CVE-2025-20701 and CVE-2025-20702 show how chipset-level authentication and authorization flaws can expose custom protocols, link keys, memory access and audio profiles across affected headphone and earbud products.

Bluetooth audio chipset research tells a similar story from a different layer of the stack. Airoha’s 2025 security bulletin lists CVE-2025-20700, CVE-2025-20701 and CVE-2025-20702 as vulnerabilities affecting Airoha chipsets. Airoha says device OEMs were notified and provided patches before publication and the listed issues include access to critical RACE protocol data, pairing without user consent and unauthorized access to the RACE protocol.

ERNW’s related research into Airoha-based Bluetooth headphones and earbuds describes implementation flaws in products using Airoha SoCs and SDKs. The researchers wrote that vulnerable devices exposed a powerful custom protocol over Bluetooth, allowing operations such as reading and writing RAM or flash, extracting Bluetooth link keys, impersonating headphones to a paired smartphone and accessing the Hands-Free Profile in some scenarios. They also note that several reputable headphone and earbud vendors have built products based on Airoha SoCs and reference implementations.

Affected layer: Bluetooth automatic pairing logic

Core security impact: Silent transition into pairing mode can enable link-key overwriting, impersonation, pairing hijacking, or man-in-the-middle scenarios.

Academic research has also explored the security cost of automatic pairing. Stealtooth, a 2025 paper , describes how commercial Bluetooth audio devices can automatically transition into pairing mode under specific conditions, enabling silent link-key overwriting, pairing hijacking and man-in-the-middle scenarios. The researchers evaluated the attack against 10 commercial Bluetooth devices from major manufacturers.

These examples are not the same vulnerability. They affect different products, stacks, chipsets, protocols and ecosystems. But they all point to the same underlying issue: wireless audio devices are small computers with microphones, radios, firmware and trust relationships. When the logic around pairing or reconnection is too permissive, convenience becomes an attack surface.

Affected layer: AirPods and Beats firmware

Core security impact: A nearby attacker could spoof a trusted source device while headphones were seeking reconnection to a previously paired device.

CVE-2022-32945 / CVE-2022-32946

Affected layer: iOS / iPadOS Core Bluetooth framework

Core security impact: Malicious local apps could bypass permission boundaries and record audio using paired or connected AirPods.

MagicPairing research, 2020

Affected layer: Apple ecosystem pairing protocol

Core security impact: Apple’s seamless accessory pairing model was found to be generally well-designed, but implementation bugs were uncovered through over-the-air and in-process fuzzing.

In 2020, researchers analyzed Apple’s MagicPairing protocol , which enables Apple accessories to pair once and then work smoothly across the Apple ecosystem. Their conclusion was balanced: they described the overall protocol as well-designed but also reported multiple implementation vulnerabilities found through over-the-air and in-process fuzzing.

A browser vulnerability might expose what you read. A messaging vulnerability might expose what you type. A headphone vulnerability can be especially sensitive because the device sits to what you say or what you hear.

This does not mean users should panic. The Beats Studio Buds issue was local, timing-dependent and limited by proximity. But it does mean wireless audio accessories should be treated as real computing devices, not simple audio objects.

ERNW’s writeup also keeps the threat model realistic. The attacker needs to be within Bluetooth range and know enough of the earbuds’ Bluetooth address to race the owner’s device. The eavesdropping may be noticeable: the victim’s audio can drop, and the useful listening window is often short. But the issue is still privacy-relevant ,because the attacker only needs to win the pairing race once to establish a lasting bond. ERNW also showed that, after bonding, they could extract the device’s Identity Resolving Key, which can undermine Bluetooth Low Energy (BLE) address randomization and enable longer-term tracking.

This Beats Studio Buds issue should not be generalized to all Apple audio products. ERNW says it confirmed the vulnerability only on Beats Studio Buds and that AirPods were not affected because they use different chipset and firmware architecture.

These attacks are usually not "someone on the other side of the world hacks your earbuds." The more realistic model is local: a nearby device tries to take advantage of a specific Bluetooth audio state, such as pairing, reconnection, accessory discovery, or automatic trust.

That is why even edge cases are worth studying.

Apple’s wireless audio history

CVE-2025-20701 is a recent Beats Studio Buds example, but it is not the first time Apple’s ecosystem has shown why Bluetooth, microphones and automatic trust deserve attention.

In 2024, Apple fixed CVE-2024-27867 in AirPods Firmware Update 6A326, AirPods Firmware Update 6F8 and Beats Firmware Update 6F8. The update affected AirPods 2nd generation and later, all AirPods Pro models, AirPods Max, Powerbeats Pro and Beats Fit Pro. Apple described the issue this way: "When your headphones are seeking a connection request to one of your previously paired devices, an attacker in Bluetooth range might be able to spoof the intended source device and gain access to your headphones." The fix addressed an authentication issue with improved state management.

In plain English, that older issue was also trust: the headphones were trying to connect to something they already knew and a nearby attacker could potentially impersonate that trusted device.

Security researcher Jonas Dreßler, who r eported CVE-2024-27867 to Apple , described the practical privacy concern more directly: someone who knew the AirPods’ Bluetooth address could connect to them, listen to the microphone, or play music. He also wrote that the issue could apply even while AirPods were connected to a phone, although music would stop playing if someone turned on the microphone. Dreßler later clarified that the vulnerability was not present while AirPods were inside a closed charging case, or while AirPods Max were inside the Smart Case, because the radio was inactive in that state.

In 2022, Apple fixed CVE-2022-32945 and CVE-2022-32946 , two Core Bluetooth issues in iOS 16.1 and iPadOS 16. Apple’s advisory says one issue could allow an app to record audio with paired AirPods and the other could allow an app to record audio using connected AirPods. Apple described the fixes as additional sandbox restrictions and improved entitlements. Both issues were credited to Guilherme Rambo.

These were not AirPods firmware bugs. They were operating system issues. But they still show how sensitive the relationship is between Bluetooth permissions, the operating system and a microphone sitting in the user’s ear.

In many Bluetooth audio scenarios, microphone access means switching from high-quality playback into a bidirectional voice path, such as the Hands-Free Profile. That can make some attacks noticeable: music may pause, audio quality may drop, or the device may behave as if it has entered a phone-call mode. But this is not a universal rule. The 2022 SiriSpy issue was notable precisely because Rambo started investigating after noticing that Siri audio over AirPods did not show the usual quality drop and the bug allowed Siri and dictation audio to be accessed without the normal microphone-permission flow or visible microphone-use indicator.

Apple is actively hardening this attack surface

It is also important to say clearly: Apple is not ignoring this attack surface.

Apple’s platform security documentation describes Bluetooth security as a layered model for Bluetooth Classic and Bluetooth Low Energy. That model includes pairing, bonding, authentication, encryption, message integrity and Secure Simple Pairing protections against passive eavesdropping and man-in-the-middle attacks.

For Bluetooth Low Energy, Apple also documents privacy features such as address randomization, which helps reduce long-term tracking risks and improves Bluetooth privacy.

Those protections do not eliminate vulnerabilities, but they show that Bluetooth is treated as a security-sensitive part of the platform.

The Beats Studio Buds advisory is best understood in that context. It doesn't claim that the entire Bluetooth model is broken; it doesn't imply that this is an Apple-only story. It shows how wireless audio security depends on several layers at once: the platform, the accessory firmware, the chipset vendor, the Bluetooth stack and the pairing logic that connects them.

It also shows the limits of privacy mechanisms when trust is broken. BLE address randomization is valuable, but if an attacker can establish a bond and extract identity material such as an Identity Resolving Key, the privacy model can be weakened in practice. That is why pairing logic matters as much as encryption or address rotation.

The security cost of seamless audio

Bluetooth is useful because it removes friction: earbuds reconnect automatically, headphones switch between devices, speakers appear quickly and microphones join meetings without cables or configuration.

But that convenience has a security cost.

Every smooth connection hides a decision: should this nearby device be trusted, should this accessory accept a pairing request, should it reconnect silently, should it expose a microphone, should it remember a relationship and should the user be interrupted with a prompt or kept out of the loop?

Good security design tries to make those decisions strict without making the product painful to use. That is a hard balance. If there is too much friction, users complain. If there is too little, trust can become too automatic.

For enterprises, this matters because wireless audio devices now sit inside real workflows: calls, customer conversations, executive meetings, conference rooms, support desks, classrooms and travel. They may not need to be managed like laptops, but they should be included in basic cyber hygiene.

For users, the message is simpler: the devices closest to your conversations deserve the same basic care as the devices in your hands.

What users and organizations should do

For most users, the response is simple: keep earbuds and connected devices updated.

Apple says Beats firmware updates are automatically delivered while the headphones are paired with and in Bluetooth range of an iPhone, iPad, or Mac. Users can check the firmware version in Bluetooth settings by tapping or clicking the information button to the headphones.

The same general advice applies to AirPods and other Apple wireless headphones. Apple gives similar update and firmware-checking guidance for the AirPods and Beats firmware updates that fixed CVE-2024-27867.

For non-Apple wireless audio accessories, the same principle applies, but the update path is often different. Users may need the manufacturer’s companion app, vendor firmware updater, or an operating system update. For Fast Pair accessories affected by WhisperPair-style issues, the relevant fix may come from the accessory vendor rather than from the phone alone, because the vulnerable behavior can live inside the accessory firmware.

Mixed-device environments deserve special attention. Beats Studio Buds and many other wireless headphones are used across iOS android, macOS, Windows and Linux. Some devices update automatically only in certain ecosystems, while others require a companion app or vendor-specific process. That means users and organizations should not assume that "the phone is updated" also means the accessory firmware is updated.

For Beats users on Android, Apple’s Beats User Guide describes the Beats app as the Android update path: users can check the firmware version inside the app and install an available update from the device screen when one is offered.

It is also wise to keep earbuds in the closed charging case when not in use. For CVE-2024-27867, Dreßler specifically noted that the issue was not present while AirPods were inside the closed charging case, or while AirPods Max were inside the Smart Case, because the radio was inactive.

For Beats Studio Buds specifically, the most important step is to update to firmware version 1B211 or later. For unpatched devices, ERNW’s writeup shows why case-opening and power-on moments matter: the pairing window appears briefly after the case is opened, before the owner’s device reconnects. That does not mean users should panic in public places, but it does mean updating the firmware is the right fix.

From a security researcher’s perspective, the practical lesson for organizations is not that every pair of earbuds needs to become a managed asset. The better starting point is simple cyber hygiene: keep phones, laptops, earbuds and headsets updated; avoid pairing new Bluetooth audio devices in crowded or untrusted environments; close the charging case when earbuds are not in use; and pay attention to unexpected pairing prompts, audio routing changes, or unfamiliar connected devices. For security teams, this is also a useful awareness message: the devices closest to our conversations are often the ones employees think the least.

CVE-2025-20701 is easy to dismiss because Apple’s advisory described a narrow condition: Bluetooth range, a specific device state and Beats Studio Buds that were not yet paired and actively seeking pair requests.

But ERNW’s later writeup shows why narrow does not mean irrelevant. A short pairing window can still matter if it appears at the right time, if an attacker is nearby and if one successful race creates a trusted relationship that lasts beyond the first connection.

That gives us a concrete example of a broader security truth: wireless audio accessories are no longer passive objects. AirPods, Beats, Fast Pair accessories, Airoha-based devices and many similar products are microphones, radios, firmware-driven endpoints and trusted companions to phones and laptops.

The takeaway is not to abandon wireless accessories. It is to end the assumption that accessories are passive. As Bluetooth audio devices become more autonomous and feature-dense, their pairing states, firmware update paths and supply-chain origins deserve the same scrutiny as any other endpoint that sits close to sensitive conversations.

Even small edge cases can reveal where the trust boundaries are.

And when the device sits to our conversations all day, those trust boundaries are worth taking seriously.

Apple, " the security content of Beats Firmware Update 1B211."

ERNW / Insinuator, "Beats Studio Buds: Insecure Pairing Window."

Airoha, "Product Security Bulletin 2025."

ERNW White Paper 74, "Bluetooth Headphone Jacking: Airoha RACE Vulnerabilities."

KU Leuven / COSIC, "WhisperPair: Hijacking Bluetooth Accessories Using Google Fast Pair."

Keiichiro Kimura, Hiroki Kuzuno, Yoshiaki Shiraishi and Masakatu Morii, "Stealtooth: Breaking Bluetooth Security Abusing Silent Automatic Pairing."

Apple, " the security content of AirPods Firmware Update 6A326, AirPods Firmware Update 6F8 and Beats Firmware Update 6F8."

Jonas Dreßler, "Do a firmware update for your AirPods - now."

Apple, " the security content of iOS 16.1 and iPadOS 16."

AppleInsider, "Malicious apps could have listened in on Siri conversations."

Dennis Heinze, Jiska Classen and Felix Rohrbach, "MagicPairing: Apple’s Take on Securing Bluetooth Peripherals," WiSec 2020.

Apple Beats User Guide, "Update Beats."

Apple Platform Security, "Bluetooth security."