Loading story…
Security guidance from GitHub Security Lab and Semgrep warned that unsafe GitHub Actions patterns can let attackers execute code in CI, steal secrets, and modify repositories. A key risk is using the privileged pull_request_target trigger while also checking out code from an untrusted forked pull request, which runs attacker-controlled code with target-repository secrets and potentially write-capable GITHUB_TOKEN permissions. The guidance also highlighted shell injection risks when workflows interpolate untrusted GitHub context fields such as pull request titles directly into run steps, as well as the danger of re-enabling deprecated insecure commands through ACTIONS_ALLOW_UNSECURE_COMMANDS.
The recommended mitigations focus on separating trust boundaries inside workflows. GitHub Security Lab advised using pull_request for untrusted forked PRs because it withholds secrets and write access, reserving pull_request_target only for limited privileged tasks such as labeling or commenting. It also recommended split-workflow designs in which untrusted PR code runs in one workflow and a separate workflow_run job consumes only safe artifact data, while warning that artifacts produced from untrusted PRs must still be treated as untrusted. Additional hardening steps included auditing third-party Actions, carefully handling environment variables and other untrusted inputs, enforcing branch protections, and scanning workflow files with Semgrep rules.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
Semgrep published a blog post describing common GitHub Actions risks, including shell injection via untrusted GitHub context fields, unsafe pull_request_target usage with untrusted code checkout, and insecure command re-enablement through ACTIONS_ALLOW_UNSECURE_COMMANDS. The post recommended mitigations such as treating context data as untrusted, limiting pull_request_target, auditing third-party Actions, and scanning workflows with Semgrep rules.
GitHub Security Lab released Part 3 of its GitHub Actions security series covering how to trust workflow building blocks. The publication expanded its documented recommendations for securing GitHub Actions components and dependencies.
GitHub Security Lab released Part 2 of its GitHub Actions security series focused on risks from untrusted input in workflows. This marked a further disclosure of GitHub Actions security pitfalls and defensive practices.
GitHub Security Lab published guidance explaining that combining the privileged pull_request_target trigger with an explicit checkout of untrusted pull request code can let attackers execute code, steal secrets, or gain repository write access. The post recommended safer split-workflow designs using pull_request for untrusted code and workflow_run for privileged follow-up actions.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
4 references tracked. Mallory keeps watching after this page renders.
semgrep.dev
Open sourcesecuritylab.github.com
Open sourcesecuritylab.github.com
Open sourcesecuritylab.github.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
GitHub released `actions/checkout@v7` with a new default safeguard that blocks unsafe checkouts of code from untrusted pull requests in privileged `pull_request_target` and some `workflow_run` scenarios. The change is designed to stop common “pwn request” patterns that can expose a repository’s `GITHUB_TOKEN`, secrets, cache access, and runner environment when workflows fetch and execute attacker-controlled fork code. GitHub said the protection is available immediately in v7 and will be backported to supported major versions, while narrowly pinned deployments must be updated manually. The move follows years of warnings about GitHub Actions supply-chain abuse and fresh examples showing how workflow misconfigurations can lead to token theft, cache poisoning, OIDC token abuse, and malicious package publication. Separately, a disclosed advisory tracked as `GHSA-C3XH-98XP-6QHF` described a command-injection flaw in a GitHub Actions workflow where an attacker could open an issue on a public repository with a crafted title and trigger shell execution on the runner, potentially exposing runner tokens and secrets including `DISCORD_WEBHOOK_URL_ISSUE`. Together, the developments underscore how untrusted repository input in CI workflows can quickly become credential exposure and downstream supply-chain compromise.
Jul 12, 2026
Researchers and maintainers disclosed multiple GitHub Actions security issues that could let attackers steal credentials or gain code execution in CI/CD pipelines. Sansec and Packagist warned that older Composer releases could print raw `GITHUB_TOKEN` values into GitHub Actions logs after rejecting GitHub’s newer hyphenated token format, creating a supply-chain risk for PHP projects, especially public repositories and older repositories where the default token still had write access. Composer issued fixes in versions `2.9.8`, `2.2.28`, and `1.10.28`, while GitHub rolled back the token format rollout to reduce immediate exposure. Separate disclosures showed how workflow design and cache handling can turn limited CI access into broader repository compromise. A newly assigned `CVE-2026-42603` affects OWASP BLT before `2.1.2`, where a privileged `pull_request_target` workflow checked out and executed code from an attacker-controlled fork, enabling remote code execution with repository write permissions. Earlier research on GitHub Actions cache poisoning described "Actions Cache Blasting," a technique that abuses client-controlled cache keys, cache eviction, and lingering runtime tokens to replace cached artifacts used by more privileged workflows, potentially leading to secret disclosure, release-signing compromise, and tampered build outputs without visible changes in source code or workflow logs.
Jun 29, 2026
Researchers reported that the `prt-scan` campaign abused misconfigured GitHub Actions workflows using the `pull_request_target` trigger to run attacker-controlled code from forked pull requests in privileged CI contexts. The actor used at least six GitHub accounts to submit more than 500 malicious pull requests across six waves, disguising many as routine CI updates and tailoring payloads to Python, Node.js, Go, Rust, and GitHub Actions repositories. Wiz said the operation evolved from simple bash payloads into AI-assisted, repository-aware implants designed to steal `GITHUB_TOKEN` values, enumerate secrets, probe cloud metadata services, and exfiltrate credentials through workflow logs and pull request comments. The campaign succeeded often enough to cause real supply-chain impact despite an estimated success rate below 10%. Wiz confirmed compromise of the npm packages **`@codfish/eslint-config`** and **`@codfish/actions`** across 106 versions, and verified theft of AWS keys, Cloudflare API tokens, and Netlify authentication tokens. High-profile projects including Sentry, OpenSearch, IPFS, NixOS, Jina AI, and recharts reportedly blocked the attempts through contributor approval gates and workflow restrictions. The activity follows earlier warnings from Sysdig that insecure use of `pull_request_target` in prominent repositories such as MITRE, Splunk, and Spotipy could expose secrets and high-privilege `GITHUB_TOKEN` permissions, underscoring that unsafe GitHub Actions defaults remain an active software supply-chain risk.
Jun 29, 2026