There is a dangerous shift happening in software supply chain security: automated attackers are now probing CI/CD workflows continuously, not occasionally.
According to StepSecurity's incident report, an account called hackerbot-claw ran a week-long campaign targeting GitHub Actions workflow weaknesses across high-profile repositories, including projects linked to Microsoft, DataDog, CNCF, and other large open-source maintainers. Their report describes multiple successful exploit paths and at least one case of token exfiltration with write permissions.
If your business ships software with GitHub Actions, this is not "big-tech-only" news. The attack methods are mostly workflow design flaws that appear in SMB repos all the time.
What is verifiable from the primary report
StepSecurity documents activity between Feb 21 and Feb 28, 2026, including:
- Multiple pull requests opened by the attacker across target repositories
- Several different exploitation techniques used (not just one payload pattern)
- A repeated payload delivery pattern involving
curl ... | bash - A case in
avelino/awesome-gowhere aGITHUB_TOKENwith write scopes was reportedly exfiltrated - A prompt-injection attempt against an AI code review workflow in
ambient-code/platform, where Claude reportedly detected and refused malicious instructions
Primary source: StepSecurity incident report.
Signal source that amplified the report: AISecHub post on X.
Why this matters for SMB teams
Most SMB engineering teams are fast-moving and understaffed. That usually leads to "it works, ship it" workflow patterns that quietly increase CI/CD blast radius:
- Over-permissioned
GITHUB_TOKEN pull_request_targetused without strict guardrails- Script execution paths that include untrusted input
- Slash-command workflows (
/format,/sync-metadata, etc.) with weak authorization checks
The Hackerbot-Claw campaign matters because it shows these are now being tested at scale by automation. You are no longer waiting for a manual attacker to notice your repo.
The three workflow mistakes to audit first
1) Untrusted code execution under privileged triggers
The highest-risk pattern is running fork-originated code in a pull_request_target workflow with elevated token permissions. This is the classic "Pwn Request" class of flaw.
Action: Audit every workflow using pull_request_target. If it checks out PR head code and executes scripts/build steps, treat it as critical risk until proven safe.
2) Unsanitized expression interpolation inside shell commands
StepSecurity's examples include injection via branch names and filenames where ${{ }} values are inserted into shell contexts without sanitization.
Action: Move GitHub expression values into environment variables and quote defensively. Avoid direct interpolation into shell command strings.
3) Over-scoped workflow token permissions
If a quality check only needs read access, write permissions are unnecessary risk. In the reported token exfiltration case, write scopes materially increased impact.
Action: Set explicit least-privilege permissions: blocks per workflow. Default to read-only and grant write scopes only when required.
A practical one-week hardening plan
If you have a small team, this is a realistic sequence:
Day 1: Inventory and classify workflows
- List all workflows and triggers
- Flag
pull_request_target,issue_comment, and external-input paths
Day 2: Lock down triggers and permissions
- Add
author_associationchecks where slash commands can trigger automation - Reduce token permissions to minimum viable scopes
Day 3: Sanitize script boundaries
- Refactor shell steps that interpolate branch names, filenames, PR metadata, or comments
- Prefer structured parsing over shell expansion where possible
Day 4: Add egress awareness
- Monitor or restrict outbound network calls from CI runners
- Alert on unexpected domains contacted during workflow execution
Day 5: Exercise incident response
- Rehearse token revocation and workflow disablement
- Document who can freeze pipelines and rotate secrets quickly
AI in CI is both force multiplier and attack surface
One of the most important details in this campaign is the attempt to influence an AI code reviewer via a poisoned repository instruction file. Whether you use Claude Code, Copilot flows, or internal LLM automation, this changes your threat model.
Treat AI assistants in CI as privileged automation components:
- Scope their permissions tightly
- Isolate untrusted inputs from trusted instruction channels
- Log what they were asked to do and what they actually executed
The upside is still real, but "AI-enabled development" now requires "AI-aware security controls."
Bottom line
The Hackerbot-Claw campaign is a preview of the near future: autonomous bots scanning for CI/CD misconfigurations continuously, across thousands of repos.
For SMB teams, the takeaway is simple: GitHub Actions hardening is no longer optional hygiene. It is a core reliability and risk-control function for your software business.
If you run production pipelines on GitHub, do the one-week hardening sprint now instead of after an incident.
Need help hardening your AI-enabled engineering workflows? Contact Barista Labs for a practical CI/CD security review tailored to small and mid-sized teams.