> 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.

Uh totally, I can't believe how much support Gadgetbridge has - wow thanks for the reminder. I'd love to use that on Linux eventually.

> Glad this submission is finally receiving upvotes.

Speaking for myself, I have very little patience for technical videos, so I don't believe I've ever upvoted a YouTube submission.

I would read it if it was an article of identical length!

One second thought I think this is called a transcript...

---

Edit: Auto-Transcript! (No timestamps, sorry)

https://jsbin.com/jiqihuveci/edit?html,output

This is a good article: https://insinuator.net/2025/12/bluetooth-headphone-jacking-f...

Just throw the link into Gemini and ask for a brief summary :-))

> This includes firmware dumps, user preferences, Bluetooth Classic session keys, current playing track, ..

That doesn't sound very serious if they're exposed, is it? Can it be used to eavesdrop my conversation if I'm speaking through the headphone

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.

This attack was not silent, it was noisy. They specifically pointed that out in their talk.

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.

presumably, even in hands-free mode the attacker needs to be very close to the speaker to hear it

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.

Finally, a coherent explanation of AirPods glitches ;)

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?

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.

I haven't read the whitepaper, but surely the ROM wouldn't include its own private signing keys. Is it maybe encrypted instead of signed?

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.

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.

[0] https://en.wikipedia.org/wiki/Tempest_(codename)

[1] https://en.wikipedia.org/wiki/Van_Eck_phreaking

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.

Thanks!

> 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].

[1] https://play.google.com/store/apps/details?id=pro.vitalii.an...

[2] https://github.com/kavishdevar/librepods/tree/main

[3] https://issuetracker.google.com/issues/371713238

Cool! Can you play audio to them too? That would be a practical joker's dream lol.

I'm not surprised Jabra acted quickly. They mainly sell too enterprise which generally care very much about security. Sony is more a consumer mfg now.

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:

Blog: https://insinuator.net/2025/12/bluetooth-headphone-jacking-f...

Paper: https://ernw.de/en/publications.html

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.

You can't change the device class.

It would be an vulnerability on the host stack to accept that.

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.”

https://www.aol.com/kamala-harris-warns-against-wireless-150...

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]

[0]: https://dl.dod.cyber.mil/wp-content/uploads/stigs/pdf/2016-0...

>I doubt this was ever classified information.

The classified part would be the intelligence that the wireless protocol is compromised. I don't see that in your document.

That's not intelligence, just a precaution.

A precaution presumably based on intelligence. The (presumed) intelligence that the wireless protocol is compromised. As I said before.

Literally common sense since the beginning of wireless communications and coms in general.

> WH1000-XM6

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.:

* https://www.amazon.com/dp/B07W3GGRF2

* https://www.amazon.com/dp/B00BJ17WKK

Maybe the XM7 will have it (along with wired audio controls) via a CTIA/AHJ TRRS plug:

* https://en.wikipedia.org/wiki/Phone_connector_(audio)#TRRS_s...

or via USB audio.