OAuth Grants and Phishing: A Deadly Combination

A phishing campaign that compromised over 12,000 GitHub repositories highlights how a seemingly harmless email can have large-scale repercussions. As awareness of email phishing grows, attackers have evolved their tactics—shifting from sending malicious links to creating convincing, bogus websites. Today, they’re targeting a new and powerful attack vector: OAuth 2.0.

OAuth 2.0 was designed to eliminate password risks, but it can be a backdoor

The cybersecurity industry has long sought to eliminate passwords due to risks like brute force attacks, password spraying, and default credentials. OAuth 2.0 protocol enables third-parties or custom-built apps to securely access services on behalf of users. Once granted specific permissions (scopes), these apps receive tokens to access APIs—no passwords needed. Convenient? Absolutely. But when misused or poorly managed, those tokens can become a backdoor hiding in plain sight.

OAuth 2.0 lets users login to third-party apps using trusted identity. For example, signing up for Spotify with Google lets you skip the step of creating a new account. With your consent, Google shares limited information (name, email address, language preference, and profile picture) so you can start listening instantly. If the user accepts, Google and Spotify negotiate an OAuth token that serves as the user’s credential material, replacing the need for a password.

Phishing campaign targets GitHub repos

Cybersecurity researcher @luc4m first flagged the threat on X (formerly Twitter) after receiving an email, supposedly from GitHub, warning about an attempt to access his account.

After further inspection, he noticed that all links would direct him to GitHub.com (the legitimate site, not a fake one). However, GitHub was requesting permission to grant access and full permissions to all his repositories to a third-party app named gitsecurityapp, in addition to personal data and other sensitive scopes.

After sharing his findings on social media, @luc4m sparked a wave of discoveries among other researchers. This wasn’t a one-off, but a widespread effort to gain full privileges to over 12,000 GitHub repositories from developers worldwide with the same rogue app.

The attacker’s strategy?  Instead of fake login pages or stealing credentials, the attacker used a more subtle trick: Leverage OAuth’s built-in permissions to gain full access through a malicious app. This tricked victims into granting full access to their code and data by authorizing a malicious app that appears trustworthy. Then the attacker wrote an application that took advantage of this access.

This method bypasses common defenses: 

• If victim end-users are using Password Managers, they won’t auto-fill on fake domains.
• Additionally, if enabled, two-factor authentication (2FA) still needs to be bypassed, forcing an attacker to time the attack just right. 
• If hardware keys are used instead of one-time codes, this becomes even more difficult to exploit.

But with OAuth, attackers didn’t need to capture credentials. They just need end-users to authorize a rogue app—no password, no 2FA bypass needed.

Compared to classic phishing sites, this approach is sneakier and more difficult to detect. First, all links in the emails point to real GitHub.com domains, so they fly under the radar. Email scanners and heuristics won’t flag these, therefore bypassing a crucial security layer against phishing attacks.

Even worse, if you’re already logged into GitHub—as most devs usually are—you won’t have to re-enter your credentials as you would with a fake website. Just a clean prompt asking to grant permissions. No password and no need to overcome 2FA since the OAuth access token is all an attacker needs to gain entry into a system.

But wait, there’s more. OAuth tokens live outside password sessions. If you suspect foul play, change passwords and logout everywhere, an OAuth token never changes or expires—unless you manually revoke token access. 

That’s why GitHub urges users to review connected apps and explicitly revoke access for this malicious app.

Other example attacks leveraging OAuth tokens

#1 – How 30+ popular Chrome extensions got hacked through a clever OAuth phish

Browser extensions are powerful tools that enhance your browsing experience. But that power comes with risk. Because extensions need deep access to your browser, they can often see everything you see: your Google Docs, screenshots, even your bank details. That makes them a prime target for attackers. After all, a browser extension is just code written by someone you don’t know, running inside a browser you trust. If an attacker convinces you to install their malicious extension and grant permissions, they essentially gain full access to your digital life.

Browser vendors like Google, Apple, and Mozilla understand this risk. To mitigate it, they require all extensions listed in their stores to go through a vetting process that scans for suspicious behavior. While not foolproof, this system blocks many malicious extensions from being published. But what if, instead of writing a new extension, an attacker hijacks one that’s already trusted by millions? That’s exactly what happened a few weeks ago—over 30 Chrome extensions were compromised, affecting more than 2.5 million people. 

The breach started with a phishing campaign targeting Chrome extension developers. Attackers sent fake emails that looked like official warnings from Google, claiming the targeted extension violated Chrome Web Store policies. The emails tricked developers into granting the attacker full OAuth permissions to “see, edit, update, or publish” their extensions.

