Over the past three years, researchers have highlighted the risks associated with GitHub Actions. These threats became manifest with two recent incidents.
First, last December brought a supply chain attack where attackers exploited a vulnerable GitHub Actions workflow to introduce an XMRig cryptominer to deployment versions of the Ultralytics Python package. Then, in March, we had the “tj-actions" incident. The attacker in this incident took advantage of multiple common anti-patterns associated with GitHub Actions and clearly leveraged the existing research literature to inform their tactics. An in-depth analysis of that incident is available in our blog posts:
GitHub Action tj-actions/changed-files supply chain attack: everything you need to know
New GitHub Action supply chain attack: reviewdog/action-setup
As a short recap:
A vulnerability in
spotbugs/sonar-findbugsallowed an attacker to compromise the Personal Access Token (PAT) of a Spotbugs contributorThat compromised PAT was used to grant a temporary, malicious user
spotbugs/spotbugsrepository accessThe write access to
spotbugs/spotbugswas used to push a malicious workflow to a branch, leaking the Github secrets – including the PAT of a mutualspotbugsandreviewdogcontributorThe
reviewdogaccess was then used to briefly poisonreviewdog/action-setup@v1, which allowed the attacker to further compromise atj-actionsPATThe
tj-actionsaccess was used first to target Coinbase (unsuccessfully), and was then burned with a broad attack that changed all tj-actions versions to include malicious code
In the follow up to this incident, we know many organizations are investing in reviewing and hardening their GitHub Actions posture. We hope this guide serves as a cheat sheet for this complicated landscape, complementing Github’s first party guidance.
GitHub Actions: Essential Terminology
It’s important to establish the key terms relevant to this domain:
GitHub Actions: A suite of automation features within GitHub that lets you automate tasks in your software development lifecycle. Actions can be used to build, test, and deploy code, among other things.
Workflow: A collection of automated tasks, defined in a YAML file, that runs in response to specific events within your GitHub repository. Think of it as a script that automates a series of Actions. Workflows can be triggered by events like pushing code, creating a pull request, on a schedule, or on demand.
Action: A reusable unit of automation that can be referenced and executed within Workflows. These can be created by you or pulled from the Marketplace and are essentially optional building blocks of Workflows. You can think of Actions like functions in a programming language—small, self-contained tasks that are reusable across Workflows.
Event: The trigger that starts a Workflow. Common events include code pushes, pull request creations, or manual triggers.
Job: A unit of work within a Workflow. Workflows can contain multiple Jobs, and each Job can run tasks (Actions). Jobs in a Workflow can run in parallel or sequentially, depending on how they're configured. Job is the minimal unit of execution schedulable on a runner.
Basically, Workflows are your automation scripts, which are built from the embedded Job code and referenced Actions.
Configuring GitHub for Safer GitHub Actions
Securing GitHub Actions starts with hardening your GitHub environment. First, secure GitHub Actions through organization-level administrative settings.
1. Set Read-Only Default Workflow Permissions
By default, the Workflow Token Permissions were set to read-write prior to February 2023. For security reasons, it's crucial to set this to read-only. Write permissions allow Workflows to inadvertently or maliciously modify your repository and its data, making least-privilege crucial.
Double-check to ensure this permission is set correctly to read-only in your repository settings.
2. Limit Actions to Verified Actions and an Allowlist
One of the key security measures is to control which Actions can run within your Workflows. You can restrict Workflows to only use verified Actions from trusted sources. This includes:
Actions created by GitHub: These are Actions maintained and supported by GitHub itself.
Actions from Marketplace-verified creators: Actions from verified creators in the GitHub Marketplace are more trustworthy, as they have undergone some level of review.
You can then use an allowlist of specific other trusted or reviewed Actions to extend permitted sources.
3. Govern Workflow Adoption and Restrict Runners to Specific Repositories
To tighten security, use a repository allowlist to control where Workflows can be adopted, and restrict self-hosted runners to specific repositories.
This ensures only trusted Workflows and runners are executed, reducing the risk of unauthorized access and execution.
4. Avoid ‘Allow GitHub Actions to Create and Approve Pull Requests’
Enabling this setting grants Workflows the ability to create and approve pull requests, which can be risky. Ensure this setting is deactivated, to prevent Workflows from making changes to pull request approvals or creating pull requests without manual oversight.
Branch Protection
In addition to organization-level settings, there are also repository-level controls that help secure your Workflows. Most importantly, Branch Protection and rulesets enforce rules before code can be merged, ensuring only trusted code makes it into your main and release branches. This is important because attackers often target these branches to exploit vulnerabilities in your CI/CD pipeline, where automated Workflows like deployments or tests could be manipulated.
However, branch protection has limitations. Malicious commits post-approval is an attack that occurs when an attacker injects malicious changes after a pull request is approved but before it’s merged. Pull request hijacking can happen when attackers add harmful changes to someone else's pull request, then approve it themselves. GitHub offers configuration options to close off these attack paths: “Dismiss stale pull request approvals when new commits are pushed” for the former, and “requiring an approval from someone other than the last person to push” for the latter.
However, it can be unreasonable to enable those options in agile environments, where rapid merging and flexibility are prioritized. Implementing commit signing and out-of-band detection can provide an additional layer of security.
Secrets Management for GitHub Actions
Secrets play a role in most attacks on Github Actions. They offer opportunities for pivoting, persistence, and privilege escalation. There are three types of secrets in GitHub: repository, organization, and environment.
Repository-level secrets are specific to a single repository and should be the default choice.
Organization-level secrets are useful when you want to share secrets across multiple repositories, reducing duplication and ensuring updates or rotation propagate automatically. They work well for credentials used by general CI infrastructure, like shared build tools or third-party service tokens.
Environment-level secrets offer granular control. These secrets are only available to Jobs that reference the environment, and additional protection can be enforced with required approvals from reviewers, ensuring they are only accessible for approved Workflows. This can be ideal for sensitive actions like deployment, where you might want to restrict access from non-reviewed or unmerged pull requests.
By default, secrets (except GITHUB_TOKEN) are not passed to the runner when a Workflow is triggered from a fork and are not passed to GitHub Actions unless explicitly passed as an input or environment variable in your Workflow file.
However, beware: Any user with write access to your repository has read access to all secrets configured in your repository. So, make sure any credentials used in Workflows are safe to be exposed to that group.
Safely Writing GitHub Workflows
Now that we’ve covered your GitHub Organization and Actions’ configuration, let’s talk about the risks to avoid when constructing your own GitHub Workflows.
Permissions
When writing GitHub Workflows, it's essential to manage permissions carefully. Organizations created before February 2023 are particularly vulnerable to misconfigurations due to legacy settings that grant Workflows excessive (read-write) access by default.
You can explicitly set `permissions: {}` at the Workflow level, which forces Job-level specification of any necessary permissions. This can be a powerful tool for encouraging least-privilege Workflows, while reducing the exposure of GITHUB_TOKEN, or risk associated with it, to unnecessary Steps.
Using Third-Party GitHub Actions
Using third-party GitHub Actions introduces risks, especially considering incidents like the tj-actions compromise. When referencing third-party actions in your Workflows, you can either hash pin or use tag-based versioning. However, only hash pinning ensures the same code runs every time. It is important to consider transitive risk: even if you hash pin an Action, if it relies on another Action with weaker pinning, you're still exposed. To reduce risk, prioritize Verified and GitHub-created (action/ and github/) Actions over random third-party Actions.
Outside of verified and GitHub-created Actions, there are several heuristics you can use to assess the risk of a third-party Action. First, consider the number of contributors; a higher number brings expanded attack surface. Next, evaluate the code complexity. Overly complicated Actions may be harder to audit for vulnerabilities and harder to trust. Popularity is another useful indicator, as more widely used Actions tend to have a larger community checking for issues. Finally, ensure that the Action follows best practices, such as proper version pinning and other safeguards we've outlined, to mitigate risks associated with supply chain vulnerabilities.
Ultimately, minimize the use of third-party Actions, as securing the supply chain comprehensively remains challenging.
Secrets
When working with secrets, they should be passed into the Step level env, only where needed. GitHub Actions can only read a secret if you explicitly include the secret in a workflow.
Avoid accessing the entire secrets context, such as:
# Bad, do not use this
env:
SECRETS: ${{ toJson(secrets) }} This antipattern exposes all secrets to the runner—even if only one is required. Instead, secrets should be accessed individually by name to limit exposure.
Along the same lines, avoid using secrets: inherit in reusable Workflows. Instead, explicitly define the secrets required by the reusable Workflow, ensuring only the necessary ones are passed along.
Common Workflow Vulnerabilities
A number of security issues in GitHub Actions Workflows fall under the broader category of Poisoned Pipeline Execution (PPE). PPE refers to any situation where attacker-controlled input reaches trusted execution paths in the CI pipeline. In GitHub Actions, this typically happens when untrusted users can influence the code, configuration, or runtime behavior of Workflows that have elevated privileges—such as access to secrets or write permissions.
Pwn Request
One of the most common PPE scenarios in GitHub Actions is the misuse of high-privilege triggers like pull_request_target and workflow_run.
These triggers run Workflows in the context of the base repository, not the fork. This means they have access to repository secrets.
If a workflow triggered by pull_request_target checks out and executes code from the forked branch—using actions/checkout or similar—the attacker can influence execution while the workflow has access to secrets or privileged Actions. This creates a high-risk scenario.
Living Off The Pipeline
Many common CI/CD tools—linters, test runners, build systems, and security scanners—process files from the repository. Some of these tools include features that can execute code during configuration or initialization. This creates an opportunity for attackers to abuse legitimate tools to gain code execution in the pipeline.
GITHUB_ENV and GITHUB_PATH
Workflows should also avoid writing to GITHUB_ENV and GITHUB_PATH in any Step where attacker-controlled content might be used. These files influence subsequent Steps:
GITHUB_ENV allows setting environment variables
GITHUB_PATH modifies the system path
An attacker could use them to introduce malicious binaries or influence execution via environment variables like LD_PRELOAD. These mechanisms are powerful and should only be used in trusted contexts.
Command Injection via Attacker-Controlled Workflow Elements
Not all PPE involves misuse of triggers. In some cases, Workflows include logic that uses attacker-controlled inputs, generally through interpolated values in the run: Steps, dynamically evaluated parameters, or CLI arguments sourced from PR comments or issue metadata. This can lead to command injection.
Examples:
Using
run: some-command ${{ github.event.issue.title }}where issue titles are user-controlledInterpolating branch names, file contents, or labels directly into shell scripts
If Workflows use this type of dynamic behavior, inputs should be validated or sanitized. In many cases, it's safer to avoid interpolation entirely and pass values through well-defined interfaces (e.g., reusable Workflows with explicit inputs).
Artifact and Credential Handling
Workflows often use artifacts to share data between Jobs or Workflows. These artifacts can pose a security risk if they contain sensitive data (e.g., credentials, config files with secrets). actions/checkout persists a credential by default in .git/config. Later Steps have been known to accidentally publish that credential in an artifact, for example via actions/upload-artifact. Set persist-credentials: false to opt-out, unless necessary.
Safely Running GitHub Workflows
Safely running Workflows requires consideration of the underlying runner infrastructure. GitHub-hosted runners are ephemeral by default and tightly sandboxed, suitable for most use cases. However, teams often turn to self-hosted runners when they need faster execution, custom environments, or for cost optimization.
Self-hosted runners execute Jobs directly on machines you manage and control. While this flexibility is useful, it introduces significant security risks, as GitHub explicitly warns in their documentation. Runners are non-ephemeral by default, meaning the environment persists between Jobs. If a workflow is compromised, attackers may install background processes, tamper with the environment, or leave behind persistent malware.
To reduce the attack surface, organizations should isolate runners by trust level, using runner groups to prevent public repositories from sharing infrastructure with private ones. Self-hosted runners should never be used with public repositories. Doing so exposes the runner to untrusted code, including Workflows from forks or pull requests. An attacker could submit a malicious workflow that executes arbitrary code on your infrastructure.
When self-hosted runners are used, they should be instrumented as sensitive production infrastructure: monitor processes, log activity, and inspect behavior for signs of compromise. Wherever possible, use ephemeral infrastructure that tears down after each Job to minimize persistence opportunities. Consider limiting network egress, only allowing outbound connections to known and trusted destinations.
Finally, when Workflows connect to downstream systems, avoid long-lived secrets. GitHub supports OpenID Connect (OIDC), which allows Workflows to authenticate with cloud providers using short-lived, identity-bound tokens. This reduces credential risk and helps enforce fine-grained access control across your CI/CD pipeline.
Takeaways
This might seem overwhelming.
To start, focus on a few core tips to safely use Github Actions:
Minimize third-party attack surface through limiting third-party Actions, and hash pinning the Actions you use.
Minimize permissions and secrets granted to Workflows and used with third-party Actions, favoring OIDC where supported for integrations.
Avoid Poisoned Pipeline Execution through careful audits of high-privilege triggers and attacker-controlled workflow elements.
There are also open source tools available to help:
zizmor: a static analysis tool for GitHub Actions, with coverage for most of the common misconfigurations
gato and Gato-X: two variants of an enumeration and attack tool, each with unique features
allstar: a GitHub App to set and enforce security policies on GitHub organizations or repositories, from OpenSSF
Want the whole picture on risks in code and version control systems? Check out Wiz's 2025 State of Code Security Report
