One Issue to Rule Them All: Claude Code GitHub Action Repo Takeover
Just came across the research by RyotaK from GMO regarding the Anthropic Claude Code GitHub Action flaw, and it’s a textbook example of how a small misconfiguration can lead to a massive supply chain disaster.
The vulnerability allowed an attacker to hijack public repositories running the action simply by opening a GitHub Issue. The mechanism was deceptively simple: the workflow was likely triggered on issue events with excessive write permissions.
What makes this critical is the self-hosting risk. Since Anthropic used the same vulnerable workflow to manage the Action's repository itself, a successful exploit would have allowed an attacker to inject malicious code directly into the Action source. From there, it’s game over for every downstream project depending on it.
If you're running self-hosted runners or utilizing Actions that interact with repo data, you need to lock down your trigger events.
Detection: You can hunt for overly permissive workflows in your environment using this KQL query if you're sending GitHub Audit Logs to Sentinel:
GitHubAuditLog
| where Operation == "workflow_run"
| where ActionDetails contains "issues"
| extend PermissionLevel = tostring(ActionDetails.permissions)
| where PermissionLevel contains "write"
| project RepoName, WorkflowName, Actor, TimeGenerated
**Mitigation:**
Review your YAML files. Do not grant contents: write unless strictly necessary, and avoid triggering on generic events like issues: [opened] unless the runner is isolated.
How is everyone else handling third-party Action vetting? Are you pinning by commit SHA or using tools like OWASP Dependency-Check for GitHub Actions?
This is exactly why we moved to pinning actions by commit SHA rather than tags. It’s a pain to update, but it prevents the scenario where a maintainer's account gets compromised and a tag is updated with malicious code.
For detection, we implemented a pre-commit hook using a Python script to scan workflow files for contents: write permissions:
import yaml
import sys
with open(sys.argv[1], 'r') as f:
workflow = yaml.safe_load(f)
if 'contents' in workflow.get('permissions', {}) and workflow['permissions']['contents'] == 'write':
print("WARNING: Excessive write permissions detected.")
It’s not perfect, but it catches the obvious misconfigurations before they hit the repo.
The self-hosted runner angle here is terrifying. If you’re running these actions on self-hosted runners with cloud credentials attached, a repo takeover turns into a cloud environment takeover immediately.
We’ve started enforcing strict GITHUB_TOKEN permissions in our org settings via a policy that defaults to read-only unless explicitly whitelisted. It causes some friction with developers initially, but it's better than explaining a breach. Everyone should double-check their permissions: block in their YAML files today.
Solid find by RyotaK. We've seen similar issues with fork-based PRs triggering workflows (the 'pwn request' pattern). I'd recommend adding a simple check in your workflow to ensure the actor is trusted before running heavy operations.
if [ "$GITHUB_ACTOR" == "dependabot[bot]" ]; then
echo " trusted"
else
echo "Untrusted actor attempting workflow trigger"
exit 1
fi
Don't assume that just because an event is in your repo, it’s safe to execute.
Great breakdown. To add a hardening step, strictly defining the permissions block in your workflow YAML is non-negotiable. Many orgs forget that default tokens can be overly broad.
permissions:
contents: read
pull-requests: write
By explicitly scoping the GITHUB_TOKEN down, you neuter the impact of a trigger hijack. Even if an attacker forces the workflow run, they can't push code or alter settings if the token lacks those specific scopes.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access