Last updated: August 19, 2026 at 1:47 AM UTC
All 741 Vulnerability 286 Breach 129 Threat 319 Defense 7
Tag: oauth (12 articles)Clear

n8n token exchange flaw could let attackers log in as other users

A vulnerability in the workflow automation platform n8n could let an attacker log in as another user without their password. Tracked as CVE-2026-59208, the flaw sits in n8n's Enterprise token exchange feature, which lets embedded deployments avoid a second login by accepting tokens from partner identity providers. Because the code did not properly bind an identity to its issuer, a valid token from one issuer that carried the identifier of a user under a different issuer would log the attacker in as that user. n8n shipped a fix on June 24, and there is no evidence of exploitation. The bug was found by an AI penetration-testing agent.

Check
Check whether you run n8n, especially Enterprise deployments using the token exchange feature for embedding or single sign-on, confirm the version, and update to a release that includes the June fix.
Affected
Organizations running n8n Enterprise deployments that use the token exchange feature (CVE-2026-59208); a flaw in binding identities to issuers could let an attacker present a token and log in as another user.
Fix
Update n8n to a version containing the June 24 fix, review authentication logs for unexpected cross-issuer logins, and apply least privilege so that a single compromised account has limited reach.

RabbitMQ flaws leak the broker's OAuth secret and expose cross-tenant data

Researchers at Miggo disclosed two access-control flaws in RabbitMQ, the widely used message broker, that have been present since early 2024. In the more serious one, an obsolete management endpoint had its authorization check hard-coded to always allow, so an unauthenticated attacker can leak the broker's confidential OAuth client secret in a single request, a direct path to full broker takeover where that secret is used. The second lets any logged-in user, even one with no assigned permissions, read other tenants' queue and exchange metadata, useful reconnaissance in shared environments. Both are fixed in updated releases, and the risk is sharpest where the management port is reachable from untrusted networks.

Check
Identify RabbitMQ instances on affected 3.13 and later releases, check whether the management interface and port 15672 are reachable from untrusted networks, and confirm how the OAuth client secret is configured.
Affected
RabbitMQ deployments from release 3.13.0 onward (CVE-2026-57219, CVE-2026-57221), especially cloud or multi-tenant setups with the management port exposed; attackers can leak the OAuth secret or read other tenants' metadata.
Fix
Update to a fixed RabbitMQ release, rotate the OAuth client secret if the management interface was internet-reachable, restrict access to port 15672, separate tenants by virtual host, and firewall the vulnerable endpoint.

Umbrij malware steals Google OAuth tokens through a hidden browser to read Gmail

Kaspersky detailed Umbrij, a new tool from the ToddyCat espionage group that steals access to corporate Gmail without ever taking a password. Delivered on Windows through DLL side-loading via trusted signed programs, Umbrij copies the victim's already-signed-in browser profile, launches a hidden Chromium with remote debugging, and drives it through Google's OAuth flow while impersonating legitimate Google Workspace sync apps. Because the copied profile is already authenticated, Google issues an authorization code that is exchanged for an access token, giving the attackers API access to Gmail, Drive, Calendar, and more, and sidestepping both the password and multi-factor authentication. The technique shows how stealing OAuth tokens can quietly bypass account protections.

Check
Audit which third-party apps and OAuth grants have access to your Google Workspace accounts, and watch endpoints for browsers launched with headless and remote-debugging flags outside dedicated test systems.
Affected
Organizations using Google Workspace or Gmail for business; by hijacking an already-signed-in browser profile and the OAuth flow, attackers gain token-based access to email and files without a password or MFA prompt.
Fix
Regularly review and revoke unnecessary OAuth app access to Google accounts, monitor for suspicious DLL side-loading and headless browser debugging, restrict remote-debugging use, and alert on unusual Google API access.

Stolen Klue OAuth tokens let 'Icarus' group raid Salesforce data

A new extortion group called Icarus stole Salesforce CRM data from multiple organizations by abusing Klue, a competitive-intelligence app that integrates with Salesforce. Attackers compromised Klue's backend through a dormant credential, pushed a malicious update that harvested customers' OAuth tokens, and used those tokens to run automated queries against Salesforce's API, exfiltrating contacts, sales communications, and account data over about a day. Salesforce has disabled the Klue Battlecards integration. It is the same OAuth-abuse playbook seen in the Salesloft Drift and Gainsight incidents, exploiting trusted third-party integrations that carry broad, lightly-monitored access. Researchers expect more such attacks through 2026.

