In December, researchers Dennis Heinze and Frieder Steinmetz published the full technical writeup and a working exploit toolkit for a set of Bluetooth flaws they’d found in Airoha’s chipsets, the silicon inside headphones from Sony, Bose, JBL, Marshall, Jabra, and about two dozen other brands. The bugs let an attacker within about 10 meters connect to a pair of headphones over BLE with no pairing and no user interaction, pull the Bluetooth link key out of memory, and use it to impersonate the headphones to the owner’s phone. From there they can place calls, read contacts, trigger the voice assistant, or just quietly dial a number and listen through the microphone.
None of that is new information exactly. Airoha shipped a patch to its partners back in June 2025. What’s new is that the exploit is no longer theoretical or locked behind two research papers. It’s a toolkit anyone can run. And a large share of the 29 affected products are, as of this writing, still shipping the vulnerable firmware.
The patch existed for a year. Most devices never got it.
This is the part that should bother anyone building connected hardware, not the vulnerability itself. Chip-level bugs happen. What’s damning is the distribution problem sitting on top of it: Airoha handed vendors a fix over a year ago, and getting that fix onto an actual pair of headphones on someone’s head required the owner to open a companion app they installed once during setup and have not touched since. Apple got a Beats fix out in June 2026, a full year after the patch was available. Plenty of other brands still haven’t.
Firmware updates for connected devices almost always route through a phone app, because that’s the only interface most of these products have. No screen, no keyboard, no way to check for updates on their own. Which means the app isn’t a nice-to-have feature layered on top of the hardware. It is the entire security perimeter. If nobody opens it, nothing gets patched, and the CVE writeup two engineers spent a year responsibly disclosing sits unread while the exploit code goes public.
The app that ships with a chip reference design is not a product
Here’s where this connects to something we see constantly in our own mobile and connected device work. A lot of BLE hardware companies build their companion app on top of whatever reference implementation the chip vendor hands them, because it’s free and it pairs the device on day one. That reference app was built to demo a chipset, not to run a fleet of devices in the field for five years. It usually has no persistent background scanning for firmware versions, no push notification path when a critical patch lands, and no telemetry telling the manufacturer how many units in the wild are still on vulnerable firmware. Nobody designed an update strategy. They shipped a pairing wizard and called it done.
That gap doesn’t show up in a demo. It shows up eighteen months later when a security researcher publishes a toolkit and a journalist asks your support team how many customers are still exposed, and the honest answer is nobody knows.
What treating firmware delivery as a real feature looks like
If you’re building or maintaining a product with a BLE companion app, this is a good moment to check a few things that are easy to skip under a launch deadline.
Push a background check for firmware version on every app open and on a schedule, not only when the user manually looks for it. If the app can hold a BLE connection long enough to sync steps or play audio, it can hold one long enough to check a version number.
Treat a critical security patch differently from a feature update. A silent, minimal firmware push with a required confirmation is a different flow than “update available, tap to install,” and most apps only build the second one.
Instrument it. If you can’t tell your CEO what percentage of active devices are running the last three firmware versions, you don’t have a patch story, you have a hope.
Don’t let the update path be an afterthought bolted onto a chip vendor’s sample app. Decide, on purpose, whether users get notified, whether updates are forced, and how long a device can go dark before someone finds out.
This is a build decision, not a security checklist item
We’d push back on the framing that this is purely a security team’s problem to solve after the fact. The moment you choose to build a product around a BLE chipset and a phone app, you’ve made an architectural bet on how software gets onto that hardware for the life of the product. Get that bet wrong and even a responsibly disclosed, patched, year-old bug turns into exposure for millions of real people, because the update mechanism nobody designed never delivered it.
It’s a version of the same argument we make about custom software development generally: the parts of a product that look like plumbing, the update pipeline, the background sync, the notification logic, are exactly the parts that determine whether the rest of the product is trustworthy six months after launch. A demo app from a chip vendor will get you to market. It won’t get a security patch onto a device that’s already in someone’s pocket.
If you’re building a connected product and aren’t sure your firmware and app update path can actually reach your installed base when it matters, get in touch. It’s a cheaper conversation to have before the exploit toolkit is public than after.