GHSA-26wh-cc3r-w6pj

Suggest an improvement
Source
https://github.com/advisories/GHSA-26wh-cc3r-w6pj
Import Source
https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2025/04/GHSA-26wh-cc3r-w6pj/GHSA-26wh-cc3r-w6pj.json
JSON Data
https://api.test.osv.dev/v1/vulns/GHSA-26wh-cc3r-w6pj
Aliases
Published
2025-04-02T22:36:03Z
Modified
2025-04-03T13:26:02Z
Severity
  • 8.2 (High) CVSS_V3 - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:H CVSS Calculator
Summary
canonical/get-workflow-version-action can leak a partial GITHUB_TOKEN in exception output
Details

Impact

Users using the github-token input are impacted.

If the get-workflow-version-action step fails, the exception output may include the GITHUBTOKEN. 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 GITHUBTOKEN 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 GITHUBTOKEN is automatically revoked when the job completes. However, there is an opportunity for an attack in the time between the GITHUBTOKEN 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 GITHUBTOKEN 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 GITHUBTOKEN is automatically revoked when the job completes. However, in the unlikely event that an attack was executed using a GITHUBTOKEN before it was revoked (as described above), users' repositories may still be impacted—for example, a sophisticated attack could have used the GITHUBTOKEN to push something to the repository.

The potential effects of an attack depend on the permissions of any GITHUBTOKENs that were leaked. However, in a very sophisticated attack, even a GITHUBTOKEN 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 GITHUBTOKEN 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 GITHUBTOKEN, 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

Database specific 
{
    "nvd_published_at": "2025-04-02T22:15:20Z",
    "cwe_ids": [
        "CWE-532"
    ],
    "severity": "HIGH",
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-02T22:36:03Z"
}
References

Affected packages

GitHub Actions / canonical/get-workflow-version-action

Package

Name
canonical/get-workflow-version-action

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
1.0.1