Critical Flaw in Gitea act_runner Lets Workflow YAML Bypass Privileged-Mode Protections for Host Takeover
What Happened
A GitHub Security Advisory (GHSA-x4q3-gcj3-m6cf, tracked as CVE-2026-73802, CVSS 9.9) discloses a flaw in Gitea's act_runner. According to the advisory, workflow-controlled jobs.<job>.container.options values are appended directly to the Docker HostConfig used to create job containers. When runner privileged mode is disabled, only the Privileged flag itself is forced to false — host namespace flags (--pid=host, --ipc=host), capability expansion (--cap-add=ALL), and security profile overrides (seccomp=unconfined, apparmor=unconfined) from the workflow YAML are preserved into the final container configuration. The advisory notes sanitizeConfig() currently only filters Binds and Mounts, leaving these other fields untouched. A proof-of-concept is publicly available showing a workflow using nsenter to reach the host PID namespace and write a file as root.
Why It Matters
Per the advisory, any attacker able to submit a workflow to a repository served by a shared, Docker-backed act_runner can enter host PID/IPC namespaces and execute commands as root on the runner host — independent of whether the operator has disabled privileged mode as a security control. That undermines a control many operators likely rely on. The advisory assesses this as critical severity for shared runners accepting untrusted workflow submissions (e.g., open-source projects accepting external PRs), and high severity for single-tenant runners where privileged mode was explicitly disabled. Consequences described include exposure of runner host secrets and deployment credentials, and lateral movement to other jobs sharing the same runner.
What Defenders Should Watch For
- Inventory exposure: identify any self-hosted
act_runnerdeployments, especially Docker-backed runners accepting workflows from external contributors or untrusted branches. - Workflow content review: treat
container.optionsin workflow YAML as untrusted input; flag or block PRs/workflow changes introducing--pid=host,--ipc=host,--uts=host,--network=host,--cap-add,--security-opt seccomp=unconfined/apparmor=unconfined,--device,--volumes-from, or--runtime/--cgroup-parentoverrides. - Host-level monitoring: on runner hosts, watch for containers or processes using
nsenter-style host namespace access, or job containers whose launch arguments diverge from the runner's configured privileged-mode policy. - Mitigation posture: until a patched
act_runneris adopted, consider restricting who can submit or modify workflows on shared runners, and isolating runners used for untrusted contributions from secrets and internal network access.
Developing Intel
This is a same-day advisory and details may evolve as Gitea maintainers finalize a fix. Defenders running self-hosted act_runner infrastructure should review the original advisory directly: GHSA-x4q3-gcj3-m6cf.