← Blog · · df00tech

Critical Flaw in Gitea act_runner Lets Workflow YAML Bypass Privileged-Mode Protections for Host Takeover

breaking ghsa go CVE-2026-73802

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_runner deployments, especially Docker-backed runners accepting workflows from external contributors or untrusted branches.
  • Workflow content review: treat container.options in 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-parent overrides.
  • 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_runner is 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.

Get new detections in your inbox

New ATT&CK coverage plus CISA KEV / CVE detection rules, roughly weekly. No spam, unsubscribe anytime.