Gitea act_runner Docker container-hardening bypass to host escape (CVSS 9.4, public PoC)

CVE-2026-58053, Gitea act_runner Docker backend: container-hardening bypass to host escape (CVSS 9.4, public PoC)

Gitea act_runner through 0.262.0 with the Docker backend passes the workflow-defined container.options string straight into Docker's HostConfig for the job container. When an operator hardens the runner with privileged: false, the code forces only the Privileged flag off but still merges the rest of container.options unchanged, so options such as --pid=host, --cap-add=SYS_PTRACE, --security-opt=seccomp:unconfined or arbitrary bind mounts pass through, allowing any user with write access to a repository whose workflows run on that runner to escape to the host as root despite the hardening (VulnCheck, 2026-06-27; ENISA EUVD EUVD-2026-58053, 2026-06-28). ENISA EUVD scores it CVSS 4.0 9.4 and a public PoC is referenced. Technique class: T1611 Escape to Host via Docker HostConfig injection → T1068. Prerequisite is write access (or accepted external contribution) to a repo whose workflows execute on a Docker-backed runner configured privileged: false, the common hardened setting, which is what makes this dangerous. Self-service CI on internal Gitea + Docker is common in Swiss/EU public-sector and academic IT. Detection: watch Docker daemon audit logs for containers launched with unusual HostConfig flags (pid_mode=host, non-baseline cap_add, custom seccomp); review CI workflow-YAML diffs from external contributors for container.options injection. Mitigation now (vendor fix act_runner >= 0.263.0 was pending at advisory time): strip or allowlist container.options at the runner policy layer, require approval for fork/external-contributor workflow runs, and use a kernel-isolation runtime (e.g. gVisor) for untrusted CI.