Glad this submission is finally receiving upvotes.
This was just shown at the 39C3 in Hamburg, few days back.
Common (unpached) Bluetooth headsets using Airoha's SoCs can be completely taken over by any unauthenticated bystander with a Linux laptop. (CVE-2025-20700, CVE-2025-20701, CVE-2025-20702)
This includes firmware dumps, user preferences, Bluetooth Classic session keys, current playing track, ...
> Examples of affected vendors and devices are Sony (e.g., WH1000-XM5, WH1000-XM6, WF-1000XM5), Marshall (e.g. Major V, Minor IV), Beyerdynamic (e.g. AMIRON 300), or Jabra (e.g. Elite 8 Active).
Most vendors gave the security researchers either silent treatment or were slow, even after Airoha published fixes. Jabra was one of the positive outlier, Sony unfortunately negatively.
What is exciting, even though the flaws are awful, that it is unlikely for current generation of those Airoha bluetooth headsets to change away from Aiorha's Bluetooth LE "RACE" protocol. This means there is great opportunity for Linux users to control their Bluetooth headsets, which for example is quite nice in an office setting to toggle "hearthrough" when toggling volume "mute" on your machine.
I feel like this should receive state-level attention, the remote audio surveillance of any headset can be a major threat. I wonder what the policies in countries official buildings are when it comes to Bluetooth audio devices, considering that Jabra is a major brand for conference speakers, I'd assume some actual espionage threats.
One of the researchers here.
Many people seem to prefer text to videos, which I sympathize with.
So please excuse me hijacking the top comment with links to our blog post and white paper:
Did you look into whether the spoofed device can also be "upgraded" to be used as an HID device, like a mouse or keyboard? That upgrade would be several CVEs against the OS vendors.
That would make the attacks potentially silent, since the attacked could simulate keypresses to dismiss notifications, or can at least keep the target unable to respond by spamming home/back or pressing power and simulating a swipe to shutdown.
I believe this would in any case require repairing and the new functionality would be visible in the pairing UI? I would be surprised if a device once paired as a headset can suddenly start acting like a keyboard if it feels like it.
EDIT: Covered in the talk at 33min. No keyboard but the Hands-Free Profile would allow you to place calls and interact with a voice assistant if one is enabled.
Kamala Harris, citing seemingly classified intelligence, famously raised the alarm on Bluetooth earphones to Stephen Colbert:
“I know I've been teased about this, but I like these kinds of earpods that have the thing [pointing to the wire] because I served on the Senate Intelligence Committee. I have been in classified briefings, and I'm telling you, don't be on the train using your earpods thinking somebody can't listen to your conversation.”
I doubt this was ever classified information. It's written all over DoD and NSA requirements and best practices for staff and diplomats.
She was probably briefed repeatedly about this as a member of that committee.
Here's one example:
> Headphones are wired headphones (i.e. not wireless) which can be plugged into a computing device to listen to audio media (e.g. music, Defense Collaboration Services, etc.).[0]
> This means there is great opportunity for Linux users to control their Bluetooth headsets, which for example is quite nice in an office setting to toggle "hearthrough" when toggling volume "mute" on your machine.
Fun fact: There are at least two applications that reverse engineered AirPods' communication protocol for custom controls - AndroPods from 2020 [1] and LibrePods from 2024 [2].
But... mainstream Android has a bug open in their Bluetooth stack for well over a year now that prevents issuing the commands, meaning to actually use the app you need root rights [3].
Is this an unintentional vulnerability or is it one of those "we left it open because it's easier and we hoped nobody would notice" kind of things. I mean can you just send a "update to this firmware" command completely unauthenticated and it's like "yep sure"? No signing or anything?
IMO, it's plausible that Airoha and the OEMs did not know about this. The tooling may have been written in a pseudo-secure manner, i.e. requiring pairing (on the client side) before attempting all the debugging/firmware update commands. The tools may simply assume that pairing is required or only list targets from those that are paired and connected, which gives the illusion that the air protocol requires this.
All it really takes is some engineer missing an if-statement to check that the connection is bonded before processing the packets.
According to the details in their whitepaper, firmware is signed, but the management protocol allows reading arbitrary memory, so you can read out the keys and sign your own payload.
I'm not sure anyone intentionally did this, but there were several poor decisions involved. It sounds like the upstream vendor shipped sample code without auth, assuming implementers would know they needed to secure a privileged device management interface, and said implementers just copied the sample and shipped it.
> Most vendors gave the security researchers either silent treatment or were slow, even after Airoha published fixes. Jabra was one of the positive outlier, Sony unfortunately negatively.
While I don't recall Sony issuing an advisory, I believe the users of their app would have started getting update notifications since they (quietly) released firmware updates.
> This means there is great opportunity for Linux users to control their Bluetooth headsets, which for example is quite nice in an office setting to toggle "hearthrough" when toggling volume "mute" on your machine.
I think most vendors are using custom services with their own UUIDs for settings such as this.
Regardless, I believe there are open client implementations for some of the more popular devices. Gadgetbridge comes to mind in regards to Android, not sure about any Linux equivalent.
These (and others?) actually have a wired option (even provide the cable) for listening. Sadly the built-in microphone doesn't work in 'wired mode' (though ANC does).
You could get at at "cable boom microphone", e.g.:
They also demonstrated how this could be used to silently find out someone’s phone number and then hijack a TFA validation call from an app like WhatsApp to take over their account with no user interaction.
Right, but isn't it noisy ... at the headphone level? (i.e. not heard when not wearing them?).
What I'm getting at is that I think the risk varies depending on how often you leave the headset paired; for example, if the headphones are over-ear, those are more prone to not be turned off --- and remain connected; thus, a greater chance of success for establishing a BlueTooth classic connection without getting noticed and performing the WhatsApp account take-over until they listen to "I'm gonna take a shower, honey!" in the distance.
the session (or pairing key) means you can both connect to the headphone or impersonate it.
It can toggle the hands-free mode and listen to whatever is being talked, you'd notice that it has switched to the mode though - but if you're headphones are powered on and you're not listening to in they can be used for eavesdropping.
During the talk they both demonstrate listening to the microphone and also receiving a WhatsApp 2FA call.
If you have a Bluetooth analyzer (e.g. Ellisys), then the link key and a directional antenna is all you need to passively eavesdrop on a conversation at a distance.
Of course, even regular omnidirectional Bluetooth antennas are plenty to eavesdrop through a hotel room door, from the hallway outside a conference room, etc.
An attacker can also passively record all the packets in an area (Ellisys allows recording all channels at the same time), and then actively gather link keys using this attack at any time to decrypt the stored conversations.
Remote audio surveillance probably be accomplished on wired headphones with TEMPEST [0]/Van Eck phreaking [1]. Not sure about which has a better range and which would be stealthier - TEMPEST or the Bluetooth attack. The Bluetooth attack just requires a laptop. Not sure if the TEMPEST attack would require a big antenna.
Even if the TEMPEST were easier, it's significantly less powerful, as it's not going to get you the ability to write malicious firmware to the audio device nor a persistent connection to the host device when the audio device isn't connected.
I doubt that audio-spectrum RF/magnetic frequencies emanate strongly from wired headphones. They are simply not a long enough antenna at 200-3,000 Hz. Also, the loop area is quite low. The ground wire runs parallel to the L/R wires, so the only loop to receive is the magnetic coils in the headphones, which are small. Only near field would work, IMO.
This was just shown at the 39C3 in Hamburg, few days back.
Common (unpached) Bluetooth headsets using Airoha's SoCs can be completely taken over by any unauthenticated bystander with a Linux laptop. (CVE-2025-20700, CVE-2025-20701, CVE-2025-20702)
This includes firmware dumps, user preferences, Bluetooth Classic session keys, current playing track, ...
> Examples of affected vendors and devices are Sony (e.g., WH1000-XM5, WH1000-XM6, WF-1000XM5), Marshall (e.g. Major V, Minor IV), Beyerdynamic (e.g. AMIRON 300), or Jabra (e.g. Elite 8 Active).
Most vendors gave the security researchers either silent treatment or were slow, even after Airoha published fixes. Jabra was one of the positive outlier, Sony unfortunately negatively.
What is exciting, even though the flaws are awful, that it is unlikely for current generation of those Airoha bluetooth headsets to change away from Aiorha's Bluetooth LE "RACE" protocol. This means there is great opportunity for Linux users to control their Bluetooth headsets, which for example is quite nice in an office setting to toggle "hearthrough" when toggling volume "mute" on your machine.
RACE Reverse Engineered - CLI Tool: https://github.com/auracast-research/race-toolkit
I feel like this should receive state-level attention, the remote audio surveillance of any headset can be a major threat. I wonder what the policies in countries official buildings are when it comes to Bluetooth audio devices, considering that Jabra is a major brand for conference speakers, I'd assume some actual espionage threats.