Hackers abuse GitHub issue emails to phish developers into approving malicious OAuth apps

A newly documented phishing technique targets developers by abusing GitHub’s own issue notification system to push malicious OAuth app approvals into victims’ inboxes. Researchers say the attack works because GitHub can send legitimate email notifications when a user gets mentioned in an issue, while the final click takes the target to a real GitHub authorization page for a rogue OAuth app.

That makes this campaign unusually convincing. The email can arrive from GitHub’s normal notification flow, and the approval screen can appear on GitHub itself. If a developer authorizes the app, the attacker can receive an access token tied to the victim’s account and the permissions the app requested. GitHub’s own documentation warns users to authorize OAuth apps only if they trust the developer and have reviewed the permissions being requested.

The bigger concern is supply chain risk. Developer accounts often sit close to private repositories, CI/CD workflows, release pipelines, and production secrets. That makes them valuable targets. The article you shared also points to recent ecosystem incidents involving Axios and LiteLLM to show how account compromise can ripple into software supply chains.

How the phishing method works

Researchers at Atsika found that attackers do not need an expensive or complex setup. The campaign can start with a free GitHub account, a malicious OAuth app, and a hosted phishing workflow built around GitHub notifications. The attacker reportedly impersonates a security service, creates a fake repository, and uses issue mentions to trigger an email to the target.

GitHub’s official documentation confirms that users can receive email notifications for mentions on issues and pull requests. GitHub also documents notification reasons in email headers, including mention, which helps explain why this delivery method feels legitimate to the victim.

Once the victim clicks through, the attack moves to the authorization step. GitHub says OAuth apps can request access scopes, and users must review what data and actions those apps want. If the victim approves the request, the app can act using the granted token within the limits of the approved scopes.

Why OAuth approval is the real trap

This attack does not need a fake password prompt to succeed. Instead, it tries to trick developers into granting access voluntarily through GitHub’s normal authorization flow. That matters because phishing-resistant authentication methods can still fall short if the victim knowingly approves a malicious app. This is an inference based on GitHub’s OAuth authorization model and the attack flow described in the shared report.

The sample report says the proof-of-concept OAuth app requested broad access, including read and write access to repositories, GitHub Actions workflows, and user profile data. If that kind of token lands in attacker hands, the result can go far beyond code theft. It can also enable malicious commits, workflow abuse, secret exposure, and persistence inside developer environments.

GitHub’s own scope documentation makes clear that scopes define what an OAuth token can access. Scopes do not create permissions the user never had, but if a victim already has powerful repository or organization access, a malicious app can inherit significant reach.

The TOCTOU angle makes the campaign harder to investigate

One of the more notable details in the material you shared is the alleged Time-of-Check Time-of-Use, or TOCTOU, race condition. Researchers say an attacker can create an issue mentioning the target, trigger GitHub’s email notification, and then quickly edit or wipe the issue content. That means the phishing text arrives in the email while the public issue may later appear empty or harmless.

If accurate, that trick reduces the trail defenders can review after the fact. It also gives the attacker a cleaner social engineering path because the inbox message can carry urgency while the linked repository looks less obviously malicious on a quick check. I have not found a GitHub advisory confirming that specific race condition, so this part currently rests on the Atsika research described in your source text.

The same report says attackers can also mask the phishing URL with link shorteners and use account or repository names that look security-related. That combination increases the chance that a developer sees the message as a routine account alert rather than a social engineering attempt.

Why developers remain a prime target

Developers control high-value systems. A compromised GitHub account can expose private source code, access tokens, package pipelines, GitHub Actions workflows, and release mechanisms. That is why OAuth phishing against developers can become a software supply chain problem, not just an account security problem.

That broader backdrop matters in 2026. CISA recently warned about the Axios npm compromise, and LiteLLM also disclosed a suspected supply chain incident tied to unauthorized package publishing. Those cases differ from this GitHub phishing technique, but they show how quickly developer account access can turn into downstream risk for many users and organizations.

So the lesson here is not only “watch for phishing.” It is also “treat third-party app approvals like privileged access decisions.” In many environments, clicking Authorize on the wrong OAuth screen can matter almost as much as handing over a password. That is an inference drawn from GitHub’s authorization model and the permissions described in the shared report.

At a glance

Element	What happens	Why it matters
GitHub issue mention	Attacker mentions a developer in an issue	GitHub can send a legitimate notification email
Security-themed lure	Message claims an account or repo problem	Urgency pushes faster clicks
Malicious OAuth app	Victim lands on a real GitHub authorization page	The page looks trustworthy
Broad scopes requested	App asks for repo, workflow, or profile access	Approval can hand over meaningful control
Fast issue edit or wipe	Original issue content may disappear afterward	Investigation gets harder

What developers and teams should do

• Review every OAuth app request carefully before approving it.
• Check who built the app and whether the request makes sense for your workflow.
• Audit already authorized OAuth apps in GitHub settings and revoke anything unfamiliar.
• Treat urgent security emails with caution, even if they come through GitHub notifications.
• Limit who can interact with public repositories where mentions can trigger notifications.
• Monitor token use, repo changes, and GitHub Actions activity for unusual behavior.

FAQ