Developers hosting code repositories on GitHub continue to use GitHub Actions insecurely, setting up automatic workflows that can be exploited to extract sensitive authentication tokens, researchers warn.
Security risks associated with GitHub Actions workflows are not new. Still, researchers from Sysdig have identified dozens of vulnerable projects, including ones from high-profile security-aware organizations MITRE and Splunk.
“These workflows often contain secrets, such as API keys or credentials, which can be used to escalate privileges or move laterally within the repository, or even across the organization if exfiltrated,” Sysdig researchers wrote in a report this week. “Despite the availability of tools, techniques, and public research detailing how to identify and exploit these vulnerabilities, the overall maturity level of many open source projects remains alarmingly low.”
One attack vector Sysdig investigated involved GitHub Actions workflows that trigger on the pull_request_target event. According to Sysdig, the attack vector exposes secrets and a secret GitHub token with write permissions to the repository. And because the Action executes in the base repository, not the fork that triggered the pull request, if implemented without safeguards, it can lead to complete repository takeover.
“As we analyzed the results, we were surprised by the number of vulnerable pull_request_target workflows we discovered,” the researchers wrote. “You might assume these were limited to obscure or inactive repositories, but that wasn’t the case. We found several high-profile projects with tens of thousands of stars still using insecure configurations.”
GitHub Actions attacks get real
GitHub Actions is a CI/CD (continuous integration and continuous delivery) service that enables developers to automate software builds and tests by setting up workflows that trigger when specified events occur, such as when new code is committed to the repository. The workflows, called Actions, are instructions packed in an .yml file that execute inside virtual containers, usually on GitHub’s infrastructure, and return compiled binaries, test results, logs, and so on.
To operate, workflows must be able to clone the repository and perform actions against it. To enable this, the system creates and saves a temporary GITHUB_TOKEN inside the local .git folder to allow the execution of authenticated git commands. This token is meant to be ephemeral and should stop working once the workflow completes.
For years researchers have shown how GitHub Actions can be abused, including through typosquatting, build artifacts that haven’t been scrubbed of secrets, and artifact poisoning during transfer between workflows. And they are not just theoretical attacks. In December, attackers managed to compromise the build process of the Ultralytics YOLO AI library on GitHub through a GitHub Actions script injection vulnerability. This resulted in poisoned versions of the library being uploaded to the PyPI repository.
Dangerous pull request Action trigger
A pull request occurs when a developer submits new code from their forked version of a code repository back to the main repository for inclusion. Pull requests are then reviewed and commented on by the project’s developers before accepting the request to commit.
In GitHub Actions, the pull_request trigger prompts the workflow to execute within the context of the forked branch, creating a GITHUB_TOKEN that has only read access to the main repository. The pull_request_target trigger, however, prompts the workflow to execute within the context of the target branch, usually the main branch, of the repository, with complete access to all secrets stored in the repository as well as a GITHUB_TOKEN that has read and write privileges. Developers need to be careful employing this trigger, especially with workflows that attempt to check out, run, or build code from the pull request, because the code can be malicious and will gain access to the secrets, tokens and permissions of the workflow.
GitHub Actions documentation actually warns about this risky behavior. Sysdig found that many developers still use it in this way to test code changes in pull requests.
One example that Sysdig found was in Spotipy, an open-source Python library for interacting with the Spotify Web API. The project is quite popular with more than 5,000 stars on GitHub and almost 1,000 forks.
The Spotipy workflow integration_tests.yml triggers on pull_request_target, checking out code from the pull request’s repository before performing a pip install (Python package installer) command to install dependencies.
If an attacker would places a malicious setup.py in their repository, they can execute malicious code during the workflow’s pip install action. The researchers’ proof-of-concept deployed a memdump.py script that extracted credentials from memory, including SPOTIPY_CLIENT_ID, SPOTIPY_CLIENT_SECRET, and the overprivileged GITHUB_TOKEN with read/write permissions.
The reseachers also added sleep commands to their malicious code to extend the workflow execution time and therefore the validity of the GITHUB_TOKEN so it could be abused before it expired. The vulnerability was rated critical and was assigned CVE-2025-47928.
MITRE and Splunk correct repo misconfigurations
A second noteworthy example was the MITRE CAR (Cyber Analytics Repository), which ironically hosts a collection of analytics, including detection rules and logic, designed to help security teams identify adversary behaviors mapped to the MITRE ATT&CK framework.
This repository included a workflow similar to Spotipy’s, which was triggered on pull_request_target to check out code from the pull request and issue a pip install -r ./scripts/requirements.txt command. Since the requirements.txt file is part of the checked-out code, it was completely under a potential attacker’s control.
“Once again, we successfully exfiltrated the default high-privileged GITHUB_TOKEN and other secrets, ultimately gaining elevated privileges within the repository,” the Sysdig team said. “After reporting the vulnerability to MITRE, it was acknowledged and quickly fixed by the MITRE team.”
A third example was a repository belonging to Splunk called security_content that had a similar abusable workflow. In this case the extracted GITHUB_TOKEN was restricted to only read access, but the researchers managed to extract other credentials from the repository called APPINSPECTUSERNAME and APPINSPECTPASSWORD. The issue was fixed after being reported but the nature and sensitivity of the extracted credentials is not clear.
Mitigations
There are several ways to mitigate these misconfiguration risks. First, pull_request_target should be avoided if possible and wherever the security implications and risks are not fully understood. Workflows that execute in this way should not check out untrusted code.
If privileged workflows are still needed, unsafe tasks such as checking out and running unsafe code should first be performed in unprivileged workflows that then pass validated results to privileged ones. This is known as workflow splitting and is a strategy recommended by GitHub.
Second, GITHUB_TOKEN permissions should be configured to be read only, as was the case in Splunk’s repository. This will not protect other credentials exposed in the workflow’s execution, but it will prevent attackers from gaining write privileges over the main repository.
“One mitigation to consider is configuring the workflow to run only when a specific label is assigned to the pull request, effectively requiring manual vetting by maintainers with write access to the repository,” the Sysdig researchers advised. “Since external contributors can’t assign labels, this ensures pull requests trigger the workflow after a manual review.”