The Sysdig Threat Research Team (TRT) has discovered CVE-2025-32955, a now-patched vulnerability in Harden-Runner, one of the most popular GitHub Action CI/CD security tools. Exploiting this vulnerability allows an attacker to bypass Harden-Runner’s disable-sudo security mechanism, effectively evading detection within the continuous integration/continuous delivery (CI/CD) pipeline under certain conditions. To mitigate this risk, users are strongly advised to update to the latest version.
The CVE has been assigned a CVSS v3.1 base score of 6.0.
To better understand the initial vulnerability discovery and impact of the security vulnerability, which could affect other CI/CD security products, let’s explore the Sysdig TRT’s findings.
Overview of Harden-Runner
Harden-Runner is an open source GitHub Action written in TypeScript that improves the security of GitHub Action workflows by hardening running jobs’ environments. Its goal is to help defenders protect these runners from untrusted workflow abuse, which is especially important in open source and public repositories. Harden-Runner is very straightforward to use, which explains why it was adopted so quickly by a wide number of public and non-public repositories. A user can start using Harden-Runner by adding an initial step to the job they wish to protect, as shown below:
steps:
- uses: step-security/harden-runner@c6295a65d1254861815972266d5933fd6e532bdf # v2.11.1
with:
egress-policy: auditCode language: PHP (php)When using GitHub-hosted runners, each job runs in an ephemeral virtual machine (VM). The runner process inside the VM is responsible for executing all the steps declared in the workflow file, which allows users to build, test, release, and perform additional tasks on their software.
The community tier Harden-Runner GitHub Action installs the step-security agent, a Go application that provides runtime visibility. By installing this component within the VM processing the job’s steps, the user can access a wide variety of features. The most important features, relevant for both this article and adopters of the action, are as follows:
- Auditing or blocking network egress traffic based on IPs or DNS domain names
- Disabling
sudoaccess for the Linuxrunneruser account inside the protected job VM
Are your GitHub Actions secure?
The recent tj-actions/changed-files compromise (CVE-2025-30066) shook the security community, exposing the CI/CD secrets of thousands of repositories to public logs – a discovery for which we must thank StepSecurity. The attack was discovered through the anomaly detection features provided by the Harden-Runner GitHub Action. This is a widely adopted security measure used to protect against supply chain attacks.
In security, we are taught to question everything’s validity. In that spirit, let’s ask a simple question: How effective is this security solution? Does it provide an additional layer of security, or is it easy for a skilled attacker to bypass the security policies it’s enforcing? By answering these questions and exploring the bypass we found, we hope to provide stronger security measures to protect CI/CD workflows running on GitHub Actions.
CVE-2025-32955: Bypassing the disable-sudo feature of Harden-Runner
Due to the nature of GitHub Actions, attackers can gain code execution within the VMs running the jobs in a multitude of ways. The Sysdig TRT inspected the open-source code for the community tier StepSecurity agent, looking to audit Harden-Runner’s resilience. In particular, we tried to understand how the detection and prevention of connections to IPs and DNS domains were implemented. Additionally, we wanted to see how the agent disables sudo access for the Linux runner user account (which is the same user executing the runner application processing the steps of our job).
For the first part, TRT observed that IP auditing and blocking are carried out using IPtables rules. This is a traditional method for implementing firewall rules, and many technologies leverage it. As we can see, there are a few rules being set here.
On the other hand, DNS monitoring and blocking are handled by a custom DNS Proxy server, which is initialized in the dnsproxy.go file. The server will run in a separate goroutine, listening for incoming DNS requests. To redirect all DNS queries of processes inside the VM, the agent stops the systemd-resolved service and rewrites the /etc/resolv.conf file to use the local IP address for DNS resolution. The original configuration is backed up to /tmp/resolved.conf, and the service is then restarted. Upon restart, the service picks up the new configuration, allowing the agent to monitor any DNS queries made in the system and potentially block them if configured to do so.
Lastly, regarding the implementation of the disable-sudo policy, we can see that the agent limits itself to moving the sudoers file used by the Linux runner user account to/tmp/runner. The sudoers file is read every time sudo is executed and is used to retrieve the commands that a user may run with elevated privileges. In the case of GitHub-hosted runners, the Linux runner user account can run any command, as stated in the default /etc/sudoers.d/runner file. Moving the file from this location means disabling sudo for this user.
Digging deeper into how the GitHub-hosted VM is configured, we noticed that the Linux runner user account belongs to the docker group. This means that it is a root-equivalent user. Being a member of this group allows the user to communicate through the Docker socket to the Docker daemon, a privileged process on the host. This allows the user to conduct privileged activities, such as running privileged root containers and mounting the entire host file system into the container. Disabling sudo to prevent root access turned out to be an insufficient security measure. It must be noted that the Linux runner user account must be in the Docker group, and this cannot be changed by the user. This is because, among other things, the actions that a legitimate user may want to run could also be a container.
Putting it all together, to bypass disable-sudo, an attacker could just execute the following commands:
# Restore the sudoers file using a privileged container with host filesystem mounted
docker run --rm --privileged -v /:/host ubuntu bash -c "cp /host/tmp/runner /host/etc/sudoers.d/runner"
Code language: PHP (php)After the execution of these commands, an attacker can proceed to perform operations as a root user using sudo inside the runner. This means being able to run commands with the same level of privilege as the agent, restoring network configurations to disable any security mechanism in place without being detected by Harden-Runner.
Impacts and mitigation
CVE-2025-32955 has been assigned a CVSS v3.1 base score of 6.0.
The integrity and availability of the Harden-Runner GitHub Action are impacted by this vulnerability:
- Integrity: By exploiting the vulnerability and gaining sudo access within the
runner, the attacker can modify files and network configurations to disable security mechanisms in a controlled manner, thereby compromising the system’s integrity. - Availability: With sudo access, the attacker can disrupt or interfere with security mechanisms and monitoring processes, potentially rendering them ineffective without detection.
CVE-2025-32955 is remediated in Harder-Runner version v2.12.0, which was released on April 21, 2025. We strongly advise updating to this version or above to mitigate this security risk.
Conclusion
Supply chain attacks and related threats are a top priority for modern security teams and developers, and they are quickly becoming a favorite tactic for attackers. By exploiting CVE-2025-32955, an attacker could remain undetected and nearly unrestricted in a workflow that uses Harden-Runner, one of the most widely adopted tools in GitHub Actions CI/CD environments. By bypassing the agent’s disable-sudo security mechanism, the attacker can escalate privileges and disable security controls, allowing the attack to continue undisturbed until discovered.
Disclosure Timeline
January 20, 2025 — The Sysdig TRT reported the security issue to StepSecurity
January 21, 2025 — StepSecurity acknowledged the reported issue
April 21, 2025 — StepSecurity released version v2.12.0 to fix the security issue
April 21, 2025 — Public disclosure via GitHub Security Advisory (GHSA)