External risk intelligence

Gitea Act Runner Container Escape via Workflow Options

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-58053

The vulnerability resides in a Gitea act_runner, which is typically deployed as an internal build or automation agent within a CI/CD infrastructure. While it interacts with external workflows, the runner itself is generally located within protected internal network segments or isolated build environments rather than being directly exposed to the public internet.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability exists in Gitea's act_runner when using the Docker backend, allowing unauthorized access to host systems. This issue stems from how workflow options are processed, potentially enabling a malicious actor to gain root-level privileges on the host machine, even when privileged mode is disabled.

Runner can be used to escape its container.
Critical access allows host system takeover.
Confirm relevance and exposure to internal systems.

Attack Path

How an attacker could exploit the issue

An attacker with the ability to run workflows on a Docker-backed Gitea act_runner can exploit this vulnerability. The runner incorrectly handles specific container options passed from a workflow. By crafting a malicious workflow, an attacker can cause the runner to create a job container with host namespaces and broad capabilities, allowing them to escape the container and gain root access on the host system, even if privileged mode is disabled.

Attacker can run workflows.
Craft malicious workflow container options.
Escape container, gain root access.

Live Threat

Current exploitation, exposure, and threat context

A user who can run workflows on a Docker-backed Gitea act_runner could exploit this vulnerability to gain root-level access to the host system by crafting specific container options, even when the runner is configured without privileged mode. This could allow an attacker to control the underlying host.

Host system access.
Workflow execution with crafted options.
Host system compromise.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability in Gitea act_runner with the Docker backend requires that an attacker first gain the ability to run a workflow. The platform team or DevOps engineers responsible for the CI/CD infrastructure should take the lead in identifying affected runners, while application owners need to confirm the criticality of the workflows executed on them. The initial practical move is to locate all Docker-backed act_runners, verify their network exposure, and identify the owning team to prioritize remediation based on risk.

Platform and DevOps teams own the issue.
Verify runner access and workflow criticality.
Plan risk-based remediation actions.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Gitea act_runner?

Gitea act_runner is a component that executes automation tasks, known as workflows, within a Gitea CI/CD environment. When configured with a Docker backend, it spins up isolated containers to perform build and deployment processes. It acts as an intermediary between the Gitea server and the execution environment, translating automation instructions into containerized tasks on a host machine.

What does CVE-2026-58053 mean by container escape?

This vulnerability involves an Improper Privilege Management flaw, categorized as CWE-269. The runner incorrectly merges container configuration settings, which allows a workflow to bypass security restrictions. Essentially, a task meant to be contained can break out of its isolated sandbox to interact directly with the underlying host system, granting the workflow unauthorized control.

How can an attacker trigger this vulnerability?

An attacker needs the ability to submit or run a workflow on a vulnerable Docker-backed runner. By injecting specific flags—such as host namespace mappings or security-related capability additions—into the workflow's container options, they force the runner to ignore security constraints. Simply executing a standard, non-malicious workflow does not trigger this behavior; it requires the intentional inclusion of these restricted configuration options.

Is my runner at risk according to Halo Surface Signal?

Halo Surface Signal identifies this risk as unlikely to be internet-facing. Because act_runners typically function as internal build agents, they are usually shielded within protected network segments rather than exposed directly to the public web. However, the risk remains internal; anyone with the authority to run workflows on your CI/CD platform could potentially use this flaw to compromise the runner's host system.

How should I respond to CVE-2026-58053?

Start by identifying all deployed act_runners that utilize the Docker backend within your infrastructure. Once located, verify which teams manage these runners and assess the sensitivity of the workflows processed by them. Focus your remediation efforts on environments where unauthorized users have workflow execution permissions, as these pose the highest risk of host system compromise.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.