Loading story…
A researcher disclosed a Google identity provider vulnerability that allowed account takeover through the OAuth 2.0 Device Authorization Grant (RFC 8628). The issue reportedly stemmed from two flaws in Google's implementation: a device authorization session could be transferred across browsers using a copied challenge URL, and the authorization server did not ensure that the client_id and requested scopes in the later consent step matched those originally tied to the issued device_code. The write-up describes the bug as a confused deputy condition that let attackers hijack device-code sign-in flows and obtain tokens for arbitrary Google-registered clients.
By combining those weaknesses with prompt=none, an attacker could allegedly send a single link to a victim already signed in with Google and trigger silent token issuance without a consent screen, fresh 2FA challenge, or obvious account-activity warning. The researcher said the attack could move beyond limited scopes such as YouTube TV and be escalated to Google Cloud permissions and even Gmail access through IMAP XOAUTH2 when a substituted client was permitted to request https://mail.google.com. According to the disclosure, the bug was reported to Google through its VRP, initially rejected, later reopened, fixed, and ultimately awarded a $13,337 bounty.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
After the issue was reopened and remediated, the researcher received a $13,337 reward from Google. The bounty recognized the reported universal account-takeover vulnerability in Google's device authorization flow.
Google fixed the reported vulnerability affecting its identity provider implementation of the OAuth 2.0 device code flow. The flaw chain could enable one-click, invisible account takeover and escalation to broader Google scopes, including Google Cloud and Gmail access via IMAP XOAUTH2.
A researcher reported a chained account-takeover vulnerability in Google's OAuth 2.0 Device Authorization Grant implementation to the Google Vulnerability Reward Program. The issue involved transferable device-code sign-in sessions and missing binding between device_code, client_id, and scope, enabling silent token issuance for arbitrary clients.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
infosecwriteups.com
Open sourcereddit.com
Open sourcesecuritysenses.com
Open sourceweirdmachine64.github.io
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A phishing campaign abused Microsoft's OAuth 2.0 **Device Authorization Grant** (`Device Code Flow`) to capture valid Microsoft account tokens without sending victims to a counterfeit login page. Victims received emails posing as legal notifications, including password-protected PDF attachments, and were funneled through phishing pages that displayed a one-time device code before directing them to the legitimate `microsoft.com/devicelogin` page. After victims entered the code and completed normal MFA on Microsoft's real site, the attackers obtained `access_token`, `refresh_token`, and `id_token` values tied to attacker-controlled applications. The stolen tokens enabled persistent access to Microsoft services including **email, OneDrive, and Teams**, allowing attackers to read messages, access files, and monitor conversations. Researchers said the activity was observed from early April to mid-May 2026 and included a Brazil-focused variant that used legitimate redirect links, including on **cacoo.com**, to add credibility to the lure chain. Defenders were urged to reject unexpected device authorization prompts, inspect redirect parameters in otherwise legitimate URLs, disable Device Code Flow in Microsoft Entra ID where it is not needed, and monitor **DeviceCodeSignIn** and anomalous sign-in activity for signs of compromise.
Jul 9, 2026
Attackers abused Microsoft’s OAuth 2.0 Device Authorization Grant flow to phish users into authorizing attacker-controlled sessions on legitimate Microsoft login pages, allowing them to capture **access tokens**, **refresh tokens**, and **ID tokens** without stealing passwords directly. In the observed campaign, victims received phishing emails, were routed through phishing landing pages and open redirects, and were told to enter attacker-supplied one-time device codes on Microsoft’s official device verification page before completing MFA. The stolen tokens enabled access to Microsoft 365 services including **email**, **OneDrive**, and **Teams**. Researchers also observed a Brazil-focused variant that used `cacoo.com`, a legitimate Nulab-owned service, as an open redirect to phishing infrastructure. Recommended mitigations include training users to reject unsolicited device-code requests, reviewing redirect parameters and final destinations, monitoring **DeviceCodeSignIn** events, enforcing device-compliance controls, and disabling Device Code Flow in Microsoft Entra ID where it is not required.
Jul 6, 2026
Threat actors are increasingly abusing **OAuth** in *Microsoft Entra ID* and *Microsoft 365* to obtain **access/refresh tokens** that provide durable access even when passwords are reset and MFA is enabled. Reported activity includes both (1) **malicious OAuth app** registrations and deceptive consent prompts that masquerade as legitimate “business integrations,” and (2) abuse of the **OAuth 2.0 Device Authorization Grant** (device code flow) where victims authenticate on Microsoft’s legitimate device login portal, making the intrusion harder to detect with credential-focused controls. Multiple reports describe campaigns targeting business users and organizations (including technology, manufacturing, and financial sectors) to access resources such as **Outlook, Teams, and OneDrive** and to enable mailbox actions and data access under seemingly legitimate application activity. Research and incident reporting highlight that attackers can persist via **service principals** created in victim tenants after consent is granted, and that some integrations may remain effective even if the consenting user is later disabled; separate reporting also describes **device-code vishing/phishing** that leverages legitimate Microsoft OAuth client IDs and standard login workflows to capture tokens without attacker-hosted phishing pages, with one source attributing the vishing activity to **ShinyHunters** (unconfirmed by Microsoft at the time of reporting).
Jun 29, 2026