WhisperPair — one tap to pair, zero clicks to hijack.

Seppe Wyns, Sayon Duttagupta and colleagues (KU Leuven COSIC and DistriNet) analysed Google Fast Pair, the one-tap Bluetooth pairing feature used by Sony, JBL, Bose and many others. Their finding, WhisperPair: the protocol says an accessory must only accept a pairing request while it is in pairing mode, but a large share of real products never enforce that check. Of 25 devices from 16 vendors, 68% were vulnerable to hijack, including Google's own Pixel Buds Pro 2. An attacker within Bluetooth range can pair with the accessory in about ten seconds without any user interaction, then control audio and microphones, and in some cases bind the device to their own account for covert location tracking. The fix requires accessory firmware updates. The work goes to IEEE S&P 2026.

Post 22 of my Black Hat Asia 2026 series. The issue was reported to Google in August 2025, rated critical, and disclosed after an extended 150-day window; patches ship as accessory firmware. I explain the design flaw and the response, not an attack procedure.

1. What Fast Pair does

Classic Bluetooth pairing is clumsy: put the accessory in pairing mode, scan, select, confirm. Fast Pair makes it one tap by bridging two Bluetooth technologies: it uses Bluetooth Low Energy (BLE) to exchange setup messages and then performs a normal Bluetooth Classic (BR/EDR) pairing. In Fast Pair terms the accessory is the Provider and the phone is the Seeker.

1. The Provider advertises a 24-bit Model ID when it wants to be paired.
2. The Seeker fetches that model's public key from a Google service. Every model has one hard-coded key pair.
3. The two establish an encrypted channel using an elliptic-curve key exchange.
4. The Seeker sends an encrypted pairing request.
5. The Provider replies with its Bluetooth Classic address.
6. The Seeker starts a Classic pairing, and the passkeys are compared over the BLE channel to confirm.

2. The pairing-state predicate

A Bluetooth device normally accepts new pairings only in pairing mode, usually triggered by a physical button. That physical trigger is the user's expression of intent: "yes, I want to pair right now."

Fast Pair complicates this. To let your already trusted phones reconnect easily, a Provider can accept requests encrypted with an account key without being in pairing mode. The consequence is that the Provider is always advertising and the Fast Pair service is always available. That is convenient, but it raises the stakes on the rule that decides which requests are allowed. The specification defines that rule, and the researchers call it the pairing-state predicate: a request that is not account-key based must be rejected unless the Provider is in pairing mode.

3. Impact

Hijacking

A nearby attacker can complete a pairing without permission and gain full control of what the accessory can do: play media, change volume, activate microphones, and use device-specific features such as noise cancelling or device switching. Practicality is what makes it serious:

• Zero-click: the victim does nothing. The accessory only needs to be powered on.
• Fast: about ten seconds, at realistic distances (the authors tested up to 14 m).
• Everywhere people are: public transport, cafés, parks. The attacker only needs to be in range.
• Cannot be disabled: Fast Pair is a property of the accessory firmware, so non-Android users (including iPhone users) are equally affected.
• Subtle: most devices play a brief audible cue, and the event resembles a normal disconnect and reconnect.

Covert location tracking

Fast Pair accessories can also join Google's crowdsourced Find Hub network. The first account key set on an accessory becomes its permanent Owner Account Key, removable only by factory reset. A device never linked to an Android phone (for example one used only with an iPhone) has no owner key yet. Because the missing-pairing-mode check also lets an attacker write that first key, the accessory can become bound to the attacker's account, and nearby Android devices then report its location to the attacker. The victim's anti-stalking protections are the standard defence, but the researchers note a wrinkle: the resulting warning can appear as if the victim's own device is the unwanted tracker, which is confusing and easy to dismiss.

4. Evaluation

5. Root cause: a broken compliance chain

The same class of failure appeared across multiple vendors and chipset families, which points to a systemic problem rather than one sloppy implementation. Vendors adopt Fast Pair through a three-stage workflow defined by Google:

1. Implementation by chipset and accessory vendors.
2. Validation with Google's validator app and reports.
3. Certification through approved conformance testing.

The researchers found security-critical failures in all three stages: the flaw was implemented, not caught by validation, and not caught by certification. A security requirement that is only stated in a specification, and only checked by tests that do not exercise the negative case, is easy to skip.

6. IntentPair: fail closed by design

The authors propose a small protocol change, IntentPair. The accessory advertises a nonce that is bound into the session key derivation, so that the pairing intent is cryptographically bound rather than trusted to a state flag. The goal is to fail closed: a request made without the intent-bound material simply does not decrypt, so an implementation cannot accidentally accept it. That reduces reliance on vendor-specific enforcement, in line with the guidance to fix problems "at the top" rather than in dozens of downstream products.

7. Disclosure and remediation

• Reported to Google in August 2025, rated critical, with a $15,000 bounty.
• Because partners had to be notified and firmware built, the disclosure window was extended to 150 days.
• The fix lives in the accessory firmware, so users must update through the manufacturer's app, which is often obscure and rarely done.

That last point is the practical gap: updating earbuds is not a habit for most people, so vulnerable devices will persist for a long time.

8. What you can do

1. Update your headphones and earbuds using the manufacturer's app and check for firmware notes about Fast Pair.
2. If you hear an unexpected connect sound or your accessory behaves oddly, treat it as suspicious and check paired devices.
3. Pay attention to tracker alerts on your phone, even if they name your own accessory.
4. Factory-reset a suspect accessory and re-pair it (a reset also clears an attacker's owner key).
5. Vendors: add negative tests for pairing-mode enforcement to your validation suite, and consider the IntentPair approach.
6. Standards bodies and certifiers: test the negative case (must-reject conditions), not only the happy path.

Takeaways

• Fast Pair's convenience keeps accessories always advertising, making the pairing-mode check the key security control.
• Many vendors did not enforce it: 68% of 25 tested devices were hijackable, including a Google product.
• Impact: zero-click hijack in ~10 s at 14 m, audio and microphone control, and covert Find Hub tracking.
• The failure spans implementation, validation and certification: a compliance-chain problem.
• Fail closed by design (IntentPair) beats relying on every vendor to add a check. For users: update your earbuds.

References & further reading

• Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
• Official talk recording on YouTube — Black Hat channel.
• Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
• whisperpair.eu — the researchers' project page.
• Google Fast Pair developer documentation — the specification and certification workflow.
• IEEE Symposium on Security and Privacy 2026 — where the full paper is presented.