On 13 August 2024, Palo Alto Networks Unit 42 researcher Yaron Avital published ArtiPACKED, research showing that GitHub Actions build artifacts in popular open source projects were leaking working credentials to anyone who downloaded them. Artifacts are files a workflow saves at the end of a run, and for public repositories they can be downloaded by anyone for up to 90 days. Avital found GitHub tokens, the undocumented ACTIONS_RUNTIME_TOKEN and working third-party cloud tokens in artifacts from projects run by Google, Microsoft, AWS, Red Hat, Canonical and OWASP, among others. A key cause was actions/checkout saving the job's token in the .git folder, which projects then uploaded whole. Using a race condition, he used a leaked token to create a branch in Red Hat's Clair repository. The affected projects fixed their workflows. GitHub classed the issue as informational. No malicious use of the leaked tokens has been reported.
Key takeaways
- Unit 42 reported tokens leaking through public GitHub Actions artifacts in 14 open source projects, including Google's Firebase JavaScript SDK, Microsoft's TypeScript and Azure repositories, AWS's OpenSearch Security, Red Hat's Clair and Canonical's adsys.
- The main cause was
actions/checkoutpersisting the workflow'sGITHUB_TOKENin.git/config, combined with workflows uploading the whole checkout directory. Logging tools such as super-linter also wrote environment variables, including tokens, into artifacts. - Tokens were usable:
ACTIONS_RUNTIME_TOKENlasts about six hours, and Avital used one to replace an artifact in the SchemaCrawler project. With artifacts v4, he won a race to use aGITHUB_TOKENbefore its job ended and created a branch in quay/clair. - This was research disclosure of a real exposure, not a confirmed attack. Maintainers patched quickly; GitHub treated the report as "informational" and left securing artifacts to users.
- The identity lesson: CI tokens are short-lived, but short-lived is not the same as safe when the token is published while still valid.
At a glance
| Organisations | Open source projects including Google (firebase-js-sdk), Microsoft (TypeScript-repos-automation, json-schemas, typescript-bot-test-triggerer, Azure/draft), AWS (opensearch-project/security), Red Hat (quay/clair), Canonical (adsys), OWASP (CycloneDX cdxgen), Stockfish, libevent and others; GitHub Actions |
|---|---|
| When | Disclosed by Unit 42 on 13 August 2024, after coordinated reports to each project |
| Attacker | None known. Found by Yaron Avital of Palo Alto Networks Unit 42 |
| Entry point | Public GitHub Actions artifacts containing .git folders and log files with tokens |
| Identities abused | GITHUB_TOKEN workflow tokens, ACTIONS_RUNTIME_TOKEN runtime tokens and third-party cloud service tokens |
| Impact | Live tokens exposed publicly, enough to push code or replace artifacts in some projects; no confirmed misuse; projects fixed their workflows |
| Category | NHI. Incident class: exposure, no confirmed misuse (live CI and cloud tokens exposed in public artifacts; demonstrated by a researcher) |
What happened
GitHub Actions workflows often save build outputs, test results or logs as artifacts so later jobs or people can download them. For public repositories, those artifacts are public too, and they are kept for up to 90 days. Avital downloaded artifacts from popular projects and scanned them for secrets, then worked out how each token got there and what it could do.
The most common leak was the GITHUB_TOKEN, the automatically issued token each workflow job uses to talk to its repository. By default actions/checkout writes this token into the local .git folder so later git commands work. When a workflow uploaded its whole checkout directory as an artifact, the token went with it. A second source was logging. The super-linter tool, with CREATE_LOG_FILE enabled, wrote environment variables, including tokens, into a log file that was then uploaded. Unit 42 also reports finding working tokens for third-party cloud services, including music streaming and cloud infrastructure providers, which it did not name.
Whether a leaked token was usable depended on timing. A GITHUB_TOKEN expires when its job ends, and before February 2024 artifacts could only be downloaded once the whole workflow had finished. GitHub's artifacts v4 changed that, allowing downloads while a workflow was still running. Avital raced to download an artifact, extract the token and use it before the job ended. Early attempts failed with "401 Unauthorized: Bad Credentials", but where the upload was followed by further steps he succeeded, creating a branch in Red Hat's quay/clair repository as an outside contributor. He built a workflow he called RepoReaper, running on GitHub's own infrastructure, to cut the delay. The ACTIONS_RUNTIME_TOKEN, an undocumented token used by actions such as actions/cache and actions/upload-artifact, lasts about six hours, and he used one to replace an artifact in SchemaCrawler with his own. As The Hacker News notes, pushing code with a stolen GITHUB_TOKEN requires the workflow to have contents: write permission.
Unit 42 says all the projects it contacted cooperated and patched quickly, and some paid bounties. The super-linter maintainers stopped logging environment variables. GitHub's bug bounty programme categorised the report as "informational", placing the onus on users to secure their artifacts. "A combination of misconfigurations and security flaws can make artifacts leak tokens," Avital wrote, as quoted by The Hacker News.
Timeline
| Date | Event |
|---|---|
| February 2024 | GitHub announces artifacts v4, which allows downloads while a workflow is still running. |
| 13 August 2024 | Unit 42 publishes ArtiPACKED, naming 14 affected projects that had already been notified. |
| 14 August 2024 | BleepingComputer reports the research and GitHub's decision not to change the platform. |
| 15 August 2024 | The Hacker News reports the findings. |
| November 2024 | GitHub's deprecation of v3 artifact actions takes effect, according to Unit 42. |
How it happened: the identity attack path
- Token written to disk.
actions/checkoutsaved the job'sGITHUB_TOKENin.git/config, and some tools wrote environment variables, including tokens, to log files. - Published as an artifact. Workflows uploaded the whole checkout directory or the logs, and public repositories made those artifacts downloadable by anyone for up to 90 days.
- Harvest while valid. A runtime token lasts about six hours. With artifacts v4, a
GITHUB_TOKENcan be downloaded while its job is still running. Some third-party cloud tokens did not expire at all. - Use the token. With write permissions, a stolen
GITHUB_TOKENcan push code or create branches, and a runtime token can replace artifacts that later jobs or developers trust. - Fixed per project. Each project changed its workflow; GitHub left the platform behaviour unchanged.
Impact
- Exposure: live tokens were downloadable from public artifacts in widely used projects. Unit 42 notes that firebase-js-sdk is referenced by 1.6 million public projects, according to GitHub.
- Demonstrated by the researcher: a branch created in quay/clair and an artifact replaced in SchemaCrawler. Unit 42 notes that a replaced artifact could lead to code execution in later jobs or on developers' machines.
- No confirmed misuse: no malicious use of the leaked tokens has been reported, and the named projects fixed their workflows.
- Wider: GitHub did not change the platform, so any workflow that uploads a checkout directory or verbose logs can still leak tokens.
What this means for NHI governance
CI/CD tokens are non-human identities with real power over source code and releases, and ArtiPACKED shows how easily they end up in public. The GITHUB_TOKEN is designed to be short-lived, which is good practice, but the race condition shows that a short lifetime only protects you if the token is not published during it. Runtime tokens last hours, and third-party cloud tokens in artifacts may never expire.
The fixes are ordinary NHI hygiene applied to pipelines: give workflow tokens the least permission they need, stop credentials persisting to disk, and scan what you publish, not only what you commit. CI pipeline identities were later abused for real in attacks such as the Ultralytics PyPI compromise and the tj-actions/changed-files compromise. See our CI/CD Pipeline Identity Security Guide and Secrets Management Guide.
Recommendations
- Revoke and rotate any token found in an artifact. Delete affected artifacts, rotate third-party tokens and check repository logs for unexpected writes. See our Leaked Credential Response Playbook.
- Stop credentials persisting on disk. Set
persist-credentials: falseonactions/checkoutunless a later step needs git authentication. - Upload only what you need. Never upload the whole checkout directory; list specific build outputs and scan artifacts for secrets before upload. See our Secrets Management Guide.
- Give workflow tokens least privilege. Set default
permissionsto read-only and grant write access only to the jobs that need it. See our CI/CD Pipeline Identity Security Guide. - Keep secrets out of logs. Disable tools and settings that print environment variables, and review log artifacts for tokens.
- Replace static cloud keys in CI. Use OIDC federation to issue short-lived cloud credentials to workflows instead of storing long-lived keys. See our Cloud Workload Identity Guide.
Frequently asked questions
What is ArtiPACKED?
ArtiPACKED is Unit 42's name for research, published on 13 August 2024, showing that GitHub Actions artifacts in public repositories can leak working tokens, mainly because actions/checkout stores the workflow token in the .git folder and workflows upload that folder as an artifact.
Were the leaked GitHub Actions tokens used by attackers?
No malicious use has been reported. The researcher showed the tokens were live by creating a branch in Red Hat's quay/clair repository and replacing an artifact in SchemaCrawler, and the affected projects fixed their workflows after being notified.
Did GitHub fix ArtiPACKED?
No. GitHub's bug bounty programme classed the report as informational and said users are responsible for securing their artifacts. Protection depends on workflow configuration, such as disabling credential persistence and uploading only specific files.
Related NHI Mgmt Group resources
Ultralytics PyPI compromise 2024 · tj-actions/changed-files compromise 2025 · CI/CD pipeline exploitation 2024 · CI/CD Pipeline Identity Security Guide · Secrets Management Guide
How NHI Mgmt Group can help
Pipelines run on tokens that few teams inventory or scope. We help engineering and security teams map CI/CD identities, cut their permissions and keep their secrets out of logs and artifacts. See our NHI and AI agent security training.
References
- Unit 42: ArtiPACKED: Hacking Giants Through a Race Condition in GitHub Actions Artifacts (13 August 2024)
- BleepingComputer: GitHub Actions artifacts found leaking auth tokens in popular projects (14 August 2024)
- The Hacker News: GitHub Vulnerability 'ArtiPACKED' Exposes Repositories to Potential Takeover (15 August 2024)