GHSA-g86g-chm8-7r2p
CRITICALcheck-spelling workflow vulnerable to token leakage via symlink attack
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
check-spelling/check-spellingReal-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
For a repository with the check-spelling action enabled that triggers on pull_request_target (or schedule), an attacker can send a crafted Pull Request that causes a GITHUB_TOKEN to be exposed.
With the GITHUB_TOKEN, it's possible to push commits to the repository bypassing standard approval processes. Commits to the repository could then steal any/all secrets available to the repository.
Workarounds
You can either:
- Disable the workflow until you've fixed all branches.
or
- Set repository to Allow specific actions. You can check:
-
Allow actions created by GitHub -
Allow Marketplace actions by verified creators
-
check-spelling isn't a verified creator and it certainly won't be anytime soon. You could then explicitly add other actions that your repository uses.
or
- Set repository Workflow permissions to
Read repository contents permission.
Solution
Workflows using check-spelling/check-spelling@main were fixed automatically with the release of v0.0.19.
Workflows using a pinned sha or tagged version will need to change the affected workflows for all repository branches to the latest version.
The simple case
In the simple case, you have few enough open branches that you can do the following on all branches.
- Edit the workflow to use
check-spelling/check-spelling@main, or - Edit the workflow to use
check-spelling/[email protected], or - Delete the workflow file, or
- Change the workflow to only use
on: push- this will result in PRs losing status checks (commits will still have statuses)
The complex case
If you have too many open branches to feasibly fix all of them as per the above, you can instead do the following:
- Perform the above solution on all open branches for which you need
check-spellingto be active. - On all open branches on which you need
check-spellingto be active, rename the workflow file (e.g. tospelling2.yml) - On the default branch, create a dummy workflow file with the old name (this is usually
spelling.yml). - Use the GitHub Actions UI to disable the workflow with the old name (this is usually
spelling.yml).
This should prevent the vulnerable workflow from executing on any branches that you have not applied the proper solution to.
The reason for creating the dummy file (Step 3) before disabling the workflow (Step 4) is that, in our testing, GitHub may un-disable a workflow if it does not exist on your default branch.
Example dummy workflow file (For step 3):
# spelling.yml is disabled per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p
name: Workflow should not run!
on:
push:
branches: ''
jobs:
placeholder:
name: Should be disabled
runs-on: ubuntu-latest
if: false
steps:
- name: Task
run: |
echo 'Running this task would be bad'
exit 1
You should also include a comment in the new workflow to remind people not to resurrect the old name, for example:
# spelling.yml is disabled per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p
Finally, you should consider sending a Pull Request to an open branch in which you have not performed the proper solution to verify that the old version of check-spelling does not execute.
How to upgrade
Perform this change to your impacted workflow file (typically .github/workflows/spelling.yml):
@@ -24 +24 @@
- - uses: check-spelling/[email protected]
+ - uses: check-spelling/[email protected]
As noted above, if you have many branches, you should additionally rename the workflow and include a comment to remind people not to use the old workflow file name:
# spelling.yml is blocked per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p
Reviewing workflow runs
Users can verify who and which Pull Requests have been running the action by looking up the spelling.yml action in the Actions tab of their repositories, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml - you can filter PRs by adding ?query=event%3Apull_request_target, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml?query=event%3Apull_request_target.
References
- For more information on
pull_request_targetattacks, see GitHub Security Lab: Keeping your GitHub Actions and workflows secure: Preventing pwn requests - For information on workflow hardening techniques, see GitHub: Security hardening for GitHub Actions
Credit
Thanks to @justinsteven for reporting as well as in helping validate the fix.
For more information
For questions or comments about this advisory:
- Email us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦GitHub Actions | check-spelling/check-spelling | all versions | 0.0.19 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for check-spelling/check-spelling. 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 check-spelling/check-spelling to 0.0.19 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g86g-chm8-7r2p 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-g86g-chm8-7r2p 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-g86g-chm8-7r2p. 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-g86g-chm8-7r2p in your dependencies?
O3 detects GHSA-g86g-chm8-7r2p 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.