Gitea act_runner CVE-2026-58053

Exploitation requires (1) a Gitea act_runner configured with the Docker backend, (2) the ability to run a workflow on that runner - i.e., an authenticated user with workflow-execution/push rights (PR:L), and (3) that the workflow's container.options field is honored by the runner. The decisive condition is that act_runner merges attacker-controlled container.options (e.g. --pid=host, --cap-add, --security-opt) into the Docker HostConfig while only forcing Privileged off; privileged: false being set does NOT prevent the attack. Limiting factors that reduce real-world risk: the attacker must already be authorized to submit workflows, the runner must use the Docker (not host/LXC) backend, and instances that block or sanitize container.options or restrict runners to trusted workflows are not exploitable.

Signals are largely consistent and point to a genuine high priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with vulnerable- and subsequent-system impacts all High and a 9.4 score reflects a remotely reachable, low-complexity escape that crosses a trust boundary (container to host). PR:L correctly captures that the attacker must be able to submit/run a workflow, so this is not unauthenticated - exposure depends on who can push workflows to a Docker-backed runner. A public POC exists, increasing real-world likelihood, but the issue is NOT in CISA KEV and no EPSS score was provided, so widespread active exploitation is not confirmed; treat the POC as proof of practicality rather than evidence of mass exploitation. The main caveat: real risk is gated by trust model - instances that only run trusted internal workflows face limited exposure, while runners exposed to untrusted contributors (public forks, multi-tenant CI) are at severe risk.

A developer with permission to run CI on a Docker-backed Gitea act_runner authors a workflow that sets privileged: false but adds container.options like '--pid=host --cap-add=SYS_ADMIN --security-opt apparmor=unconfined'. The runner clears only the Privileged flag and applies the rest, giving the job container host namespace access and elevated capabilities, from which the attacker escapes to the host and gains root. A public POC for exactly this technique is available.