Apple Patches Beats Studio Buds Microphone Vulnerability (CVE-2025-20701)

Apple's firmware update for the Beats Studio Buds closes a high-severity Bluetooth microphone flaw — verification work for organizations issuing the device.

CUPERTINO, CALIFORNIA — Apple on June 16, 2026 published a security advisory and released Beats Firmware Update 1B211, closing a high-severity Bluetooth vulnerability in the Beats Studio Buds that an attacker within wireless range could use to eavesdrop through the earbuds' microphone. Tracked as CVE-2025-20701 and carrying a CVSS score of 8.8, the flaw lets an unauthorized device listen through a Studio Buds unit that is not yet paired and is actively seeking pair requests. Apple framed the issue as a vulnerability in open-source code that its firmware incorporates, and reported no evidence of exploitation in the wild.

The disclosure is a vendor-patch story rather than a breach, but the underlying defect is notable for where it lives. The weakness sits in the Airoha Bluetooth audio system-on-chip software used across the consumer-audio industry, so the same flaw reaches roughly 30 products from other vendors — which turns a single earbud advisory into a broader hardware-supply-chain and patch-verification question for any organization that has handed the device to its staff.

What Apple Disclosed

In its support document titled "About the security content of Beats Firmware Update 1B211," Apple described the impact plainly: "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." The company assigned the issue CVE-2025-20701 and noted that the identifier was assigned by a third party, because the underlying defect lives in open-source code that Apple's software is among the affected projects to incorporate.

Independent reporting by Ars Technica traced that code to the Airoha Bluetooth audio software development kit (SDK), the firmware that runs on the Bluetooth system-on-chip inside the Studio Buds. The flaw is an incorrect-authorization weakness: in the vulnerable state, the earbuds do not adequately verify that a device requesting a connection is one they should trust, which allows a nearby device to pose as a trusted endpoint and gain access to the microphone of a unit that has not yet completed pairing. The vulnerability was reported to Apple by Dennis Heinze and Frieder Steinmetz of ERNW GmbH, the German security firm that has documented the Airoha chip issues, and carries a CVSS score of 8.8, placing it in the high-severity band.

Apple's advisory lists the affected product specifically as the Beats Studio Buds and the fix as Beats Firmware Update 1B211, released June 16, 2026. Because the defect originates in a shared chip platform rather than in Beats-specific code, the same class of flaw reaches well beyond Apple's earbuds: reporting by The Hacker News indicates roughly 30 audio products from vendors including Sony, Bose, JBL, Marshall, and Jabra are affected by issues in the same Airoha software, with several of those vendors shipping their own updates through companion apps or support pages.

Defender Posture for Organizations Issuing the Device to Employees

For most consumers, the story ends with an automatic update. For organizations that issue Beats Studio Buds to employees — or that simply have them in circulation among staff devices — the advisory is better read as a small inventory-and-verification task than as an emergency. The realistic exposure is bounded: exploitation requires physical proximity within Bluetooth range and a unit that is unpaired and actively advertising for a connection, which is the state a fresh or recently reset device is in before it has been bound to a phone or laptop.

That bounded threat model is worth stating clearly, because it shapes the response. This is not a remotely exploitable, internet-reachable flaw of the kind that drives same-day patch mandates; it is a proximity-gated eavesdropping risk against a specific, transient device state. The defender's interest is less about racing a vulnerability clock and more about confirming that the fix has actually reached the hardware in the field, since the failure mode here is silent: an out-of-date unit looks and works identically to a patched one.

The practical concern is highest where the device's microphone meets sensitive environments — earbuds worn into meetings, used on calls that discuss non-public information, or issued to staff who travel. In those settings the question is not whether a patch exists, but whether each unit in the estate has received it, and whether any units sitting in drawers, awaiting handout, or shared between users have been brought online recently enough to update.

Firmware-Update Guidance

Apple's remediation is to move every Beats Studio Buds unit to Beats Firmware Update 1B211. The mechanism is the same one Apple uses for AirPods and other Beats hardware: the firmware is delivered automatically over Bluetooth while the earbuds are paired with, and in range of, an iPhone, iPad, or Mac. There is no separate Beats companion app to open and no manual "install" button to press — the update arrives in the background, which is convenient for individuals but means an organization cannot assume a unit is current simply because a fix shipped.

Verification is therefore the operative step. Apple documents how to read the installed firmware version: on an iPhone or iPad, open Settings > Bluetooth, then tap the information button next to the headphones; on a Mac, open System Settings > Bluetooth and select the info control beside the device. Confirming that a unit reports firmware 1B211 (or later) is the only reliable way to know it is no longer exposed. Because the update requires the earbuds to be paired and in range of an Apple device, units that are stored, unpaired, or only ever connected to non-Apple hardware may not have updated at all — and those are precisely the units most likely to be in the vulnerable, unpaired-and-advertising state the flaw targets.

