Earbuds or Fearbuds - Learning About the Earbud Bluetooth Vulnerability

I started reading about a set of Bluetooth earbud vulnerabilities and ended up with one of those uncomfortable reminders that “small” devices are still computers.

These notes are my attempt to understand the issue, based on the material I collected. I am not treating this as a full independent verification or exploit write-up. I am trying to map the idea clearly: how could wireless earbuds become an attack path into a phone?

The short version is unsettling: some earbuds reportedly expose a powerful internal control/debug protocol over Bluetooth without proper authentication. If true for a given device, that means an attacker nearby could potentially read memory, extract Bluetooth trust material, alter firmware behavior, or abuse the earbud as a stepping stone toward the paired phone.

The basic problem

The material I found centers on Airoha Bluetooth System-on-Chips, which are used in many wireless audio products. The notes mention three vulnerabilities:

• CVE-2025-20700
• CVE-2025-20701
• CVE-2025-20702

The core issue appears to involve a proprietary protocol called RACE, described in the notes as Remote Access Control Engine.

My understanding is that RACE is not meant to be a normal user-facing feature. It sounds more like a factory, engineering, or maintenance interface: something useful for configuring hardware, reading or writing device memory, managing flash storage, or performing firmware-related operations.

That kind of interface is not automatically bad. Devices need manufacturing and repair hooks. The danger comes when something that powerful is reachable wirelessly and does not require authentication.

RACE, as I understand it

RACE is part of the Airoha SDK stack used by earbud manufacturers. It seems to provide low-level control over the chip.

The concerning claims are:

• The protocol can be reached over Bluetooth Classic and Bluetooth Low Energy.
• It does not properly authenticate the sender before accepting commands.
• It can allow memory read/write operations.
• It is connected to the firmware-over-the-air update path.

If all of that is true on a vulnerable product, this is not just a “settings bug.” It is closer to leaving a privileged service exposed to anyone nearby.

The phrase that kept coming back to me while reading was: debug interfaces are powerful because they are trusted. If that trust boundary is missing, the interface becomes an attack surface.

Why memory access is such a big deal

At first, “read and write memory” can sound abstract. But for a Bluetooth earbud, memory may contain sensitive pairing material and operational state.

The notes specifically call out Bluetooth link keys.

When earbuds are paired with a phone, the phone and earbuds establish a trusted Bluetooth relationship. That trust is represented by cryptographic material. If an attacker can extract those keys from the earbud, they may be able to impersonate the earbud to the phone.

That is the part that made the issue click for me.

The attacker may not care about the earbud itself. The earbud is useful because the phone already trusts it.

The attack chain in my own words

Here is the mental model I wrote down:

1. A victim has vulnerable wireless earbuds paired to a phone.
2. An attacker gets within Bluetooth range.
3. The attacker sends unauthenticated commands to the exposed RACE interface.
4. The attacker reads sensitive data from the earbud, such as Bluetooth link keys.
5. The attacker uses that trust material to impersonate the earbud or interfere with the phone-earbud relationship.
6. Depending on the device and platform behavior, this could affect audio, microphone access, calls, or data routed through the trusted Bluetooth connection.

This diagram from my notes captures the idea well:

The firmware update angle

Another part of the notes that stood out to me is the FOTA angle: firmware over the air.

Firmware update systems are already high-impact code paths. They decide what software the device is allowed to run. If firmware update functionality is reachable through the same unauthenticated control protocol, the risk becomes much larger.

The material suggests that malformed or custom firmware could potentially be pushed to a vulnerable device. It also raises the possibility of worm-like behavior, where a compromised Bluetooth device scans for other nearby vulnerable devices and attempts to compromise them too.

I want to be careful here: “wormable” is a strong claim, and whether it is practical depends on implementation details, radio behavior, exploit reliability, and patch status. But architecturally, I can see why researchers would worry about it. And can you blame them? I mean Are you f😡ing kidding me! Earbuds are mobile, always near people, and often powered on in dense spaces like trains, airports, offices, and conferences.

Why this feels different from a normal app bug

A phone app usually lives inside layers of platform security:

• app sandboxing
• permission prompts
• OS updates
• app store review
• user-visible settings

Earbuds do not feel like that. They are tiny embedded systems with radios, microphones, firmware, persistent pairing state, and limited user visibility.

Most people do not think about them as computers. I usually do not either. They feel like accessories.

But from a security perspective, they are trusted Bluetooth endpoints sitting very close to our body and our phone. That combination matters.

What I am taking away

My personal notes from this are less about panic and more about threat modeling.

A few takeaways:

• Bluetooth accessories should not be treated as harmless just because they are small.
• Factory/debug protocols need strong authentication, especially if reachable over wireless transports.
• Pairing keys are extremely valuable because they represent established trust.
• Firmware update mechanisms are high-risk and should be tightly protected.
• Supply-chain SDK decisions can affect many downstream brands at once.

The supply-chain part is especially important. If many vendors build products using the same chip vendor SDK, one insecure default can become a broad ecosystem problem.

Questions I still have

I still have questions I would want answered before drawing stronger conclusions:

• Which exact consumer products are STILL affected?
• Which firmware versions are still vulnerable?
• Are patches available, and how reliably do earbuds receive them?
• Do all affected products expose the same RACE functionality over Bluetooth?
• How practical is link-key extraction across different phone platforms?
• What mitigations exist if a user cannot update the earbuds?

Those details matter. A scary architectural issue becomes a practical risk only when we know the affected devices, exploit conditions, and available fixes.

Small practical habits

Until I understand more, the practical habits I would consider are simple:

• Keep earbud firmware updated through the official vendor app, if available.
• Avoid using unknown or abandoned wireless earbuds for sensitive calls.
• Unpair and reset devices before selling or giving them away.
• Be cautious with cheap or no-name Bluetooth accessories that may never receive firmware updates.
• Check whether the manufacturer publishes security advisories or firmware release notes.

None of this is perfect. The frustrating part with embedded devices is that users often have very little visibility or control.

Final thought

The big lesson for me is that trust does not stop at the phone. Once a device is paired, it becomes part of the phone’s trusted environment.

Wireless earbuds may look simple from the outside, but inside they are radios, firmware, memory, microphones, update systems, and cryptographic keys. If a privileged interface is exposed without authentication, that tiny accessory can become a much bigger security problem than it appears.

References

• Uploaded diagram: Screenshot_20260704-182055.png
• Low level
• hacker news
• hacker news
• Insinuator.net