Multiple high-profile open-source projects, including those from Google, Microsoft, AWS, and Red Hat, were found to leak GitHub authentication tokens through GitHub Actions artifacts in CI/CD workflows.
Attackers stealing these tokens could gain unauthorized access to private repositories, steal source code, or inject malicious code into projects.
The discovery by Palo Alto Networks’ Unit 42 prompted action by owners of popular repositories where secrets were leaked through GitHub Actions artifacts. However, the underlying problems remain unfixed as GitHub decided not to address the risk, placing the responsibility on users to secure their artifacts.
Given the situation, GitHub users need to understand the risks, evaluate their exposure, and take measures to prevent leaks in the future.
Source: Unit 42
Leaking GitHub tokens
Unit 42’s report highlights a combination of factors, including insecure default settings, user misconfiguration, and insufficient security checks, that can lead to the leakage of GitHub tokens in what they call an “ArtiPACKED” attack.
The first risk point is the ‘actions/checkout’ action, commonly used in GitHub workflows to clone the repository code so that it is available during the workflow run.
By default, this action persists the GitHub token to the local .git directory (hidden) as required for authenticated operations within the workflow.
If a user mistakenly uploads the entire checkout directory as part of an artifact, the GitHub token inside the git folder will now be exposed.
Source: Unit 42
Other sensitive information that might be contained in that folder include API keys, cloud service access tokens, and various account credentials.
A similar exposure by erroneous artifact uploads can happen by artifacts generated during the CI/CD process, such as build outputs and test results, which are stored and accessible for up to three months.
Another point of failure is CI/CD pipelines that use environment variables to store GitHub tokens. If actions or scripts within the workflow log these variables, either purposefully or by mistake, the logs are uploaded as artifacts.
Unit 42 notes that the ‘super-linter’ action can create detailed logs that include environment variants when the ‘CREATE_LOG_FILE’ property is set to ‘True.’
Exploiting the leakages
Ultimately, attackers would seek to exploit specific race condition scenarios where the ephemeral GitHub tokens have to be extracted from logs and used before they expire.
GitHub tokens remain valid for the duration of the workflow job, so their exploitation potential varies per case.
The ‘Actions_Runtime_Token,’ used internally by GitHub for caching and managing artifacts, is typically valid for six hours, so the exploitation window is small.
Custom secrets and tokens, such as API keys or access tokens for cloud services, have varying lifespans, from a few minutes to never expire.
Unit 42 presents an attack scenario that identifies projects or public repositories that use GitHub Actions and uses automated scripts to scan them for criteria that increase the likelihood of artifact generation.
A different set of scripts could automatically download artifacts from the CI/CD pipelines of target repositories, which is a simple process in the case of public repositories. Then, it would scrutinize them for secrets.
Source: Unit 42
Mitigation
Unit 42 identified the following 14 cases of large open-source projects exposing artifacts with GitHub tokens and reported it to the affected parties for remediation:
- Firebase (Google)
- OpenSearch Security (AWS)
- Clair (Red Hat)
- Active Directory System (Adsys) (Canonical)
- JSON Schemas (Microsoft)
- TypeScript Repos Automation, TypeScript Bot Test Triggerer, Azure Draft (Microsoft)
- CycloneDX SBOM (OWASP)
- Stockfish
- Libevent
- Guardian for Apache Kafka (Aiven-Open)
- Git Annex (Datalad)
- Penrose
- Deckhouse
- Concrete-ML (Zama AI)
In general, GitHub users are recommended to avoid including entire directories in uploaded artifacts, sanitize logs, and regularly review CI/CD pipeline configurations.
The default settings for dangerous actions like ‘actions/checkout’ should be adjusted so credentials do not persist. Furthermore, token permissions used in workflows should be set to the least privilege necessary to limit damage in case they are exposed.