For an organization, a lightweight process covers the gap: enumerate where Studio Buds have been issued, ask holders to pair each unit with their managed iPhone, iPad, or Mac and confirm the version reads 1B211, and pay particular attention to spare or pooled units that change hands. Where the same Airoha software underpins other audio brands in the fleet, the same logic applies — check each vendor's advisory and companion-app or support-page update path, rather than assuming a single firmware push has covered the whole inventory.

Open Questions

Several points remain worth tracking. Apple reported no evidence that CVE-2025-20701 has been exploited in the wild, and the proximity precondition makes opportunistic mass exploitation unlikely; the more realistic concern is targeted use against a specific person within range. How the various non-Apple vendors sharing the Airoha platform stagger their own fixes — and how completely those updates reach already-sold hardware that may rarely connect to an updating app — is the larger open variable, since a flaw in a shared chip is only as patched as the slowest vendor and the least-connected device.

What is confirmed is enough to act on. A high-severity, CVSS 8.8 authorization flaw in the Beats Studio Buds allowed a nearby device to listen through the microphone of an unpaired unit, Apple has shipped a fix in firmware 1B211, and the same underlying Airoha defect spans a wide swath of the consumer-audio market. For organizations issuing the device, the durable response is not alarm but verification: confirm the firmware version on every unit, fold connected peripherals into the same asset and patch-tracking discipline applied to phones and laptops, and treat a microphone-bearing accessory as exactly the kind of endpoint that warrants it.

The CyberSignal Analysis

The reported facts above are Apple's advisory and independent reporting; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — Peripherals Are an Attack Surface, Not an Accessory

The instinct with a wireless-earbud advisory is to file it under consumer hardware and move on, and that instinct is the exact gap worth closing. A pair of Beats Studio Buds carries a microphone into the same meetings, calls, and travel where an organization already governs its phones and laptops — yet peripherals almost never inherit the asset inventory, patch tracking, or ownership discipline applied to those primary devices. Our reading is that the defect matters less than the category lesson: a microphone-bearing accessory is an endpoint, and treating it as furniture is how a listening device ends up in a sensitive room with nobody accountable for its firmware.

The practical consequence is that the response to this advisory should not live in a consumer-support workflow but in the same fleet-management posture that covers managed hardware. Enumerate where the devices were issued, fold them into the inventory, and assign the update-verification task an owner. The point is not this single CVE; it is that the next peripheral flaw lands on an organization that either already tracks the accessory or discovers it has no idea where its microphones are.

Signal 02 — A Shared SDK Turns One Advisory Into a Supply-Chain Problem

The most consequential detail is that the flaw does not belong to Beats. It lives in the Airoha Bluetooth audio SDK, third-party code that Apple's firmware merely incorporates, which is why the same weakness reaches roughly 30 products across Sony, Bose, JBL, Marshall, Jabra, and others. Our assessment is that this is the shape defenders should recognize: a single shared component silently propagates one defect across an entire product category, and an inventory organized by brand name will systematically miss the real unit of exposure, which is the chip platform underneath.

That reframing changes the remediation question from "did we patch the Beats" to "which of our audio devices ride the same Airoha software, and has each vendor shipped and delivered its own fix." A shared-SDK flaw is only as patched as the slowest vendor and the least-connected device, so bounding it means mapping the fleet to the underlying platform rather than to the label on the box — the same discipline that software teams apply to a vulnerable dependency buried in a bill of materials.

Signal 03 — Silent Auto-Updates Create an Assurance Gap, Not Assurance

Apple delivers this firmware automatically over Bluetooth, in the background, with no companion app and no install button — which is convenient for a consumer and quietly dangerous for an organization. The failure mode is that an out-of-date unit looks and behaves identically to a patched one, and the update only lands when the earbuds are paired with and in range of an updating Apple device. Units sitting in drawers, awaiting handout, shared between users, or only ever connected to non-Apple hardware may never update at all — and those are precisely the units most likely to be in the unpaired-and-advertising state the flaw targets.

Our conclusion is that a silent auto-update mechanism shifts the defender's job from triggering the fix to proving it arrived. The only reliable signal is the installed firmware version, so verification — reading that each unit reports 1B211 or later — is the actual control here, not the existence of the patch. An organization that trusts "it updates automatically" without confirming the version has assurance on paper and an exposure gap in the field.

Sources