The Attacker Was an Agent: What 2026's GitHub Actions Campaigns Mean Before pull_request_target Is Blocked on December 2

What Changes on December 2, and Who Does It Affect?

On 2 November 2026 GitHub announced that starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories, unless an Actions event policy explicitly allows them. Enforcement had originally been scheduled for 2 November. The rule runs in evaluate mode first, with two brownouts between 16:00 and 18:00 UTC on 9 November and 16 November, during which blocked workflows fail with an error annotation instead of running.

The scope is narrower than many headlines suggest. According to the same changelog entry, the default applies to public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories are not affected, and neither is GitHub Enterprise Server. Teams that depend on the trigger can opt back in through an event policy and target specific workflow files.

This is the second tightening in a year. In November 2025 GitHub changed the trigger so that the workflow file and checkout commit are always taken from the repository's default branch, effective 8 December 2025, which closed the trick of running outdated, vulnerable workflow files from old branches. A platform vendor does not block a feature by default unless the incident data has become hard to ignore. In 2026 it did.

If your company maintains open-source SDKs, plugins, documentation sites or public tooling, this affects you directly. If all your code is private, it still matters, because the actions and tools your private pipelines run are mostly built in public repositories, and that is where this year's attacks started.

Why Is pull_request_target So Dangerous?

GitHub Actions has two triggers for pull requests. The ordinary pull_request trigger runs fork contributions with a read-only token and no access to secrets. The pull_request_target trigger exists for jobs that need more, such as labelling a pull request or posting a comment. As GitHub Security Lab explains, it runs in the context of the target repository and has write permission to it.

That is safe as long as the job never runs code from the pull request. The problem is that many workflows check out the contributor's branch and then run a build, a linter, a test suite or an install step. At that point an outsider's package.json scripts, conftest.py or build.rs execute with the base repository's token and secrets. GitHub Security Lab calls combining the trigger with an explicit checkout of untrusted code a dangerous practice, and notes that even without running PR code, the read/write token is still in memory for the duration of the job.

The pattern has been documented since 2021 and is widely known as a "pwn request". What changed in 2026 was not the vulnerability. It was the cost of finding it. Scanning thousands of public workflow files for a risky trigger, reading each one to work out which file gets executed, and writing a tailored payload used to take a skilled human hours per target. This year it was done by bots, at volume, around the clock.

For engineering leaders the lesson is uncomfortable but simple. CI configuration is code that runs with production-grade credentials, and in most organisations it receives a fraction of the review that application code gets. YAML that one engineer copied from a blog post in 2022 can still be the shortest path to your release keys.

February: A Self-Described AI Agent Took Over Trivy's Repository

Between 21 February and 2 March 2026, a GitHub account called hackerbot-claw systematically scanned public repositories for exploitable GitHub Actions workflows, according to StepSecurity's investigation. The account described itself as an "autonomous security research agent powered by claude-opus-4-5". That label is self-reported and cannot be verified, but the behaviour fitted it: methodical scanning, several distinct techniques, and payloads adapted to each target.

StepSecurity documented attempts against at least seven repositories, including microsoft/ai-discovery-agent, DataDog/datadog-iac-scanner, avelino/awesome-go, the CNCF project akri, RustPython and aquasecurity/trivy, and remote code execution in at least four of them. The techniques went beyond the classic pwn request: a poisoned Go init() function in a checked-out pull request, a shell line injected into a script triggered by a comment command, command injection through a crafted branch name, and command injection through a crafted filename.

Trivy, the widely used open-source vulnerability scanner, suffered the worst outcome. A pull request triggered an API diff workflow that ran on pull_request_target and executed code from the fork. Nineteen minutes after that run, a stolen personal access token was used to push directly to the repository. Citing Aqua Security's disclosure, StepSecurity reports that the token was used to make the repository private and rename it, delete GitHub releases from v0.27.0 to v0.69.1, and push a suspicious artifact to Trivy's VS Code extension on Open VSX. When the repository was restored, its star count had dropped from more than 25,000 to about 25.

