GHSA-26wh-cc3r-w6pj
HIGHcanonical/get-workflow-version-action can leak a partial GITHUB_TOKEN in exception output
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
canonical/get-workflow-version-actionReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects GitHub Actions packages — download data is not available via public APIs for these ecosystems.
Description
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦GitHub Actions | canonical/get-workflow-version-action | all versions | 1.0.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for canonical/get-workflow-version-action. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update canonical/get-workflow-version-action to 1.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-26wh-cc3r-w6pj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-26wh-cc3r-w6pj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-26wh-cc3r-w6pj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-26wh-cc3r-w6pj in your dependencies?
O3 detects GHSA-26wh-cc3r-w6pj across GitHub Actions dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.