ghsa-26wh-cc3r-w6pj
Vulnerability from github
Impact
Users using the github-token
input are impacted.
If the get-workflow-version-action
step fails, the exception output may include the GITHUB_TOKEN. If the full token is included in the exception output, GitHub will automatically redact the secret from the GitHub Actions logs. However, the token may be truncated—causing part of the GITHUB_TOKEN to be displayed in plaintext in the GitHub Actions logs.
Anyone with read access to the GitHub repository can view GitHub Actions logs. For public repositories, anyone can view the GitHub Actions logs.
The opportunity to exploit this vulnerability is limited—the GITHUB_TOKEN is automatically revoked when the job completes. However, there is an opportunity for an attack in the time between the GITHUB_TOKEN being displayed in the logs and the completion of the job. Normally this is less than a second, but it may be greater if continue-on-error
is used in the get-workflow-version-action
step or if status check functions are used in a later step in the same job. For an example of an attack in the time between the GITHUB_TOKEN being displayed in the logs & the completion of the job, see https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/
For users who passed the GITHUB_TOKEN to the github-token
input, update to v1.0.1
. Any secrets that were partially leaked while using v1.0.0
should have already been revoked, since the GITHUB_TOKEN is automatically revoked when the job completes. However, in the unlikely event that an attack was executed using a GITHUB_TOKEN before it was revoked (as described above), users' repositories may still be impacted—for example, a sophisticated attack could have used the GITHUB_TOKEN to push something to the repository.
The potential effects of an attack depend on the permissions of any GITHUB_TOKENs that were leaked. However, in a very sophisticated attack, even a GITHUB_TOKEN with read-only permissions can affect other GitHub Actions in the same repository if those actions use the Actions cache. For more information, see the "But Wait, There’s More" section of https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/ and https://github.com/AdnaneKhan/Cacheract
If any users used a long-lived secret (e.g. a personal access token) instead of the GITHUB_TOKEN in the github-token
input, they should immediately revoke that secret. The get-workflow-version-action
's documentation & examples all instructed the user to use the GITHUB_TOKEN, so it is unlikely that users used a long-lived secret instead of the GITHUB_TOKEN.
Patches
This has been fixed in v1.0.1
. Also, the v1
tag has been updated to include the fix.
References
https://github.com/canonical/get-workflow-version-action/issues/2
{ "affected": [ { "package": { "ecosystem": "GitHub Actions", "name": "canonical/get-workflow-version-action" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "1.0.1" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2025-31479" ], "database_specific": { "cwe_ids": [ "CWE-532" ], "github_reviewed": true, "github_reviewed_at": "2025-04-02T22:36:03Z", "nvd_published_at": "2025-04-02T22:15:20Z", "severity": "HIGH" }, "details": "### Impact\nUsers using the [`github-token` input](https://github.com/canonical/get-workflow-version-action/blob/a5d53b08d254a157ea441c9819ea5002ffc12edc/action.yaml#L10) are impacted.\n\nIf the `get-workflow-version-action` step fails, the exception output may include the GITHUB_TOKEN. If the full token is included in the exception output, GitHub will automatically redact the secret from the GitHub Actions logs. However, the token may be truncated\u2014causing part of the GITHUB_TOKEN to be displayed in plaintext in the GitHub Actions logs.\n\nAnyone with read access to the GitHub repository can view GitHub Actions logs. For public repositories, anyone can view the GitHub Actions logs.\n\nThe opportunity to exploit this vulnerability is limited\u2014the GITHUB_TOKEN is automatically revoked when the job completes. However, there is an opportunity for an attack in the time between the GITHUB_TOKEN being displayed in the logs and the completion of the job. Normally this is less than a second, but it may be greater if [`continue-on-error`](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) is used in the `get-workflow-version-action` step or if [status check functions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#status-check-functions) are used in a later step in the same job. For an example of an attack in the time between the GITHUB_TOKEN being displayed in the logs \u0026 the completion of the job, see https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/\n\nFor users who passed the GITHUB_TOKEN to the `github-token` input, update to `v1.0.1`. Any secrets that were partially leaked while using `v1.0.0` should have already been revoked, since the GITHUB_TOKEN is automatically revoked when the job completes. However, in the unlikely event that an attack was executed using a GITHUB_TOKEN before it was revoked (as described above), users\u0027 repositories may still be impacted\u2014for example, a sophisticated attack could have used the GITHUB_TOKEN to push something to the repository.\n\nThe potential effects of an attack depend on the permissions of any GITHUB_TOKENs that were leaked. However, in a very sophisticated attack, even a GITHUB_TOKEN with read-only permissions can affect other GitHub Actions in the same repository if those actions use the Actions [cache](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows). For more information, see the \"But Wait, There\u2019s More\" section of https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql/ and https://github.com/AdnaneKhan/Cacheract\n\nIf any users used a long-lived secret (e.g. a personal access token) instead of the GITHUB_TOKEN in the `github-token` input, they should immediately revoke that secret. The `get-workflow-version-action`\u0027s documentation \u0026 examples all instructed the user to use the GITHUB_TOKEN, so it is unlikely that users used a long-lived secret instead of the GITHUB_TOKEN.\n\n### Patches\nThis has been fixed in `v1.0.1`. Also, the `v1` tag has been updated to include the fix.\n\n### References\nhttps://github.com/canonical/get-workflow-version-action/issues/2", "id": "GHSA-26wh-cc3r-w6pj", "modified": "2025-04-03T13:26:02Z", "published": "2025-04-02T22:36:03Z", "references": [ { "type": "WEB", "url": "https://github.com/canonical/get-workflow-version-action/security/advisories/GHSA-26wh-cc3r-w6pj" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31479" }, { "type": "WEB", "url": "https://github.com/canonical/get-workflow-version-action/issues/2" }, { "type": "WEB", "url": "https://github.com/canonical/get-workflow-version-action/commit/88281a62e96e1c0ef4df30352ae0668a9f3e3369" }, { "type": "PACKAGE", "url": "https://github.com/canonical/get-workflow-version-action" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:H", "type": "CVSS_V3" } ], "summary": "canonical/get-workflow-version-action can leak a partial GITHUB_TOKEN in exception output" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.