CVE-2026-58053: Gitea act_runner Container Escape

Affected Versions and Exposure Scope

The affected product is Gitea act_runner using the Docker backend. The NVD description states the vulnerable behavior exists “through act 0.262.0.” That is the most specific version information available in the supplied source material. It is important to be precise here: the research note does not establish a complete vendor-maintained affected version range for act_runner itself, and it does not provide a first-party advisory tying the CVE to a specific fixed runner release.

Because of that limitation, defenders should avoid overconfidence in version-based scoping. If you operate Gitea act_runner with Docker-backed job execution and you cannot verify from vendor documentation that your deployed runner build includes a fix for CVE-2026-58053, you should assume exposure. The absence of a confirmed fixed version in the available sources means asset owners need to validate runner version, embedded act version where possible, and execution backend before making patch compliance claims.

The risk is highest in environments with shared or multi-tenant runners, public or semi-public repositories, permissive pull request workflows, or any model where repository maintainers do not fully trust every workflow author. By contrast, tightly controlled internal-only runners dedicated to a single trusted team face lower exploitation likelihood, but still carry significant impact if credentials are stolen or a developer account is abused.

Why This Vulnerability is Dangerous

This issue enables a workflow author to influence the Docker runtime configuration of the job container more than defenders likely intend. Disabling privileged mode sounds protective, but the NVD description makes clear that it is insufficient here because the runner still merges other security-relevant Docker options into HostConfig. If an attacker can set host namespaces or broaden capabilities, they may escape normal container isolation assumptions.

The likely outcome is host-level compromise of the runner machine as root. In a CI/CD context, that can be far worse than compromising a single build job. Runner hosts often have network access to internal package registries, source code, cloud credentials, deployment tokens, and secrets caches. A compromised runner can become a pivot point into development, staging, or production systems, especially in smaller organizations where CI/CD infrastructure is under-segmented.

This also changes incident response priority. If you suspect exploit attempts, do not treat the event as a contained job-level incident. Assume the host may be compromised and any secrets accessible from that host may be exposed. That includes Gitea registration tokens, Docker credentials, SSH keys, cloud IAM material, and any artifacts processed during the runner’s lifetime.

Technical Notes

The NVD description identifies these example options as dangerous when passed through unchanged:

jobs:
  build:
    runs-on: self-hosted
    container:
      image: alpine:latest
      options: --pid=host --cap-add=SYS_ADMIN --security-opt apparmor=unconfined

Why this is risky:

--pid=host         -> shares host PID namespace
--cap-add=...      -> grants additional Linux capabilities
--security-opt ... -> can weaken LSM confinement such as AppArmor or seccomp

Exploitation Status

A public proof of concept is known. The supplied references include a GitHub PoC repository: https://github.com/bikini/exploitarium/tree/main/gitea-act-runner-container-options-poc. That means defenders should assume exploit details are available to researchers and attackers, even if weaponization quality varies. Public exploit material significantly lowers the barrier to testing exposed environments.

At the same time, confirmed exploitation in the wild is not established from the provided sources. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog as of 2026-06-28, and the KEV lookup result is on_kev=false. That is useful context, but it should not be misread as low risk. KEV is a lagging indicator and self-hosted CI/CD infrastructure is often under-reported in public exploitation telemetry.

Operationally, the most accurate status is this:

In the absence of authoritative exploitation telemetry, defenders should assume opportunistic exploitation is plausible anywhere untrusted workflow execution is allowed. A critical CI/CD breakout with a public PoC is the kind of issue that gets tested quickly by red teams, bug hunters, and attackers scanning for weak self-hosted automation.

What Defenders Should Do Next

First, inventory every Gitea act_runner instance and identify which ones use the Docker backend. If you do not know the backend, treat that as a gap to close immediately. Mapping trust boundaries is just as important as version discovery here, because exploitability depends heavily on who can run or modify workflows targeting those runners.

Second, prioritize exposure based on workflow trust. Public-facing repositories, shared runners, and environments that execute pull-request or contributor-controlled code should move to the top of the response queue. If necessary, temporarily disable those runner assignments while investigating. That is a reasonable business decision for a host-root CI/CD breakout issue with a public PoC and no clearly verified fixed version in hand.

Third, prepare for the possibility that host compromise has already occurred anywhere suspicious workflow activity is found. Preserve runner logs, Docker events, container metadata, and host forensic artifacts before cleanup. Rotate secrets reachable from the runner, rebuild compromised hosts from clean images, and avoid returning the same machine to service without re-provisioning.