Check
Inventory third-party apps connected to your Salesforce and other SaaS, especially Klue, review their OAuth scopes, and hunt API logs for unusual query volume or access from unexpected integrations.
Affected
Organizations using Klue's Salesforce integration, and more broadly any business relying on third-party SaaS integrations whose OAuth tokens grant broad, under-monitored access to CRM and other sensitive data.
Fix
Revoke and rotate OAuth tokens for Klue and other affected integrations, terminate active sessions, restrict integration and API access to known infrastructure, and continuously monitor SaaS integration activity for anomalies.

FBI-flagged Kali365 phishing-as-a-service expands reach - Microsoft 365 OAuth device-code consent abuse grows beyond April campaigns

Dark Reading reports that Kali365 - the phishing-as-a-service platform the FBI flagged for fueling Microsoft 365 attacks in April - is expanding its reach. Rather than stealing passwords, Kali365 captures OAuth access and refresh tokens by tricking victims into completing attacker-initiated Microsoft device-login requests, granting immediate mailbox access. The service generates branded lures impersonating Adobe, DocuSign, and SharePoint in many languages and sells in tiers from $250 for 30 days to $2,000 annually. Its continued growth signals that OAuth device-code consent phishing remains a high-yield technique, and that defenders should prioritize blocking device-code flows for non-mobile platforms and enforcing phishing-resistant MFA across Microsoft 365 tenants.

Check
Search Microsoft 365 logs for unfamiliar device-login completions and OAuth consent grants. Hunt for inbox rules hiding security alerts. Block Adobe/DocuSign/SharePoint-themed device-code lures.
Affected
Microsoft 365 tenants where users can complete attacker-initiated device-login flows. Kali365's branded multi-language lures and tiered pricing keep OAuth device-code phishing scalable and growing.
Fix
Block device-code flow in Conditional Access for non-mobile platforms. Enforce phishing-resistant FIDO2 MFA. Train users to verify device-login codes. Audit OAuth-granted apps regularly.

FBI warns of Kali365 phishing-as-a-service: OAuth device-code consent abuse against Microsoft 365 since April, $250-$2,000/year

The FBI has issued a warning about Kali365, a phishing-as-a-service platform that fueled large Microsoft 365 attacks in April. Instead of stealing passwords, Kali365 customers trigger Microsoft device-login requests and trick victims into completing the authorization, capturing OAuth access and refresh tokens that grant immediate mailbox access. Arctic Wolf, which infiltrated the system, says Kali365 sells in three tiers from $250 for 30 days to $2,000 for the year and generates branded phishing lures impersonating Adobe, DocuSign, and SharePoint in dozens of languages. Threat actors set malicious inbox rules to suppress security notifications and extend dwell time.

Check
Search Microsoft 365 audit logs for unfamiliar device-login completions and OAuth consent grants since April 1. Hunt for inbox rules that auto-delete or hide security-team email addresses.
Affected
Any Microsoft 365 tenant where users can complete device-login flows initiated by an attacker. Adobe, DocuSign, and SharePoint-themed lures are the primary social engineering vector.
Fix
Block device-code flow in Conditional Access for non-mobile platforms. Enforce phishing-resistant FIDO2 MFA. Train users to verify the device-login codes they approve. Audit OAuth-granted apps quarterly.

Tycoon2FA pivots to OAuth device-code phishing - lures Microsoft 365 users to legitimate microsoft.com/devicelogin

The Tycoon 2FA phishing-as-a-service kit, which Microsoft, Europol, Cloudflare and others tried to dismantle in March 2026, is back and has switched tactics. Instead of relaying credentials and MFA codes through a fake login page, operators now send victims to Microsoft's legitimate device-login page at microsoft.com/devicelogin and ask them to enter a code from the lure email. That single consent grants the attacker OAuth tokens for the victim's Exchange Online, OneDrive, and SharePoint through Microsoft's own Authentication Broker app, so it looks normal in Entra logs. eSentire spotted the late-April campaign and published IoCs, including AS45102 (Alibaba Cloud) operator infrastructure.

Check
Search Entra sign-in logs for Microsoft Authentication Broker consents (AppId 29d9ed98-a469-4536-ade2-f981bc1d605e) from unfamiliar IPs, especially AS45102 (Alibaba Cloud) with node/undici user agents.
Affected
Microsoft 365 tenants without Conditional Access policies restricting the OAuth Device Authorization Grant flow. The initial lure abuses legitimate Trustifi click-tracking URLs.
Fix
Block the Device Code Flow in Conditional Access for users who do not need it (most knowledge workers do not). Review eSentire IoCs and revoke matching sessions and refresh tokens.

New 'ConsentFix v3' attack lets criminals take over Microsoft 365 accounts even when MFA and passkeys are turned on

Push Security disclosed ConsentFix v3, a new attack that lets criminals take over Microsoft 365 accounts even if the victim has MFA and phishing-resistant passkeys turned on. The trick: instead of stealing a password, the attacker tricks the user into pasting a Microsoft authorization URL into a phishing page during what looks like a routine login. That URL contains a one-time code that the attacker exchanges for permanent access tokens. v3 automates the whole attack with Cloudflare Pages phishing sites, Pipedream webhook automation, and tenant fingerprinting that customizes the lure to each target organization's branding.

