tl;dr We discovered SaaS providers mishandling our OAuth tokens. Attackers can use this to pivot into corporate accounts on critical services like GitHub, Azure, Slack, and more. 

Q: Would you copy/paste your GitHub password into a random SaaS tool? 

A: No way. 

Q: What about clicking “Sign in with GitHub” or “Connect to GitHub”? 

A: Probably. Let’s be honest - most of us have clicked these buttons more times than we can count. And usually, it’s fine.

But here's the reality: when you connect your GitHub account to a SaaS platform via OAuth, you’re trusting that platform to store and handle access to your GitHub account securely. Unfortunately, not all SaaS providers deserve your trust.

We analyzed over 75 popular SaaS vendors and found that more than 10% mishandled GitHub access tokens.

Note: This is NOT a vulnerability in GitHub. This issue lies with how SaaS providers implement OAuth flows. This problem isn’t exclusive to GitHub either - it affects integrations with Azure, Slack, Heroku, Twitter, and many other services.

Mishandled GitHub Access Tokens

A Typical OAuth Flow

Consider this typical OAuth flow for connecting a SaaS app to a user’s GitHub account.

[source: https://medium.com/@tony.infisical/guide-to-using-oauth-2-0-to-access-github-api-818383862591]

Despite all of the back-and-forth, the basic idea is pretty simple.

1. Authenticate: You log into GitHub (Steps A & B).

2. Authorize: GitHub provides a code to the SaaS provider, proving your identity (Step C).

3. Access: The SaaS provider exchanges that code for an access_token to make GitHub API requests on your behalf (Step D)

This is standard practice.

An Atypical OAuth Flow

During our research, we found that some SaaS providers return users' access_tokens in plaintext to the browser.

There are only a few valid reasons to expose these tokens on the client side (e.g., in a native client app). In the case of web applications, the tokens are only needed for server-to-server communication. The user should never see their value.

While reviewing popular SaaS vendors with GitHub integrations, we discovered a variety of organizations mishandling these tokens, including: 

• A tech unicorn

• A bug bounty platform

• Several AI startups

• Mid-size SaaS platforms

Case Study: A Midsize SaaS Platform 

One Developer Experience platform with30M+ users returned plaintext GitHub access_tokens via a GET request to the /api/provider/github/provider-token endpoint. As you can imagine, this endpoint’s entire job is to return the user’s GitHub access_token. Why can the client query this endpoint!?

What’s the risk?

While simply exposing a user’s own token may seem low-risk, the situation changes drastically when chained with a vulnerability like cross-site scripting (XSS).

An attacker could exploit an XSS flaw to inject malicious JavaScript that:

1. Queries /api/provider/github/provider-token for the user’s access_token.

2. Exfiltrates the token to a server the attacker controls.

Depending on the type of XSS vulnerability, an attacker could potentially compromise GitHub tokens for all authenticated users. On a platform of 30M+ users, this would lead to a significant exfiltration of valid GitHub access_tokens.

And what if the company goes out of business? An attacker could purchase the domain, add malicious JavaScript to steal tokens stored in users’ browser cookies, and then wait for users to visit the domain.

Or imagine something more straightforward - an attacker hijacks a user’s session on this SaaS application, requests a valid GitHub access_token, and then uses it to pivot into their GitHub account. 

Why is this a Big Deal?

Compromising a SaaS platform that integrates with GitHub allows attackers to harvest GitHub access_tokens at scale. SaaS providers are often much softer targets than the tech giants they integrate with.

This attack path isn’t hypothetical—it’s real.

Real-World Example: Mintlify Breach

Earlier this year, a threat actor gained access to approximately 100 customer GitHub access_tokens stored by Mintlify. The attacker then used those tokens to pivot into the customers’ GitHub accounts.

And Mintlify isn’t an isolated example.

The Problem with Detection

In attacks like this, GitHub users likely wouldn’t even know their account was compromised. Unlike a username/password login from a new IP address (which triggers an email alert), the use of a stolen OAuth token tied to a SaaS app often goes unnoticed. SaaS providers frequently change IP addresses, making it hard for GitHub to distinguish malicious activity from legitimate API calls.

What should SaaS platforms do?

Implementing OAuth securely is hard - no argument here. But this particular issue has a simple solution: don’t send user access tokens in plaintext to the client.

A quick read of GitHub’s “Best Practices” documentation clearly states that tokens should:

• Be encrypted and stored securely on the back end.

• Only accessed by secure systems (...so, don’t send them to a browser you can’t secure)

  
  

Consider GitHub's own approach: when users generate access tokens via the GitHub GUI, they must first pass an MFA challenge.

SaaS providers should adopt the same standard: users shouldn’t be able to retrieve sensitive GitHub tokens without passing GitHub’s MFA.

Our Remediation Efforts

We disclosed our findings to all impacted organizations via an email like this:

As usual, some organizations fixed the vulnerability, some didn’t, and others ignored us completely. Here’s the breakdown:

• 70% of organizations fixed the issue

• 20% never responded to us (and didn’t fix it)

• 10% responded saying it wasn’t a vulnerability

While we’re happy that 70% of vendors resolved the issue, seeing others ignore it or dismiss its severity is frustrating. We’re just trying to help!

What Can You Do?

Should You Stop Using OAuth?

No. Please keep using OAuth. Just understand the trust you place in third-party SaaS providers. And consider closely evaluating the scopes granted to the SaaS provider when you make the initial OAuth connection. There's a big difference between a leaked token that can only access your GitHub account's email address vs. your entire collection of repos.

How Can You Check if a SaaS Provider Mishandles Tokens?

For now, the best approach is to inspect the SaaS provider's traffic manually and look for token leaks. It’s a lot of work. We have a tool coming soon (stay tuned for an announcement) to help with this!

Special Thanks

A big shoutout to Brian (BB) King at Black Hills Information Security for reviewing an earlier draft of this research.