Think about what that means for a company that installs Trivy in its own pipelines. For a period, the tool you use to find vulnerabilities in your containers was itself distributed from a compromised project. Nothing about your private repository configuration would have protected you from that.

March: The Second Compromise and the Cost of an Incomplete Rotation

Aqua rotated credentials after the February incident. It was not enough. In its advisory for CVE-2026-33634, Aqua states that the credential rotation was performed but was not atomic, meaning not all credentials were revoked at the same time, and an attacker may have held a valid token during a rotation window that lasted a few days.

On 19 March 2026 that window was used. The Aqua advisory describes a malicious Trivy v0.69.4 release available for roughly three hours, 76 of 77 trivy-action version tags force-pushed to malicious commits for roughly twelve hours, and all seven setup-trivy tags repointed as well. Any workflow that referenced trivy-action by a version tag such as @0.34.2 silently started running the attacker's code.

The payload targeted exactly what CI runners hold. According to StepSecurity's analysis of the second compromise, it read the GitHub Actions runner's worker memory to extract secrets, harvested environment variables, collected cloud, Kubernetes, Docker and SSH credentials, encrypted the result and sent it to a lookalike domain. StepSecurity's advice was blunt: assume that any secret the runner had access to was captured.

Two engineering lessons follow. First, a version tag on a GitHub Action is a mutable pointer, not a version. The Aqua advisory itself recommends pinning actions to full, immutable commit SHAs. Second, incident response in CI is a race. If revoking every token, deploy key and service account cannot be done in one coordinated step, an attacker who is already inside will simply use the credential you rotate last.

April: prt-scan and the Economics of Attacking at Machine Speed

The third campaign showed what this looks like once it is industrialised. Wiz Research traced the campaign it named prt-scan to activity beginning on 11 March 2026, three weeks before public disclosure, run by one actor across six GitHub accounts in six waves. Security researcher Charlie Eriksen flagged it publicly on 2 April, after one account opened more than 475 malicious pull requests in 26 hours.

Each pull request was titled "ci: update build configuration" and injected a payload into whatever file the target's CI would execute: conftest.py for Python projects, package.json scripts for Node, build.rs for Rust, or a composite action.yml. Wiz describes AI-generated, repository-aware wrappers and a sustained pace of about seven pull requests per hour for more than 22 hours, which it reads as indicators of AI assistance.

Most attempts failed. Across more than 450 analysed exploit attempts, Wiz observed a success rate below 10%, which still added up to dozens of compromises. Wiz verified theft of AWS keys, Cloudflare API tokens and Netlify auth tokens, and the attacker compromised two npm packages across 106 versions. Projects including Sentry, OpenSearch and NixOS blocked the attack with contributor approval gates, workflows restricted by actor, and path-based trigger conditions.

That failure rate is the real point. When an attack costs almost nothing to attempt, a 90% failure rate is perfectly acceptable to the attacker. The defensive model of "we are too small to be a target" stops working when targeting is automated. Every repository with a vulnerable workflow is a target, and the scanner will find it whether or not anyone has heard of your company.

Your AI Code Reviewer Is Now Part of the Attack Surface

One of the hackerbot-claw attempts deserves particular attention from teams adopting AI in CI. The target ran an automated code review workflow on pull_request_target that checked out the fork and ran Claude Code with write permissions. The attacker replaced the repository's CLAUDE.md with instructions telling the agent to commit a change to the README and post a fake "Approved and ready to merge" review.

This attempt failed. StepSecurity reports that the model identified both injection attempts and refused them, and that the workflow's tool allowlist limited it to a handful of read and comment commands. But the configuration also allowed any user, including users without write access, to trigger the workflow. The defence held because of one model's judgement plus one well-scoped allowlist. That is not a margin most security teams would accept for a job holding a write token.

The broader pattern is that AI review bots, triage agents and auto-fix workflows are exactly the kind of job that needs the dangerous combination: untrusted input from a pull request, plus permissions to comment, label, commit or approve. Agent instruction files such as CLAUDE.md and AGENTS.md are now executable configuration in practice, and an outsider can propose changes to them in any pull request. We covered the wider risk of agents reading attacker-controlled text in our article on prompt injection against coding agents.

