The disclosure of CVE-2025-20701 affecting Skullcandy Dime 3 wireless earbuds demonstrates how something as ordinary as Bluetooth pairing can become a meaningful security boundary when implemented incorrectly. CERT/CC says Dime 3 model S2DCW units running firmware version 1.0.0.28 accept new Bluetooth Classic pairing requests from previously unpaired devices without requiring the earbuds to be placed into pairing mode and without any physical confirmation from the owner. An attacker only needs to be within Bluetooth radio range and know or discover the earbuds’ Bluetooth address. No PIN, passkey, button press or interaction with the charging case is required. 

The vulnerability originates in the Airoha Bluetooth Audio SDK and is tracked as CVE-2025-20701. CERT/CC describes it as an authentication failure that permits Bluetooth audio devices to pair without user consent, while public vulnerability data rates the issue High severity at CVSS 8.8. Airoha issued updated SDK code in August 2025, and other manufacturers using the same technology have subsequently deployed fixes. Skullcandy says the issue is corrected in firmware version 1.0.0.30.

The security problem is more serious than an unwanted Bluetooth connection. Once an attacker successfully bonds with the earbuds, their device becomes trusted and can automatically reconnect when it comes back within range. CERT/CC says the attacker can establish an A2DP audio connection, interrupt the legitimate owner’s existing connection and hijack audio playback. More concerningly, the attacker can access the Hands-Free or Headset profile and capture live microphone audio.

That microphone capability changes the nature of the vulnerability. What might initially sound like somebody nearby playing unwanted audio can potentially become a local eavesdropping problem. Wireless earbuds increasingly remain connected for long periods during commuting, office work, conference calls and travel. If an unauthorized device can silently become a trusted Bluetooth peer and subsequently access the microphone profile, the security consequences extend beyond inconvenience.

The attacker still needs physical proximity within Bluetooth range, which is an important limitation. This is not an internet-based remote compromise where someone on another continent can hijack the earbuds. But proximity-based attacks can still be realistic in airports, trains, offices, conferences, cafés, universities and other crowded environments where attackers can remain near potential targets without attracting attention.

The lack of required user interaction makes the flaw particularly interesting. Normal Bluetooth security assumes that establishing a new trust relationship is an intentional event. The user places the device into pairing mode, selects it on another device and, depending on the device capabilities, confirms the connection. That sequence establishes consent.

CVE-2025-20701 breaks that assumption.

The attacker can initiate a new pairing while the earbuds are operating normally, without asking the owner to approve it. The only indication may be an audible “new device paired” notification after the unauthorized pairing has already completed. CERT/CC specifically notes that this provides no opportunity for the user to reject the connection before trust is established.

This is a useful example of the difference between notification and authorization. Informing a user after a security-sensitive operation has occurred is not equivalent to requesting permission beforehand. Security decisions involving establishment of persistent trust should normally require an explicit action from the owner before they become effective.

Bluetooth devices with limited interfaces naturally create challenges here. Earbuds typically have no screen, keyboard or conventional input mechanism, so implementations rely on Bluetooth pairing modes and physical actions such as opening a case or holding a button. CERT/CC notes that the affected device advertises a `NoInputNoOutput` I/O capability, which influences how Bluetooth authentication is negotiated.

That hardware simplicity makes the firmware responsible for enforcing the user's intent. If the firmware accepts pairing whenever a remote device asks, the absence of a screen effectively becomes an absence of authentication rather than simply a user-interface limitation.

The persistence aspect also deserves attention. Once the attacker has paired successfully, they do not necessarily need to repeat the exploit every time. The malicious device has been added to the trusted-device list and may reconnect automatically when it comes back into range.

This converts a brief proximity opportunity into a longer-lived trust relationship. An attacker could pair once in a crowded environment and potentially reconnect later whenever the victim comes within range. That is significantly more useful than a one-time interference attack.

For privacy-sensitive users, the microphone issue creates the most obvious concern. Wireless headsets are routinely used during confidential conversations, business meetings and calls. A compromised Bluetooth trust relationship therefore has privacy consequences disproportionate to the apparent simplicity of the device.

The incident is also a useful reminder that modern headphones and earbuds are computers, even if consumers do not think of them that way. They contain processors, firmware, Bluetooth stacks, authentication logic and persistent configuration. Once those components become programmable and network-connected, they acquire the same fundamental security problems seen in routers, cameras, smart televisions and other embedded systems.

But consumers often receive much weaker vulnerability-management capabilities for accessories than they receive for phones or laptops.

That becomes the most concerning part of the Dime 3 disclosure.

Skullcandy says firmware version 1.0.0.30 fixes CVE-2025-20701, but CERT/CC says existing Dime 3 units running version 1.0.0.28 currently cannot be updated by customers through the Skullcandy application. At the time of the CERT advisory, there was no known consumer-accessible mechanism for moving an affected unit from 1.0.0.28 to 1.0.0.30.

This produces a strange vulnerability-management state in which the manufacturer has a patched firmware build but some customers cannot deploy it.

