# CVE-2025-24362: CodeQL GitHub Action failed workflow writes GitHub PAT to debug artifacts > Attackers with repository read access can retrieve exposed secrets and GitHub tokens from debug artifacts in failed CodeQL workflows. - **Severity:** High 7.1 (`CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N`) - **Exploited in the wild:** Not known - **Login needed:** Any signed-in user - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 24 Jan 2025 - **Updated:** 31 Mar 2025 - **Also known as:** GHSA-vqf5-2xx6-9wfm ## What is CVE-2025-24362? CVE-2025-24362 is a high-severity vulnerability in github codeql-action, published on 24 Jan 2025. Any signed-in user can exploit it over the network, with no action from the victim. ### Official description In some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment. This vulnerability is patched in CodeQL Action version 3.28.3 or later, or CodeQL CLI version 2.20.3 or later. For some affected workflow runs, the exposed environment variables in the debug artifacts included a valid `GITHUB_TOKEN` for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The `GITHUB_TOKEN` is valid until the job completes or 24 hours has elapsed, whichever comes first. Environment variables are exposed only from workflow runs that satisfy all of the following conditions: - Code scanning workflow configured to scan the Java/Kotlin languages. - Running in a repository containing Kotlin source code. - Running with debug artifacts enabled. - Using CodeQL Action versions <= 3.28.2, and CodeQL CLI versions >= 2.9.2 (May 2022) and <= 2.20.2. - The workflow run fails before the CodeQL database is finalized within the `github/codeql-action/analyze` step. - Running in any GitHub environment: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. Note: artifacts are only accessible to users within the same GitHub environment with access to the scanned repo. The `GITHUB_TOKEN` exposed in this way would only have been valid for workflow runs that satisfy all of the following conditions, in addition to the conditions above: - Using CodeQL Action versions >= 3.26.11 (October 2024) and <= 3.28.2, or >= 2.26.11 and < 3. - Running in GitHub.com or GitHub Enterprise Cloud only (not valid on GitHub Enterprise Server). In rare cases during advanced setup, logging of environment variables may also occur during database creation of Java, Swift, and C/C++. Please read the corresponding CodeQL CLI advisory GHSA-gqh3-9prg-j95m for more details. In CodeQL CLI versions >= 2.9.2 and <= 2.20.2, the CodeQL Kotlin extractor logs all environment variables by default into an intermediate file during the process of creating a CodeQL database for Kotlin code. This is a part of the CodeQL CLI and is invoked by the CodeQL Action for analyzing Kotlin repositories. On Actions, the environment variables logged include GITHUB_TOKEN, which grants permissions to the repository being scanned. The intermediate file containing environment variables is deleted when finalizing the database, so it is not included in a successfully created database. It is, however, included in the debug artifact that is uploaded on a failed analysis run if the CodeQL Action was invoked in debug mode. Therefore, under these specific circumstances (incomplete database creation using the CodeQL Action in debug mode) an attacker with access to the debug artifact would gain unauthorized access to repository secrets from the environment, including both the `GITHUB_TOKEN` and any user-configured secrets made available via environment variables. The impact of the `GITHUB_TOKEN` leaked in this environment is limited: - For workflows on GitHub.com and GitHub Enterprise Cloud using CodeQL Action versions >= 3.26.11 and <= 3.28.2, or >= 2.26.11 and < 3, which in turn use the `actions/artifacts v4` library, the debug artifact is uploaded before the workflow job completes. During this time the `GITHUB_TOKEN` is still valid, providing an opportunity for attackers to gain access to the repository. - For all other workflows, the debug artifact is uploaded after the workflow job completes, at which point the leaked `GITHUB_TOKEN` has been revoked and cannot be used to access the repository. Weakness: CWE-532 (Insertion of Sensitive Information into Log File) ## Which versions are affected by CVE-2025-24362? 2 open source packages ship an affected version, including github/codeql-action. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `github/codeql-action` | GitHub Actions | From 2.26.11 | None | | `github/codeql-action` | GitHub Actions | From 3.26.11 | 3.28.3 | ## How do I fix CVE-2025-24362? Upgrade github/codeql-action to 3.28.3 or later. ## Is CVE-2025-24362 being exploited? There is no known exploitation of CVE-2025-24362 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2025-24362 and fix it if it is affected. What it is: CVE-2025-24362 is a high-severity vulnerability in github codeql-action, published on 24 Jan 2025. Any signed-in user can exploit it over the network, with no action from the victim. Exploitation: There is no known exploitation of CVE-2025-24362 in the wild and no public exploit code. Affected packages and fixed versions: - github/codeql-action (GitHub Actions): affected from 2.26.11; no fix listed - github/codeql-action (GitHub Actions): affected from 3.26.11; fixed in 3.28.3 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2025-24362/ (Markdown: https://insights.sbomify.com/CVE-2025-24362/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2025-24362 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-24362 - OSV: https://osv.dev/vulnerability/CVE-2025-24362 --- From sbomify Insights: https://insights.sbomify.com/CVE-2025-24362/ Summaries are generated and may contain mistakes; the official description above is the record.