The practical rules are straightforward. Run AI review on the ordinary pull_request trigger with read-only permissions wherever possible. When an agent must write, gate it behind a maintainer label or comment from a user with write access. Give it an explicit tool allowlist, never a shell. Protect agent instruction files with CODEOWNERS so that changes require maintainer review. And never let an AI review count as the approval that satisfies branch protection.

Private Repositories Are Not Exempt From the Lesson

It is tempting for a company with only private repositories to read the December 2 change as someone else's problem. It is not, for three reasons.

First, your pipelines consume public actions. The 2025 compromise of tj-actions/changed-files, tracked as CVE-2025-30066, let attackers read secrets from workflow logs, and CISA noted that it was potentially enabled by the compromise of another action, reviewdog/action-setup. The 2026 Trivy compromise followed the same path. In both cases, private repositories that referenced a mutable tag ran the malicious code.

Second, the trigger is not the only weakness. Branch-name and filename injection, the techniques used against Microsoft's and Datadog's repositories in February, arise whenever a workflow interpolates attacker-controlled text into a shell command. Inside a company, the person who controls a branch name might be a contractor, a compromised laptop or a coding agent following instructions it found in a ticket. Our analysis of how coding agents find workarounds shows how quickly internal automation ends up handling untrusted input.

Third, the credentials in a CI runner are usually more powerful than those on any developer's laptop: cloud deploy roles, package registry tokens, signing keys. We set out how those credentials accumulate in our piece on secrets sprawl and AI agents. A runner that can reach production is a production system, whether or not the repository is public.

A Hardening Checklist to Finish Before the Brownouts

The brownouts on 9 and 16 November give public repository owners a free test. GitHub suggests using Insights to see which workflow runs the rule would block before the first one. Do that this week, and decide for each workflow whether it really needs the trigger. In most cases it does not, and GitHub's own advice is that if a workflow does not require elevated permissions or access to secrets, use pull_request instead.

Then fix the things the new default does not touch. GitHub's secure use guidance recommends pinning actions to a full-length commit SHA, locking workflow dependencies where possible, and setting the default GITHUB_TOKEN permission to read-only for repository contents. Since August 2025, organisation administrators can enforce SHA pinning through the allowed actions policy, so that any workflow using an unpinned action fails, and block specific actions or versions outright.

Move every ${{ }} expression that contains a branch name, title, filename or comment body out of run: blocks and into environment variables, so it is treated as data rather than shell. Require approval for workflow runs from first-time and outside contributors. Restrict egress from runners where you can, so that a payload cannot reach its collection server. And write down, before you need it, how you would revoke every CI credential in a single step.

Finally, put CI under the same review standard as application code. Add .github/workflows and agent instruction files to CODEOWNERS, review workflow changes like infrastructure changes, and include CI in your threat model and penetration tests. For pipelines already straining under agent-generated pull requests, our article on CI capacity in the agent era covers the reliability side of the same problem.

Where a Senior Nearshore Team Fits

None of this work is glamorous, which is precisely why it gets postponed. Auditing a hundred workflow files, replacing tag references with SHAs, rewriting injection-prone steps and restructuring AI review jobs is careful, detailed engineering. It competes for the same senior attention as the roadmap, and the roadmap usually wins until an incident decides otherwise.

This is a good fit for a focused engagement with an experienced partner. Stepto's DevOps and platform engineers audit GitHub Actions estates, fix risky triggers and token scopes, set up SHA pinning with automated update bots so pinned actions do not go stale, and design AI review and auto-fix workflows that are useful without holding write access to untrusted input. Where security depth is needed, our cybersecurity consulting team adds threat modelling and CI-focused testing.

For companies that want this to stay fixed rather than be fixed once, a dedicated development team can own pipeline security as an ongoing part of delivery: reviewing workflow changes, keeping action pins current, and responding when the next compromised action is announced. Our engineers work from Serbia with full overlap with European business hours and a usable overlap with the US East Coast, so a credential rotation does not wait for the next day's stand-up.