Somewhere in your organization, right now, there is an employee who authorized a third-party AI tool last quarter. They clicked through the permissions screen in under ten seconds. They have long since forgotten about it. That authorization is still active. The vendor who built that tool may have been compromised last month. And no one on your security team has any idea this access exists.
This is not a hypothetical. It is exactly what happened to Vercel in 2026 — and the attack pattern it represents has become the defining breach vector of the year. Welcome to the age of OAuth supply chain attacks, where your perimeter isn’t your firewall. It’s every third-party application your employees have ever trusted. The pattern mirrors the CISA credential leak from the same window: long-lived, over-privileged access sitting in places nobody was monitoring.
Monday Morning, One Click, Six Weeks of Access
The story starts the way most modern breaches start — not with a sophisticated attack, but with a completely ordinary moment. A Vercel employee authorized Context.ai, a small AI productivity tool, to connect to their Google Workspace account. The permissions screen offered the usual vague assurances. The employee clicked through. The integration worked as advertised. Life continued normally.
What happened next was invisible to everyone at Vercel for the better part of two months. In approximately February 2026, threat actors deployed a Lumma Stealer infection against Context.ai’s own systems. Lumma Stealer is a commodity infostealer — cheap to buy, widely available, designed to harvest credentials and session tokens from infected machines. When it hit Context.ai, it found something far more valuable than a password: it found OAuth session tokens representing active, authenticated connections to Context.ai’s enterprise customers, including Vercel.
Those tokens didn’t just represent access to Context.ai’s own systems. Because the employee had granted broad Google Workspace permissions during the original authorization, the stolen tokens were skeleton keys — able to authenticate as a known, trusted application, bypassing every MFA control Vercel had in place, and operating with the same implicit trust as a legitimate employee session. This is why privileged access management must extend to every OAuth-connected application, not just human accounts.
“One employee granting broad Workspace permissions to a third-party AI tool gave attackers an inherited trust path into Vercel’s deployment systems. The breach wasn’t discovered by Vercel’s security team — it was discovered when the attacker chose to monetize publicly.”
Vercel Official Security Bulletin · April 19, 2026
For six weeks, attackers moved through Vercel’s internal environment. They accessed source code repositories. They harvested API tokens for GitHub and NPM. They collected 580 employee records. They mapped deployment infrastructure. At no point during those six weeks did a security alert fire. Vercel’s detection stack saw a known, authorized application accessing resources — exactly what it was designed to accept. The breach was discovered not when Vercel’s security team noticed something, but when the attacker chose to sell the access on underground forums and post proof-of-data publicly.
This is the anatomy of an OAuth supply chain attack. And the uncomfortable truth is that Vercel is not exceptional. It is representative. The same attack chain played out at two major U.S. banks through a shared third-party vendor in April 2026. At Adobe, through an Indian BPO contractor with Workspace access. At dozens of smaller organizations that never made headlines. The pattern is consistent because the underlying vulnerability is consistent: enterprises have authorized hundreds of third-party applications and have no ongoing visibility into whether those vendors are still trustworthy.
Why OAuth Became the Gap Nobody Was Watching
To understand why this attack pattern is so effective, you have to understand how OAuth was supposed to work — and how the world it was designed for no longer exists.
OAuth’s core promise was elegant: instead of sharing passwords between applications, users grant specific, revocable permissions. An application gets a token scoped to what it actually needs. The user stays in control. Security teams can audit what’s connected and revoke access at any time. On paper, this is a significant improvement over the credential-sharing patterns it replaced.
The gap between the design and the reality is three things: volume, scope creep, and invisible vendors.
Volume: The SaaS explosion nobody audited
The average enterprise in 2026 has hundreds of SaaS applications, each potentially carrying OAuth connections to core identity platforms. Most of these were authorized by individual employees — not IT, not security — during the normal course of doing their jobs. A marketing coordinator connected a data enrichment tool. A developer authorized a code review integration. A manager granted calendar access to a scheduling assistant. Each individual decision was harmless. Collectively, they created an OAuth graph with hundreds of trust relationships that nobody has ever mapped, let alone governed. The problem is structurally identical to the agentic AI identity crisis: non-human actors with excessive access and no oversight.
Scope creep: The permissions screen nobody reads
OAuth allows narrow, specific permissions. Most applications request broad ones. “Access all files in Google Drive.” “Read and send email on your behalf.” “Manage all connected applications.” Users click through these requests in seconds, during the moment of wanting to use a tool — the worst possible moment for careful security evaluation. The result is that most enterprise OAuth graphs are saturated with applications holding far more access than their function requires. When any one of those vendors is compromised, the blast radius is determined entirely by the permissions they were granted. Your cybersecurity policies and procedures should explicitly address OAuth authorization standards — including which permission scopes require security review before approval.
Invisible vendors: The third party your third party doesn’t tell you about
The Vercel breach went undetected for six weeks because Context.ai’s compromise wasn’t flagged to Vercel — there was no mechanism for it to be. Most enterprise OAuth applications have no contractual requirement to disclose a security incident to the organizations whose tokens they hold. Your third-party risk management program almost certainly covers your Tier 1 vendors — the companies on your formal vendor list with signed security addendums. It probably doesn’t cover Context.ai. It doesn’t cover the dozen shadow AI tools your developers have connected to their GitHub accounts. It doesn’t cover the data enrichment integrations your marketing team authorized last quarter. These apps hold real access to real systems. Treat them like vendors.
Most organizations have no inventory of which third-party applications their employees have authorized, what permissions those applications hold, or whether those vendors’ own security meets any minimum standard. The OAuth graph — the full map of which apps can access which resources — is invisible to most security teams. That invisibility is the vulnerability.
This Isn’t One Incident. It’s a Pattern.
Vercel made headlines. Dozens of other organizations didn’t. The same attack architecture — compromise a trusted third party, inherit their OAuth access, move through the downstream organization undetected — was documented across a wave of 2026 incidents that Trend Micro described as “an unprecedented concentration of software supply chain attacks” in the March–April window alone.
Here’s what the 2026 incident record shows when you look at OAuth and supply chain attacks together:
The numbers tell one part of the story. The timeline of 2026 incidents tells the other. Read the breach disclosures from February through May 2026 and a pattern emerges: the entry point is almost never a direct attack on the target organization. It’s a trusted third party. A shared vendor. An authorized application. The attacker walks in through the front door — the door your security architecture was specifically designed to keep open for trusted partners.
What a Stolen OAuth Token Actually Gives an Attacker
The reason OAuth supply chain attacks are so dangerous isn’t just that they’re hard to detect. It’s that the access they provide is extraordinarily broad. When most people think about a stolen credential, they picture access to one account. A stolen OAuth token with broad workspace permissions is categorically different. Here’s what an attacker inheriting a Workspace OAuth token actually has:
- MFA bypass — permanently. OAuth tokens represent completed authentication events. Presenting a valid token to an API endpoint doesn’t trigger an MFA challenge. There is no secondary factor to bypass. The attacker is, from the perspective of every connected system, an authenticated, trusted session.
- Lateral access across every connected service. A Google Workspace token with broad permissions doesn’t just open Gmail. It opens Drive, Calendar, Meet, Admin Console — and every application that uses Google as an identity provider. One token cascades through dozens of connected services, all of which see legitimate, authorized access.
- Long or indefinite persistence. OAuth refresh tokens can maintain access for months or indefinitely. Unlike a stolen password that becomes useless after a rotation, a refresh token that hasn’t been explicitly revoked keeps working — even after the compromised user changes their password, even after the vendor relationship is terminated, even after the incident is discovered, unless someone specifically revokes it.
- No traditional indicators of compromise. Token-based access looks identical to legitimate application access in every log format. Without dedicated OAuth behavioral monitoring — the kind of anomaly detection that a managed detection and response program should provide — a stolen token generates no alerts. It’s just another authorized session.
- Path to production infrastructure. In modern deployment environments, OAuth tokens held by CI/CD and developer tools carry permissions that reach production — container registries, deployment pipelines, cloud platform APIs. A compromised token in a developer productivity tool can translate directly into the ability to push malicious code to production systems.
“The OAuth graph is now the new perimeter, and most companies have no inventory of which third-party apps their employees have authorized. Tightening OAuth scope reviews and inventorying authorized third-party apps would have closed the lateral path before it was used.”
PKWARE 2026 Data Breaches Analysis · April 2026
Five Things to Do Before the Next Vendor Discloses an Incident
The Vercel breach had a clear preventable moment: before the employee authorized Context.ai, someone could have asked whether that vendor’s security posture justified the permissions being granted. That question wasn’t asked. It rarely is. Building an organization where that question gets asked — systematically, for every authorization — is the architectural change that closes this vulnerability class.
Here’s the practical framework, in priority order:
1. Run your OAuth inventory this week
Google Workspace, Microsoft Entra, and Okta all expose administrative visibility into authorized OAuth applications. Most organizations have never pulled this data. Pull it now. You will find applications authorized by employees who left the company years ago. You will find integrations carrying admin-level permissions for tools that need nothing close to admin access. You will almost certainly find applications that nobody on your security team has ever heard of. A cybersecurity risk assessment that includes an OAuth audit is the fastest path to visibility — you cannot scope, monitor, or revoke what you don’t know exists.
2. Apply least-privilege scoping immediately to your highest-risk apps
Sort your OAuth inventory by permission scope: which applications hold the broadest access to your most sensitive systems? For each high-scope application, ask whether the scope is actually necessary for the application’s function. Most won’t be. For applications where a narrow scope would suffice, require vendors to implement it. For applications where broad access is genuinely necessary, document the justification and flag those vendors for enhanced security scrutiny. This is where data security posture management intersects with identity governance — understanding not just who has access, but what data that access exposes.
3. Extend vendor risk management to OAuth-connected applications
Your governance, risk, and compliance program almost certainly covers your Tier 1 vendors. It probably doesn’t cover the small AI tools your developers have connected to their GitHub accounts. These apps hold real access to real systems. Treat them like vendors. Ask whether they have a security incident disclosure process. Find out what data they actually store from their connection to your environment. Establish a minimum bar — even a simple questionnaire — before any application with broad permissions gets authorized. The convergence of AI identity risk and data privacy makes this especially urgent for AI-connected tools.
4. Build OAuth-specific detection rules into your SIEM
The six-week undetected dwell time in the Vercel breach reflects a detection gap that is completely addressable. OAuth anomaly signals to monitor include: tokens being used from unexpected IP geographies, access to resources outside an application’s historical scope, access at unusual hours, API call volume spikes from a connected application, and tokens being used after the authorizing user’s account has been deprovisioned. None of these require new tooling — they require new detection rules on data you’re already collecting. Build them before the next vendor incident happens.
5. Create and test a token revocation playbook
When a vendor discloses an incident, your mean time to revoke their OAuth tokens is a critical security metric. In the Vercel breach, persistent access lasted six weeks in part because there was no revocation trigger. Every organization should have a documented, tested incident response plan that covers OAuth token compromise: identify all tokens associated with a compromised vendor, revoke them across every connected platform, audit what those tokens accessed during the window of compromise, and notify affected systems and users. Practice this process before you need it. A vendor incident is not the time to figure out how token revocation works in your environment.
Propelex’s Third-Party Risk Management and Cybersecurity Risk Assessment services include a comprehensive OAuth and SaaS access audit — mapping every application authorized in your environment, the permissions it holds, and the vendor security posture behind it. We help you close the gaps before the next Vercel happens to you.
