Could the CodeQL leak have been prevented? How to protect your secrets against CI/CD workflow vulnerabilities
In March 2025, a critical vulnerability called CodeQLEAKED was discovered within GitHub's CodeQL, potentially exposing numerous repositories to supply chain attacks.
The vulnerability highlighted how even short-lived secrets can spark massive breaches, and that strong secret scanning is non-negotiable.
Incident Overview
The CodeQLEAKED vulnerability CVE-2025-24362 originated from a publicly exposed GitHub token found in workflow artifacts. What makes the discovery of this vulnerability particularly surprising is the token's extremely short validity period—just 1.022 seconds. Despite this brief window, a security researcher at Praetorian both found the issue, and demonstrated that attackers could exploit a race condition to execute malicious actions with the exposed token.
The discovery happened when a security researcher was scanning GitHub Actions workflow artifacts for secrets using a specialized tool he had built. After downloading the "my-debug-artifacts" zip uploaded by a "PR Check – Debug artifacts after failure" workflow in the github/codeql-action repository, the researcher found a GitHub Token starting with "ghs_" in a crash report. This token was stored in a file containing the environment variables of the GitHub Runner executing the workflow.
With this GITHUB_TOKEN, attackers could:
- Create branches and push malicious code
- Create tags pointing to compromised code
- Potentially backdoor the entire CodeQL system
- Execute code on any repository using CodeQL
The vulnerability didn't just affect the CodeQL repository—it potentially impacted every repository using CodeQL's default configuration. Since CodeQL is used by hundreds of thousands of repositories for security scanning, this represented a significant attack surface.
The Hidden Dangers of Short-Lived Tokens
The CodeQLEAKED incident shatters a dangerous assumption: that short-lived tokens pose minimal risk.
Many security teams operate under the belief that temporary credentials with brief validity periods are safer. And while this is generally true, the CodeQLEAKED incident proved that these brief periods could still be exploited.
After discovering the Github token, the researcher still needed to prove that despite the ~1 second validity period, the token could be successfully exploited. To do this, the researcher created a Python script (artifact_racer.py) that:
- Continuously monitored the github/codeql-action repository for new workflow runs
- Downloaded artifacts as soon as they appeared
- Extracted the GITHUB_TOKEN
- Used it to create a branch, push a file, and create a tag
For this vulnerability to be possible to be exploited, three conditions had to be met:
- Token Privileges: The compromised token needed full write privileges to the repository.
- Artifact API Version: The artifact upload had to specifically use version 4 of the GitHub Actions upload artifact API, as earlier versions prevented downloading artifacts before job completion.
- Timing: There needed to be a sufficient window (at least one to two seconds) between artifact upload completion and token invalidation, providing enough time for the attacker to retrieve and exploit the token.
In the case of CodeQLEAKED, all three conditions aligned, and the researcher was able to successfully demonstrate the potential for exploitation despite the extremely short token lifespan.
How The Attack Could Spread
If found by a more malicious actor, the vulnerability could have a much wider impact. When a repository enables CodeQL through GitHub's interface, it doesn't just analyze code locally. Instead, it executes actions from the github/codeql-action repository using the "v3" tag reference. If an attacker could overwrite this tag (which the vulnerability allowed), they could immediately execute malicious code in every repository using CodeQL's default configuration.
This attack vector created the potential for a massive supply chain attack affecting thousands of repositories simultaneously, and would have allowed exfiltration of source code from private repositories, theft of GitHub Actions secrets, and even cache poisoning to maintain persistent access.
High-profile projects including Homebrew, Angular, and Grafana were identified as potentially vulnerable.
GitHub's Response
GitHub responded quickly:
- January 22, 2025, 3:13 PM UTC: the vulnerability was reported to GitHub.
- January 22, 2025, 6:28 PM UTC: GitHub confirmed the vulnerability, temporarily disabled the problematic workflow, and submitted a PR to disable the uploading of debug artifacts.
- January 24, 2025: GitHub assigned CVE-2025-24362 and published a security advisory.
- January 27, 2025: Debug artifact upload was re-enabled for CLI versions 2.20.3 or greater in CodeQL Action version 3.28.6
This rapid response (just three hours from report to initial mitigation) demonstrated how seriously major platforms like Github take security issues like this one.
Best Practices Learned
The CodeQLEAKED vulnerability offers several valuable lessons for securing CI/CD environments:
1. Restrict Token Permissions
The compromised token had full write permissions to the repository, significantly increasing its potential for abuse. Follow the principle of least privilege by:
- Configuring workflows to use read-only tokens when possible
- Granting specific permissions rather than blanket access
- Regularly auditing token permissions across your pipelines
2. Secure Workflow Artifacts
Artifacts represent a frequently overlooked attack vector. Improve security by:
- Only uploading specific files or directories as workflow artifacts
- Avoiding uploads of artifacts containing environment variables, the `.git/config` file, or any files in the runner's `<path_to_runner_dir>/_work/_temp/` directory
- Limiting artifact retention periods to minimize exposure
3. Use Proper Workflow Pinning
The CodeQL vulnerability was particularly dangerous because it used tag references rather than commit SHA pinning. Always pin workflows to specific commit SHAs rather than branches or tags to prevent tag manipulation attacks. GitHub recommends this as a security best practice for Actions.
4. Understand Cache Poisoning Risks
The vulnerability also highlighted the risk of 'cache poisoning' in CI/CD systems. Cache poisoning occurs when malicious data or code is deliberately inserted into shared caches used by CI/CD workflows, allowing an attacker’s payload to persist and re-execute even after the original vulnerability is patched. This technique could provide persistent backdoor access by continuously poisoning the cache entries leveraged by various workflows.
How Does Soteri Stop Secrets From Being Exposed?
While CodeQLEAKED specifically affected GitHub repositories, similar supply-chain vulnerability patterns—such as exposed credentials, artifact leakage, or misconfigured caches—can occur in other CI/CD systems, including Bitbucket Pipelines.
Soteri's Security for Bitbucket specifically addresses secret exposure by proactively scanning Bitbucket repository content and preventing leaked credentials from ever entering the codebase. However, unlike GitHub's CodeQL (which focuses on general code vulnerabilities), Soteri's solution ensures the secrecy of credentials that could accidentally be committed to repositories.
Early Detection
Soteri scans for secrets before any code can be pushed into Bitbucket through a pre-receive hook. This prevents secrets from entering repositories or workflow artifacts in the first place.
The hook can be configured to run in individual repositories, projects, or enforced across the entire Bitbucket instance.
Local Scanning
Unlike cloud-based solutions that require sending code to external servers, Soteri performs all oursecret scanning locally within your environment. This means sensitive code never leaves your systems, and detection happens instantly without network delays.
Comprehensive Coverage
Soteri provides comprehensive secret scanning across Bitbucket repositories, including commit-level scans, and repository-wide audits. This ensures secrets are identified and prevented from ever entering or persisting within Bitbucket-hosted codebases.
Beyond this, Soteri also provides secret scanning for additional developer products within the Atlassian ecosystem:
Custom Secret Detection
Beyond standard patterns like API keys and credentials, Soteri can also identify organization-specific secrets using custom regex patterns, helping catch even non-standard token formats.
In Summary
The CodeQLEAKED incident serves as a critical reminder that even the most trusted security tools can introduce vulnerabilities. No matter which version control or CI/CD system you use, robust secret scanning is essential for protecting your software supply chain.
We encourage all organizations to:
- Audit your current CI/CD workflows for potential secret exposures
- Implement pre-commit hooks to catch secrets before they're committed
- Scan workflow configurations and artifacts for exposed credentials
- Review token permission models to enforce least privilege
- Pin workflow references to specific commit hashes rather than tags or branches
If you're using Atlassian products and want to protect against similar vulnerabilities in your environment, Soteri provides comprehensive secret scanning specially designed for Bitbucket, Jira, and Confluence.
Book a call with us today to learn how our comprehensive scanning approach can help secure your development pipeline and prevent the next supply chain attack before it happens.