Check
Brief any Microsoft 365 admin or developer that any 'verification step' that asks them to paste a URL containing 'localhost' into a webpage is hostile, no matter how legitimate the page looks.
Affected
Any Microsoft 365 / Entra ID tenant. The attack bypasses MFA, passkeys, and most Conditional Access policies by abusing pre-consented Microsoft first-party apps. Acute risk for organizations whose admins, developers, or DevOps engineers regularly use Azure CLI - those users won't suspect a fake Azure CLI authorization page. Cloudflare Pages and Pipedream both look legitimate in network telemetry.
Fix
Apply token binding to trusted devices and require Conditional Access for first-party Microsoft apps where possible. Hunt Azure sign-in logs for Azure CLI authentications from unfamiliar IPs, especially against accounts that don't normally use it. Train developers to verify out-of-band any 'verification step' that asks them to paste URLs into a webpage. Use app authentication restrictions to limit which first-party apps can issue refresh tokens.

Microsoft patches Entra ID role flaw that let a low-privileged service account impersonate any service principal in your tenant

Microsoft quietly patched a privilege escalation flaw in Entra ID (formerly Azure AD) that let an attacker with a low-privileged service account take over any service principal in the same tenant - including high-value ones with admin consent grants. The bug was in how Entra ID validated role assignments during certain API calls: the validator checked whether the caller had any role on a service principal but didn't check whether that role authorized the specific action. Microsoft fixed the flaw on the back end, so customers don't need a patch - but the takeover scenario means anyone who exploited it before the fix could have created persistent backdoors via OAuth grants.

Check
Audit your Entra ID tenant this week for unfamiliar service principals, unexpected admin consent grants, and OAuth tokens issued to apps you don't recognize.
Affected
Microsoft Entra ID tenants with multiple service principals where any low-privileged account had role assignments on those service principals. The fix is server-side, so you don't need to apply a patch - but you do need to assume any attacker with foothold access before the fix could have abused this to escalate.
Fix
Run a Microsoft Graph audit on your tenant: list all service principals, OAuth grants, and app role assignments created since January 2026. Investigate any unfamiliar app, any grant from a service account, and any service principal whose roles changed unexpectedly. Revoke and re-issue admin consent for high-privilege apps. Enable audit logging for application registrations.

Vercel expands Context.ai breach scope - additional accounts compromised, and some predate the April incident entirely

Vercel updated its security bulletin on April 23 to disclose that ongoing forensics has uncovered additional customer accounts compromised in the Context.ai-linked breach that went public on April 19, and - more worryingly - a separate cluster of customer accounts with evidence of compromise that predates and appears unconnected to the Context.ai incident. CEO Guillermo Rauch confirmed on X that the threat actor has been active beyond Context.ai's compromise. Hudson Rock's forensic report traced patient-zero to a Context.ai employee whose laptop was infected by Lumma Stealer in February 2026 after downloading Roblox auto-farm scripts - a roughly four-week dwell time before the operator pivoted into Context.ai's AWS environment and then through OAuth tokens into Vercel's Google Workspace. The stolen credential set from that single laptop included Google Workspace logins, Supabase keys, Datadog tokens, Authkit credentials, and the support@context.ai account. Vercel has now confirmed non-sensitive environment variables in affected team scopes were readable to the attacker, and says customer notifications are going out individually rather than via a public list.

Check
If you run any service on Vercel, re-check your team's incident email for new direct notifications, and proactively rotate any environment variable not marked as 'sensitive' that was stored in Vercel during February to April 2026.
Affected
Vercel customer teams where a member authorized Context.ai's AI Office Suite OAuth integration against a Vercel enterprise Google Workspace account, and any Vercel team with environment variables not explicitly marked as 'sensitive' stored during the February to April 2026 window. The newly-surfaced predate-April account cluster is separate and Vercel has not publicly scoped it - if you receive a notification email, treat it as a distinct compromise and not simply a continuation of the Context.ai incident.
Fix
Rotate every environment variable stored in Vercel that was not marked as 'sensitive' - in practice, treat every database URL, API key, signing secret, and third-party credential as public and rotate it in place. Audit Google Workspace OAuth app grants and revoke any Context.ai 'AI Office Suite' integration. Review Vercel activity logs back to February 2026 for unexpected access to environment variable dashboards. Rotate Supabase, Datadog, and Authkit credentials if any Context.ai employee or integration ever had access to yours. Set a standing policy that no OAuth grant from an external AI tool gets 'Allow All' Workspace permissions.