Summary
Gitea Runner may pass workflow-controlled container options to Docker even when privileged mode is disabled. A workflow author who can run jobs on an affected Docker-backed runner may use namespace, capability, or security-profile settings to weaken isolation and execute commands as root on the runner host.
Gitea Runner may pass workflow-controlled container options to Docker even when privileged mode is disabled. A workflow author who can run jobs on an affected Docker-backed runner may use namespace, capability, or security-profile settings to weaken isolation and execute commands as root on the runner host.
Affected context
The issue occurs in Gitea Runner deployments that execute workflows through Docker-backed runners and allow workflow-controlled container options to influence job configuration. It becomes risky when host namespace settings, additional capabilities, or security-profile overrides remain effective despite the runner attempting to disable privileged mode.
The issue occurs in Gitea Runner deployments that execute workflows through Docker-backed runners and allow workflow-controlled container options to influence job configuration. It becomes risky when host namespace settings, additional capabilities, or security-profile overrides remain effective despite the runner attempting to disable privileged mode.
Exploit preconditions
- Attack surface: Workflow job execution on a Docker-backed Gitea Runner
- Required access: Permission to author or modify a workflow that runs on the affected runner
- Trigger point: Creation and startup of the workflow's Docker job container
- Why exploitation is possible: User-controlled container options can alter isolation, capability, namespace, or security-profile settings that are not fully constrained by the privileged-mode control
- Attack surface: Workflow job execution on a Docker-backed Gitea Runner
- Required access: Permission to author or modify a workflow that runs on the affected runner
- Trigger point: Creation and startup of the workflow's Docker job container
- Why exploitation is possible: User-controlled container options can alter isolation, capability, namespace, or security-profile settings that are not fully constrained by the privileged-mode control
Why this happens
The underlying bug is improper privilege management, mapped to CWE-269. The runner applies a high-level restriction intended to disable privileged containers but does not comprehensively constrain lower-level Docker options supplied by workflow data. As a result, security-sensitive settings may remain effective, allowing untrusted workflow input to weaken container isolation and expand the job's authority over the host.
The underlying bug is improper privilege management, mapped to CWE-269. The runner applies a high-level restriction intended to disable privileged containers but does not comprehensively constrain lower-level Docker options supplied by workflow data. As a result, security-sensitive settings may remain effective, allowing untrusted workflow input to weaken container isolation and expand the job's authority over the host.
Potential impact
- A workflow author may escape the job container
- The attacker could execute commands as root on the runner host
- Host files, credentials, and other workloads may be exposed
- The runner could be used for lateral movement or persistence
- CI/CD artifacts, source code, or secrets may be modified or exfiltrated
- A workflow author may escape the job container
- The attacker could execute commands as root on the runner host
- Host files, credentials, and other workloads may be exposed
- The runner could be used for lateral movement or persistence
- CI/CD artifacts, source code, or secrets may be modified or exfiltrated
General mitigation guidance
Mitigation generally focuses on treating workflow-controlled container options as untrusted and enforcing isolation at the lowest relevant layer.
Common defensive patterns include:
- Use an allowlist of permitted container settings rather than forwarding arbitrary options
- Reject host namespace sharing, added capabilities, device mappings, security-profile overrides, and equivalent escape-sensitive controls
- Apply secure-by-default Docker and runtime configurations independently of workflow input
- Run jobs with the least host, filesystem, network, and process privileges necessary
- Separate untrusted workflows onto disposable, isolated runners
- Avoid exposing sensitive host mounts, credentials, or control sockets to job containers
- Enforce runtime policies that prevent privileged operations even when job configuration is manipulated
Mitigation generally focuses on treating workflow-controlled container options as untrusted and enforcing isolation at the lowest relevant layer.
Common defensive patterns include:
- Use an allowlist of permitted container settings rather than forwarding arbitrary options
- Reject host namespace sharing, added capabilities, device mappings, security-profile overrides, and equivalent escape-sensitive controls
- Apply secure-by-default Docker and runtime configurations independently of workflow input
- Run jobs with the least host, filesystem, network, and process privileges necessary
- Separate untrusted workflows onto disposable, isolated runners
- Avoid exposing sensitive host mounts, credentials, or control sockets to job containers
- Enforce runtime policies that prevent privileged operations even when job configuration is manipulated
How teams detect issues like this
Detection can combine source review, configuration analysis, and runtime monitoring:
- Use static analysis to identify direct propagation of workflow fields into Docker host configuration
- Review code for missing allowlists around namespace, capability, device, mount, and security-profile options
- Search runner policies and container definitions for host namespace sharing, broad capabilities, writable host paths, or exposed container sockets
- Monitor job creation events for security-sensitive Docker options and unexpected changes in container isolation
- Enforce admission or runtime policies that reject disallowed container settings
- Add CI checks and automated security review tools that flag workflow-to-runtime privilege boundaries
Detection can combine source review, configuration analysis, and runtime monitoring:
- Use static analysis to identify direct propagation of workflow fields into Docker host configuration
- Review code for missing allowlists around namespace, capability, device, mount, and security-profile options
- Search runner policies and container definitions for host namespace sharing, broad capabilities, writable host paths, or exposed container sockets
- Monitor job creation events for security-sensitive Docker options and unexpected changes in container isolation
- Enforce admission or runtime policies that reject disallowed container settings
- Add CI checks and automated security review tools that flag workflow-to-runtime privilege boundaries
Sources
| Source | Link |
|---|---|
| blog. | blog.gitea.com/ |
| gitea. | gitea.com/ |
| github. | github.com/ |