From a security-engineering perspective, firmware update capability should increasingly be considered part of the security architecture of any connected consumer device. Vulnerabilities are inevitable over a product’s lifetime. The question is whether the manufacturer can reliably deliver corrections after those vulnerabilities are discovered.

A device without an effective field-update mechanism effectively freezes much of its security posture at the moment it leaves the factory.

That may have been acceptable decades ago for a simple analog headset.

It is considerably harder to justify for a device running a wireless protocol stack capable of establishing authenticated connections, exposing microphones and storing trusted-device relationships.

The problem is not unique to Skullcandy. CVE-2025-20701 affects the Airoha Bluetooth audio SDK used across products from multiple vendors. BleepingComputer notes that the flaw was originally discovered by ERNW researchers and presented at the TROOPERS conference, and that manufacturers subsequently began integrating Airoha’s SDK correction. Apple, for example, addressed the same underlying issue in Beats Studio Buds through a firmware update released in June 2026.

This demonstrates the supply-chain nature of embedded-device vulnerabilities. A consumer sees a Skullcandy, Beats or other branded headset, but important security behavior may actually originate several layers deeper in a chipset vendor’s SDK. A flaw in that common software component can consequently affect products from multiple manufacturers.

Manufacturers therefore need complete software bills of materials for embedded products, including third-party Bluetooth stacks and SDK versions. When a chipset vendor discloses a vulnerability, product makers should be able to determine quickly which models inherit the vulnerable component and which firmware releases contain the fix.

Just as importantly, the update must actually reach devices already in consumers’ hands.

Publishing fixed firmware for newly manufactured units while leaving older units unable to update creates two security populations bearing the same model name. A customer buying a Dime 3 manufactured after the fix may receive version 1.0.0.30, while someone owning an earlier unit could remain on 1.0.0.28 with no obvious way to remediate it.

That makes vulnerability communication especially important. Consumers need a reliable method to determine their installed firmware version and understand whether their device is affected. Where software remediation cannot be delivered, manufacturers should provide clear alternative guidance, servicing options or replacement policies rather than leaving users to infer their exposure from security advisories.

From a defensive perspective, affected users have relatively limited technical options because the vulnerability exists inside the earbuds themselves. Keeping the earbuds powered off or stored in the case when not required can reduce the window in which an attacker can reach them, and users should treat unexpected “new device paired” announcements as potentially meaningful rather than merely Bluetooth behaving badly again.

If an unexplained pairing notification occurs, users should review paired Bluetooth devices on their phones and computers and reset the earbuds’ stored pairing state if the product supports it. However, these steps reduce exposure rather than correcting the vulnerable authentication logic.

For organizations, the problem becomes more interesting where Bluetooth headsets are used by executives, government personnel, financial professionals or employees handling sensitive calls. It may be appropriate to consider peripheral firmware support and updateability when procuring wireless audio equipment rather than evaluating products solely on cost, sound quality and battery life.

Security-sensitive environments should also recognize that Bluetooth peripherals represent another local radio attack surface. Policies around wireless devices usually concentrate on phones, laptops and Wi-Fi while treating headsets as harmless accessories. CVE-2025-20701 demonstrates that a compromised accessory may itself expose microphones, audio sessions and trusted relationships.

The attack also illustrates why proximity threats should not automatically be dismissed because they lack internet-scale reach. The attacker does not need to compromise millions of devices globally for the vulnerability to be useful. Targeted proximity attacks against one valuable individual can have entirely different economics from mass exploitation.

An attacker interested in corporate espionage, investigative information or a particular individual may be perfectly willing to sit within Bluetooth range for a few minutes if that interaction establishes a persistent trusted connection to a microphone-equipped device.

This is why risk should be assessed according to attacker objectives rather than merely maximum geographic reach.

The vulnerability also raises a broader question about how long connected consumer devices should receive security support. Earbuds increasingly depend on firmware just as smartphones do, yet buyers are rarely told how many years of updates the manufacturer commits to provide.

Security support periods should become a normal product specification for connected devices. Consumers should be able to know whether a device will receive security updates for one year, five years or not at all. The industry has already learned this lesson with phones, routers and smart-home products. Wireless audio devices are now complicated enough that they belong in the same conversation. The broader lesson from CVE-2025-20701 is therefore larger than one pair of earbuds. Pairing establishes trust. Trust should require consent. And any connected device that depends on software to enforce that trust needs a reliable way to fix the software when the enforcement fails. Because a security patch that exists only on newly manufactured devices is not really a remediation for the people who already bought the vulnerable ones. For them, the vulnerability remains sitting quite literally in their ears.

The Carnegie Mellon University CERT Coordination Center (CERT/CC) is warning that Skullcandy Dime 3 wireless earbuds accept Bluetooth pairing requests from nearby unpaired devices without requiring user interaction. [...]

Source: Skullcandy Dime 3 earbuds expose users to Bluetooth hijacking via Bleeping Computer — published 09 Sep 2026.