Summary
act_runner 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 act_runner:
ContainerSpec.Options accepts workflow YAML container.optionsRunContext.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:
Privileged=false
PidMode=host
IpcMode=host
CapAdd=["ALL"]
SecurityOpt=["seccomp=unconfined","apparmor=unconfined"]
Attacker workflow 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 act_runner 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 SYS_ADMIN
- 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
References
sn0x-sharma Reporter
Summary
act_runner appends workflow-controlled
jobs.<job>.container.optionsdirectlyto the Docker HostConfig for the job container. When runner privileged mode is
disabled, only
Privilegedis forced false. Host namespace flags, capabilityexpansion, 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 act_runner:
ContainerSpec.Optionsaccepts workflow YAMLcontainer.optionsRunContext.options()appends workflow options to runner-level container optionsPrivileged: rc.Config.Privilegedbut alsowith
Options: rc.options(ctx)mergeContainerConfigs()parses Docker CLI-style options into HostConfigcopts.privilegedis forced falsesanitizeConfig()only filtersBindsandMountsAttacker workflow YAML:
Impact
An attacker who can submit a workflow to a repository using a shared
Docker-backed act_runner can:
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.optionsas untrusted input. Reject or strip whenprivileged mode is disabled:
--pid=host,--ipc=host,--uts=host,--network=host--cap-add ALL,--cap-add SYS_ADMIN--security-opt seccomp=unconfined,--security-opt apparmor=unconfined--device,--device-cgroup-rule--volumes-from--runtime,--cgroup-parentReferences