One-Click Google SSO Takeover via Device-Code Bug

How the attack worked

A researcher identified two related flaws in Google's device code sign-in flow, the mechanism used when signing into devices like smart TVs or consoles by entering a code shown on screen. The first flaw allowed a device code session to be transferred by copying a Google challenge URL, containing a TL parameter, into a second browser. Logging in on that second browser could complete the sign-in for the original device. The second flaw was more serious: Google did not verify server-side that the client_id and scope in the authorization URL matched what the device_code was originally issued for. This meant an attacker could swap in a different application's client_id and request different scopes after the flow had already started.

Why it succeeded

Combining the two flaws with prompt=none and common scopes such as openid email profile created a flow that required only one click. The victim opened a single crafted link and the sign-in completed silently, with no consent screen and no button to press. Because the resulting token could be replayed against any third-party app using Sign in with Google, the researcher noted that account takeover was possible on virtually any application relying on that login method. In a variant aimed at higher-value targets, the attacker swapped the client_id for Google's own Cloud SDK client and changed the scope to cloud-platform, compute, and appengine.admin, producing a consent screen with elevated permissions instead of a silent flow.

What to watch for

• An unexpected Google Accounts or sign-in link that you did not initiate yourself
• A sign-in flow that completes with no consent screen, even though it relates to account access
• A consent screen naming an application that does not match the context, such as Google Cloud SDK appearing during what should be a TV or console sign-in
• Scopes that look unusually powerful, like cloud-platform or appengine.admin, requested for an everyday login

How to build resistance

Because the login itself is genuinely rendered by Google, awareness training should stress that a normal-looking sign-in step does not guarantee a safe outcome. Employees should be encouraged to pause on unexpected sign-in links, even ones on legitimate Google domains, and to actually read the application name and requested permissions on any consent screen before proceeding. Periodic review of the connected apps list on Google accounts can also help, since traces of this kind of abuse may appear as an unusual scope tied to an unexpected app entry rather than as an obvious error.

What was the Google device code flow vulnerability?

Google did not bind the device_code to the original client_id and scope on the server side, so an attacker could swap those values in the authorization URL after the flow started, redirecting a victim's sign-in to a different application.

Did the victim have to approve anything for the attack to work?

In the most dangerous version, no. By adding prompt=none and using common scopes like openid email profile, the flow completed silently after the victim opened a single link, with no consent screen and no button to press.

How could a victim detect this attack after the fact?

The Google connections page could show the original device client, such as YouTube TV, rather than the substituted application, so a victim would need to notice an unusual scope request tied to an unexpected app name to catch it.

Was this issue fixed?

Yes. Google initially responded with a won't fix decision but later fixed the issue and paid a bug bounty for the report.