CVE-2026-73802: Critical severity go/gitea.com/gitea/runner vulnerability
Summary actrunner appends workflow-controlled jobs.<job>.container.options directly to the Docker HostConfig for the job container. When runner privileged mode is disabled, only Privileged is forced false. Host namespace flags, capability expansion, and security profile overrides from workflow YAML are preserved in the final HostConfig. A workflow author can enter host PID/IPC namespaces and execute commands on the runner host as root.
Details Source-to-sink path in actrunner:
- ContainerSpec.Options accepts workflow YAML container.options - RunContext.options() appends workflow options to runner-level container options - Job container is created with Privileged: rc.Config.Privileged but also with Options: rc.options(ctx) - mergeContainerConfigs() parses Docker CLI-style options into HostConfig - When privileged mode is disabled, only copts.privileged is forced false - sanitizeConfig() only filters Binds and Mounts - Preserved dangerous HostConfig fields:
text Privileged=false PidMode=host IpcMode=host CapAdd=["ALL"] SecurityOpt=["seccomp=unconfined","apparmor=unconfined"]
Attacker workflow YAML: yaml jobs: breakout: runs-on: ubuntu-latest container: image: ubuntu:22.04 options: >- --pid=host --ipc=host --cap-add=ALL --security-opt seccomp=unconfined --security-opt apparmor=unconfined steps: - name: host namespace marker run: | nsenter -t 1 -m -u -i -n -p -- sh -c "id > /tmp/marker"
Impact An attacker who can submit a workflow to a repository using a shared Docker-backed actrunner can:
- Enter host PID, IPC, and mount namespaces - Execute arbitrary commands as root on the runner host - Access runner host secrets, deployment credentials, and environment variables - Pivot to adjacent jobs running on the same runner - Access internal build infrastructure reachable from the runner host
Critical severity for shared runners where untrusted users can trigger workflows. High severity for single-tenant runners with privileged mode explicitly disabled as a security control.
Fix Direction Treat container.options as untrusted input. Reject or strip when privileged mode is disabled:
- Host namespaces: --pid=host, --ipc=host, --uts=host, --network=host - Capability expansion: --cap-add ALL, --cap-add SYSADMIN - Security overrides: --security-opt seccomp=unconfined, --security-opt apparmor=unconfined - Device access: --device, --device-cgroup-rule - Volume inheritance: --volumes-from - Runtime controls: --runtime, --cgroup-parent
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/gitea.com/gitea/runnerto a version that resolves this vulnerability.Fixed in 1.0.9-0.20260731160927-34bfa1915022 - Configuration
Explicitly disable privileged mode for job containers by forcing HostConfig.Privileged to false.
Docker-backed act_runner Privileged = false - Configuration
Treat jobs.<job>.container.options as untrusted input and reject or strip host namespace flags such as --pid=host and --ipc=host, capability expansion such as --cap-add=ALL, and security overrides such as --security-opt seccomp=unconfined and --security-opt apparmor=unconfined before converting options into Docker HostConfig.
act_runner workflow container options container.options = reject or strip dangerous options
Event History
Frequently Asked Questions
Who is exposed to this issue?
Runner hosts are exposed when untrusted or insufficiently trusted users can author or modify workflow YAML that runs on the affected act_runner. The workflow author needs only low-privilege workflow authoring access; runner privileged mode being disabled does not prevent the breakout.
What does an attacker need to do to exploit it?
The attacker supplies Docker-style container options through jobs.<job>.container.options in a workflow. They can request host PID or IPC namespaces and preserve capability or security-profile overrides, then execute commands from the job container on the runner host as root.
Is a non-privileged runner configuration safe?
No. With privileged mode disabled, the runner forces only Privileged=false, while dangerous settings such as PidMode=host, IpcMode=host, CapAdd=ALL, and unconfined seccomp or AppArmor options can remain in the final Docker HostConfig.
What can be done if patching is not immediately possible?
Do not allow untrusted users to create or modify workflows executed by the runner. Restrict workflow use until container.options values that can request host namespaces, added capabilities, or security-profile overrides are prevented from reaching the runner.
How can I determine whether a runner may be affected?
Review workflows executed by the runner for jobs.<job>.container.options, especially options requesting host PID or IPC namespaces, CapAdd=ALL, seccomp=unconfined, or apparmor=unconfined. Also determine whether workflow-controlled options are passed into Docker HostConfig without filtering beyond Binds and Mounts.