The flaw was not in Sony’s headphones or Bose’s. It was in a chip both of them bought, and a debug interface that asked for no password

The German security firm ERNW disclosed vulnerabilities affecting headphones and earbuds from Sony, Bose, JBL, Jabra, Marshall and others — confirmed models including the Sony WH-1000XM6 and LinkBuds S, the Jabra Elite 8 Active, Bose QuietComfort Earbuds, and JBL Live Buds 3.

That list reads like a flaw found independently in half a dozen companies. It was not. It is one flaw, in one component, that all of them bought.

What was found

The vulnerable part is a Bluetooth system-on-chip made by Airoha, and specifically a custom debugging protocol present in Airoha's reference software development kits — the code a chipmaker supplies so that device manufacturers can build products around the chip.

Three things make it serious:

1. The protocol is exposed over both Bluetooth Low Energy and Bluetooth Classic, so it is reachable over the air.
2. It has no authentication whatsoever. Not weak authentication — none.
3. It allows reading and writing the device's RAM and flash, without pairing.

The issues are tracked as CVE-2025-20700, CVE-2025-20701 and CVE-2025-20702.

What an attacker in range can do

Reading and writing memory on a pair of earbuds sounds abstract until you follow what the earbuds are connected to.

The headphones hold an established trust relationship with your phone. An attacker who controls the headphones can use that relationship: researchers demonstrated retrieving call history and contacts from the paired handset, and — because these devices contain microphones — turning them into a listening device.

That last capability is what makes this a different category of bug from most Bluetooth issues. The attack surface is a thing you wear on your head, in public, within radio range of strangers all day.

The part worth generalising

A debugging interface left reachable in a shipped product is one of the oldest mistakes in embedded engineering. What makes this instructive is where the mistake was made.

No brand on that list wrote the flawed code. Each bought a chip, built on the vendor's reference SDK as intended, and shipped. The result is a single defect replicated across competing products in a way no individual company's security review would catch — because each firm is auditing its own work, and the problem is underneath it.

This is the same shape as supply-chain vulnerabilities in software libraries, and it has the same consequence: the number of affected devices is set by the component's market share, not by any one manufacturer's practices. Users cannot assess it, because nothing on the box says which Bluetooth chipset is inside.

What to do about it

Realistically, less than one would like.

1. Update firmware through the manufacturer's companion app. This is the actual fix, and it requires the brand to have pushed a patched build — which has varied considerably across the affected list.
2. Turn Bluetooth off when not in use, which removes the exposure entirely and costs nothing.
3. Treat the pairing list on your phone as worth pruning: fewer trusted devices, less to inherit.

And keep the proportion right. This requires an attacker physically within Bluetooth range who is targeting you specifically. It matters a great deal if you have reason to think someone is; for most people it is a reason to install the firmware update and move on.

Sources: ERNW's disclosure; Airoha; the CVE records; Heise; BleepingComputer; CyberInsider; and Prothom Alo's original report.