To publish a Chrome extension, a developer needs a Google account. Google provides APIs that let apps interact with many of its services—including Chrome extensions—via OAuth 2.0. This system allows third-party apps to request specific access to your Google account data without needing your password. The attacker built a malicious app using this framework, specifically designed to request access to manage Chrome extensions.

Once developers approved the access—believing it was a legitimate request—the attacker could silently update their extensions in the Chrome Web Store. This gave them the power to inject malicious code directly into the browsers of millions of users, bypassing store reviews entirely. In short: they didn’t hack users—they hacked the developers, then weaponized trusted extensions already in place.

It was a clever tactic—developers expect to receive policy-related emails. The fake message included a link labeled “Go to policy,” which led to a legitimate Google Site. There, the malicious app requested the exact permissions needed to take control of the extension and push harmful updates to users.

The app was deceptively named “Privacy Policy Extension,” adding credibility and increasing the chances a developer would approve it. Once granted access, attackers gained full control to modify and publish new versions of the extension— all from a single mistake: unknowingly approving a malicious app via Google OAuth.

#2 – Double-clickjacking: Bypassing browser defenses with two deceptive clicks

Double-clickjacking is a recent tactic that shows attackers don’t always need phishing emails to trick users into approving dangerous OAuth grants.

Clickjacking tricks users into clicking something they didn’t intend to by overlaying invisible or disguised elements on legitimate websites. Victims think they’re interacting with a harmless button, but in reality, they may be granting permissions or executing actions without realizing it.

Modern browsers now block most traditional clickjacking techniques using protections like X-Frame-Options and Content Security Policies (CSP), which prevent websites from being embedded in malicious pages.

Since embedding legitimate sites is now blocked, attackers have shifted to “double-clickjacking”— a technique that swaps content between two rapid clicks to trick users into approving malicious actions without realizing it. ​

This technique has been demonstrated in real-world environments, where attackers were able to take over applications like Salesforce and Slack with just two quick clicks.

To best illustrate how the attack works, the researcher recorded several demonstrations showcasing Salesforce and Slack takeovers, all because of a simple double-click. Once again, we can see how attackers are using their creativity to find new ways to gain access abusing the capabilities of the OAuth authentication protocol. 

Key Takeaways:

These recent campaigns illustrate a broader pattern that’s becoming harder for security teams to ignore:

• Attackers no longer need to steal passwords
  Campaigns like the GitHub repository hijack show how attackers can gain persistent access by tricking users into authorizing malicious apps through OAuth— bypassing traditional credential-based defenses.
  
• Phishing has evolved
  Modern phishing techniques no longer rely on fake login pages. Instead, attackers leverage legitimate OAuth flows from trusted domains to request high-risk permissions.
  
• Trust is the weak link
  When users see OAuth prompts from platforms they use every day, such as GitHub or Google, they are more likely to approve access without realizing the potential risk.
  
• Token persistence hides compromise
  OAuth tokens often remain valid after a user logs out or changes their password. Unless manually revoked, this allows attackers to retain access and operate undetected.
  
• Visibility into OAuth activity is now critical
  Security teams need continuous monitoring of granted permissions, third-party app activity, and scope usage to detect and mitigate OAuth abuse before it results in data compromise.

Despite growing evidence, many organizations still underestimate the impact of OAuth abuse.

How AppOmni monitors permission grants

AppOmni keeps track of all access granted to your SaaS applications, providing comprehensive visibility into the environment. Continuous monitoring of new permission grants helps teams detect and mitigate phishing attacks like those described in this article, protecting critical assets before damage occurs. If overly permissive privileges are granted to a third-party, AppOmni issues an alert so it can be addressed immediately.

When real-world threats emerge, such as the GitHub OAuth app or compromised Chrome extensions, AppOmni adds these malicious applications to its Indicators of Compromise (IOC) database. This proactive step allows security teams to automatically detect and block attempts to authorize known threats.

The same approach applies to malicious browser extensions. If a compromised extension is detected— like those involved in the Cyberhaven breach— customers receive real-time alerts. AppOmni’s up-to-date repository of known threats, including rogue OAuth apps, compromised third-party integrations, and malicious extensions, gives organizations a strong defense against evolving attacks.

With AppOmni’s AI-powered assistant, AskOmni, managing SaaS security becomes as easy as having a conversation. Instead of digging through dashboards or running complex queries, security teams can ask questions like “Are there any overly permissive OAuth grants?” or “Show me suspicious grants from third-party apps.” In seconds, AskOmni provides clear, actionable answers, reducing investigation time and making it easier to detect risks before they escalate.