Supply Chain Breach via GitHub Issues: The Claude Code Action Debacle
Just came across the report from RyotaK at GMO regarding the critical flaw in Anthropic's Claude Code GitHub Action. It’s a textbook example of how a simple misconfiguration can lead to a massive supply chain compromise.
The mechanics of this are terrifying: by simply opening a GitHub Issue on a public repository running the vulnerable action, an attacker could hijack the repo. The kicker is that Anthropic's own repository was vulnerable, meaning a successful exploit could have injected malicious code directly into the action's source, propagating the compromise to every downstream project pulling it.
The root cause seems to be the workflow's handling of issue data combined with an overly permissive GITHUB_TOKEN. If you're using this action, you need to audit your workflows immediately. Specifically, check if you are granting write permissions to the default token on events like issues: [opened] without strict input validation.
Here is a basic KQL query for defenders using Azure Sentinel or GitHub Advanced Security to hunt for suspicious pushes by the bot:
GitHubAuditData
| where Actor == 'github-actions[bot]'
| where Operation == 'git.push'
| where RepositoryName contains 'claude-code' or RepositoryName contains 'target-repo'
| project TimeGenerated, Actor, Operation, RepositoryName, RefName
| order by TimeGenerated desc
Also, always pin your actions to a specific commit SHA rather than a tag to prevent these update-chain attacks.
Question: For those managing CI/CD pipelines, are you using any third-party tools to automatically audit PRs for unsafe GITHUB_TOKEN permissions, or is this still a manual review process for you?
We saw this behavior with a similar dependency confusion attack last month. Manual review is impossible at scale. We implemented a step in our pipeline using regula to check IaC and workflow files against policy before they are even merged.
regola check .github/workflows/*.yml --config regola-config.yml
It flags if the `permissions` block is set to `write-all` or if it listens to `issues` triggers without the necessary `contents: read` restriction.
This is exactly why we stopped allowing GitHub Actions to trigger on public comments or issues unless it's strictly for triaging. The risk of command injection via user input is just too high.
If you must use it, sandbox the action. Don't give the default token write access to the repository scope. Use a scoped PAT or a separate OIDC provider if possible.
The supply chain aspect is the real scary part here. Even if you didn't use the action yourself, if one of your dependencies did, you could be pulling malicious code.
We are currently looking at software composition analysis (SCA) tools that actually verify the integrity of the Action's SHA against the vendor's provenance data, rather than just trusting the registry.
Great insights. To expand on hardening, we need to ensure the GITHUB_TOKEN follows the principle of least privilege. Even if an issue triggers the workflow, the runner shouldn't have write permissions to the repository unless absolutely necessary.
You can enforce this in the workflow YAML:
permissions:
contents: read
issues: write
This prevents an attacker from pushing code even if they manage to inject commands through the issue title or body.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access