Listen to this Post
Introduction:
Attackers are now exploiting GitHub’s own trusted issue‑notification system to deliver OAuth phishing attacks, turning routine developer inbox alerts into a silent supply‑chain compromise vector. By creating fake “security alerts” as GitHub issues, hackers trick developers into authorizing malicious OAuth applications that grant persistent, permission‑rich access to repositories, CI/CD pipelines, and production workflows. This technique bypasses traditional email filters because the notification originates from GitHub itself, making it a highly effective and scalable attack.
Learning Objectives:
- Identify and analyze OAuth phishing attacks that leverage GitHub issue notifications to compromise developer accounts.
- Implement defensive controls including OAuth application approval policies, 2FA, and repository audit logging.
- Apply incident response steps to revoke malicious OAuth tokens, rotate secrets, and secure CI/CD pipelines after a breach.
You Should Know:
- Anatomy of the Attack: How GitHub Issue Notifications Are Abused
Attackers begin by creating an issue on any public GitHub repository (often a popular or trending project). The issue title and body are crafted to mimic an urgent security alert from GitHub, for example: “Unusual access attempt from new device – verify your credentials” or “Malicious commits detected in your repositories – review now.” The issue contains a link that appears legitimate but leads to an attacker‑controlled OAuth consent page.
When a developer clicks the link, they are presented with a standard GitHub OAuth authorization screen requesting permissions such as repo, workflow, admin:org, or delete_repo. If the developer approves, the malicious app receives an OAuth token that can be used to read, modify, and exfiltrate code, inject backdoors into CI/CD pipelines, or even delete entire repositories.
Step‑by‑step guide to understanding the attack flow:
- Attacker creates a fake alert issue on a public repo (e.g., `https://github.com/owner/repo/issues/999`).
- GitHub sends an email notification to watchers and contributors – the email comes from
[email protected], bypassing most spam filters. - Developer clicks the link inside the issue, which points to `https://github.com/login/oauth/authorize?client_id=ATTACKER_APP_ID&scope=repo,workflow`.
- Developer authorizes the malicious OAuth app, thinking it is a legitimate security tool.
- Attacker’s server receives the OAuth token and immediately begins cloning repositories, modifying code, or exfiltrating secrets.
To inspect your currently authorized OAuth apps on Linux/macOS:
Using GitHub CLI
gh auth status
gh api /user/authorizations --jq '.[] | {id, app_name, scopes, token_last_eight}'
Using curl and jq (create a personal access token first)
curl -H "Authorization: token YOUR_PAT" https://api.github.com/user/authorizations | jq '.[] | {app_name, scopes, updated_at}'
On Windows (PowerShell):
Requires GitHub CLI installed
gh auth status
gh api /user/authorizations | ConvertFrom-Json | Select-Object -Property @{Name="AppName";Expression={$_.app.name}}, scopes, token_last_eight
- Detecting Malicious OAuth Applications on Your GitHub Account
Proactive auditing of installed OAuth apps is critical. Many developers approve apps and forget them. Malicious apps often request broad, unnecessary permissions like write:packages, delete_repo, or admin:repo_hook.
Step‑by‑step guide to audit OAuth apps:
- Navigate to GitHub Settings → Applications → Authorized OAuth Apps.
- Review each app – remove any that you do not recognize or that request excessive scopes.
- Check the app’s creation date and popularity – new, obscure apps with no avatar or description are suspicious.
- Use GitHub’s API to automate audits across your organization.
Automated audit script (Linux/macOS):
!/bin/bash
List all authorized OAuth apps and flag dangerous scopes
DANGEROUS_SCOPES=("repo" "workflow" "admin:org" "delete_repo" "write:packages" "admin:repo_hook")
gh api /user/authorizations | jq -r '.[] | "(.app.name): (.scopes | join(","))"' | while read line; do
app=$(echo "$line" | cut -d: -f1)
scopes=$(echo "$line" | cut -d: -f2)
for danger in "${DANGEROUS_SCOPES[@]}"; do
if [[ "$scopes" == "$danger" ]]; then
echo "⚠️ $app has dangerous scope: $danger"
fi
done
done
- Hardening GitHub Accounts and Organizations Against OAuth Phishing
Prevention is far more effective than cleanup. Implement these controls to block malicious OAuth apps before they can be authorized.
Step‑by‑step hardening guide:
- Enable mandatory 2FA for all users (including bots and service accounts). Use WebAuthn security keys or TOTP.
2. Restrict OAuth app access in organization settings:
Organization Settings → Third‑party access → OAuth Apps → Restrict access to approved apps only.
This forces any new OAuth app to be approved by an admin before use.
3. Configure IP allow lists (GitHub Enterprise or GitHub Enterprise Cloud) so that API and OAuth tokens can only be used from your corporate IP ranges.
4. Enable audit logging to track when OAuth apps are authorized:
`Organization Settings → Audit log` – search for oauth_authorization.create.
5. Use GitHub’s security manager role to monitor and revoke suspicious apps across all repositories.
Linux command to check for unexpected OAuth activity in audit log (using API):
Requires a token with read:org and admin:org scope
org="YOUR_ORG"
curl -H "Authorization: token YOUR_PAT" \
"https://api.github.com/orgs/$org/audit-log?include=oauth_authorization.create" \
| jq '.[] | {created_at, actor, action, oauth_app_name}'
4. Defending CI/CD Pipelines from Compromised OAuth Tokens
If an attacker gains an OAuth token with `repo` and `workflow` scopes, they can inject malicious steps into your GitHub Actions, steal secrets, or push backdoored code. Protect pipelines by avoiding long‑lived tokens and using short‑lived, scoped credentials.
Step‑by‑step pipeline hardening:
- Never store personal access tokens (PATs) as secrets – use GitHub’s built‑in `GITHUB_TOKEN` which is automatically scoped to the current workflow.
- Use OpenID Connect (OIDC) instead of static secrets for deploying to cloud providers (AWS, Azure, GCP). OIDC issues short‑lived, workload‑identity tokens that are not reusable by attackers.
- Require approval for workflow runs from outside collaborators:
Repository Settings → Actions → General → Require approval for all outside collaborators. - Regularly rotate any remaining PATs and store them in GitHub Secrets with limited repository access.
- Use code scanning and secret scanning to detect leaked tokens or suspicious commit patterns.
Example OIDC configuration for AWS (GitHub Action):
.github/workflows/deploy.yml jobs: deploy: permissions: id-token: write needed for OIDC contents: read steps: - name: Configure AWS credentials using OIDC uses: aws-actions/configure-aws-credentials@v3 with: role-to-assume: arn:aws:iam::123456789012:role/github-oidc-role aws-region: us-east-1 - name: Deploy to S3 run: aws s3 sync ./build s3://my-bucket
- Incident Response: What to Do If You’ve Been Phished
If you suspect that you or a team member authorized a malicious OAuth app, immediate containment is required to prevent repository takeover and supply‑chain propagation.
Step‑by‑step incident response:
- Revoke the malicious OAuth app immediately – go to `Settings → Applications → Authorized OAuth Apps → Revoke` for the app in question.
- Rotate all secrets that may have been exposed: repository secrets (GitHub Actions), cloud provider keys, database passwords, and API tokens.
- Audit repository logs for unusual activity: force pushes, branch deletions, new webhooks, or modified GitHub Actions workflows.
Check recent commits across all branches git log --all --since="7 days ago" --oneline --author="attacker" List recently added webhooks gh api /repos/:owner/:repo/hooks --jq '.[] | {id, config_url, events}' - Enable branch protection rules to prevent force pushes and require PR reviews on critical branches (
main,master,develop). - Notify GitHub Support if the malicious OAuth app has been widely distributed – they can revoke it globally.
- Reset your account password and invalidate all existing tokens:
Settings → Developer settings → Personal access tokens → Regenerate all.
Windows PowerShell script to list all webhooks across your repos:
$org = "YOUR_ORG"
$repos = gh api "orgs/$org/repos" --jq '.[].name' | ForEach-Object { $_ }
foreach ($repo in $repos) {
Write-Host "Webhooks for $repo :"
gh api "repos/$org/$repo/hooks" --jq '.[] | {url: .config.url, events: .events}'
}
- Simulating the Attack for Ethical Training (Test Environment)
Understanding the attacker’s perspective helps defenders build better awareness. In a controlled, isolated environment, you can simulate this OAuth phishing attack to train your team.
Step‑by‑step ethical simulation guide:
- Create a test GitHub organization and a dummy repository with no sensitive data.
2. Register a new OAuth application on GitHub:
Settings → Developer settings → OAuth Apps → New OAuth App.
Set the callback URL to your attacker‑controlled server (e.g., `http://localhost:8080/callback`).
3. Build a simple phishing page that mimics GitHub’s OAuth consent screen but includes a warning label: “THIS IS A TRAINING SIMULATION”.
4. Create a test issue in the dummy repository with a link to your OAuth app’s authorization URL:
https://github.com/login/oauth/authorize?client_id=YOUR_TEST_CLIENT_ID&scope=repo,workflow&state=training
5. Have team members (with consent) click the link and observe which permissions they approve.
6. Log the received OAuth token and demonstrate how it can be used to list repositories, then immediately revoke it.
7. Debrief with training on how to spot malicious issues and never approve unexpected OAuth requests.
Linux command to set up a simple token capture server (for training only):
Using netcat to listen on localhost:8080 and log the callback parameters nc -lvnp 8080 | grep -i "code=" Then use the captured code to exchange for token (requires client_secret) curl -X POST https://github.com/login/oauth/access_token \ -H "Accept: application/json" \ -d "client_id=YOUR_TEST_ID&client_secret=YOUR_TEST_SECRET&code=CAPTURED_CODE"
What Undercode Say:
- Trust is the new perimeter – Attackers weaponize GitHub’s own trusted notifications to bypass human suspicion. Never click on unsolicited “security alerts” inside issues, even if they appear to come from GitHub.
- OAuth apps are a blind spot – Most developers never audit their authorized OAuth applications. Treat OAuth tokens as you would SSH keys: revoke unused ones, enforce approval policies, and monitor for anomalous scopes.
This attack demonstrates a fundamental shift from code‑level exploits to identity‑ and trust‑based supply‑chain compromise. Traditional email filters are ineffective because the phishing vector is a legitimate GitHub notification. Organizations must implement OAuth approval workflows, enforce 2FA with hardware keys, and train developers to recognize that GitHub issues can be malicious. The same technique could easily be adapted to other platforms like GitLab, Bitbucket, or even Jira. Expect to see more “platform‑native” phishing attacks that abuse internal messaging, comments, and notification systems.
Prediction:
In the next 12‑18 months, we will witness a surge of supply‑chain attacks that exclusively use trusted platform notifications (GitHub issues, GitLab merge requests, Slack webhooks, Jira comments) as phishing vectors. OAuth consent screens will evolve to include dynamic risk indicators – such as “This app was created 2 hours ago and has no verified publisher” – but attackers will quickly adapt by registering seemingly legitimate apps with typosquatted names. Regulatory bodies like NIST may issue new guidance requiring mandatory OAuth app approval for any code‑related scopes, and GitHub will likely introduce a “report this OAuth app” button on the consent screen. The long‑term solution lies in short‑lived, just‑in‑time tokens (e.g., OAuth 2.0 with device flow and user‑managed policies) combined with continuous authorization checking against security posture.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mayura Kathiresh – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
