One-Click Speaker-Linking Flow Hands Over a Streaming Account

Reported Jun 16, 2026

Severity High

Platform Web / Connected Device

Vulnerability Class OAuth Misconfiguration (CWE-601)

Target Type Music Streaming

Impact One-click permanent account takeover

The Risk

A paying customer of this music service who clicked a single attacker-supplied link, thinking it was a routine login confirmation, handed the attacker ongoing access to their account. With that access the attacker could change the account's contact email to their own, trigger a password reset that then arrived in the attacker's inbox, set a new password, and permanently own the account while locking the real owner out of recovery. Before that, the same access already exposed the victim's email, real name, full date of birth, country, and billing status. The only thing that keeps this from being the very worst case is that the victim has to click once.

The Vulnerability

The service offers an account-linking flow so customers can connect a smart-speaker platform to their account through a music-service integration API. Two compounding defects in that flow and in the account API combine into one-click permanent takeover.

Defect one: attacker-steerable device linking with a scope upgrade

The device-link flow issues an access token bound to a device-household identifier. That identifier is fully attacker-chosen and is reflected verbatim into the sign-in state value, rather than being tied to the authorizing user's own device or session. So an attacker can mint a link code bound to a household they control, and after the victim authorizes, poll for and collect the victim's token. The integration's sign-in client also accepted an attacker-supplied scope upgrade from read-only to read-and-write, which is what enables account-changing actions.

Defect two: email change with no re-authentication

The account API let a write-capable token change the account's contact email with no current password, no email confirmation, and no one-time code. This defect stands alone: any write-capable token obtained by any means converts to permanent takeover through the email-swap and password-reset path.

The Attack

The chain

The attacker, unauthenticated, generates a device-link code bound to a household they control. The service hands back a ready-to-use authorize link with the attacker household reflected into the sign-in state.
The attacker makes one change to that link, upgrading the requested access from read-only to read-and-write, and sends it to the victim.
The victim, logged in, opens the link and clicks a single confirmation. The consent screen renders on the genuine sign-in origin, does not name the speaker platform, does not list the requested access, and does not warn that ongoing access is being granted, so it looks like a routine login confirmation.
The attacker polls with the same household and link code and receives the victim's bound token, scoped read-and-write, plus a refresh token for persistent access.
Using the token, the attacker reads the victim's personal data, then changes the account's contact email to an attacker address with a single write that requires no current password, confirmation, or one-time code.
The attacker triggers the account's password reset. Because the reset link is delivered to the contact email, now the attacker's, the attacker receives it, sets a new password, and permanently owns the account. The original owner no longer holds the contact email and cannot self-recover.

This was demonstrated end-to-end: the password-reset email landed in the attacker-controlled inbox.

The Impact

This is one-click permanent account takeover on a connected-device integration that is an explicitly in-scope critical asset. Before the takeover, the stolen token already exposed the victim's email, full date of birth, real name, country, account age, subscription and billing status, active session and bound device, and full library, a personal-data disclosure on its own.

The interaction requirement, a single click delivered by phishing, is what places this at High rather than Critical. It is not zero-click and not pure request forgery. Notably, the second defect stands independently: any write-capable token obtained by any means, a token leak, a malicious integration, or another sign-in client, becomes permanent takeover through the same email-swap and reset path, with no re-authentication check. That raises the floor of the finding regardless of how the linking vector itself is scoped.

Remediation

Bind the issued token to the authorizing user's own consent and session, not to a caller-supplied device-household identifier.
Show an explicit linking consent screen that names the device and the access being granted, and cannot be mistaken for a routine login confirmation.
Restrict the integration's sign-in client to read-only access and reject any attacker-supplied upgrade to write access.
Require the current password, or verification on the old address, or a confirm-on-new-address step, before changing the account's contact email, and never deliver password resets to an unverified, newly-set email.