GPU VulnDB

Database/Control plane, storage & DevOps

Gitea act_runner: workflow container options bypass privileged:false and escape to the host

CVSS 9.4CVE-2026-58053Control plane, storage & DevOpscurated

Impact

act_runner passes a workflow's container.options straight into the job container's HostConfig and, with privileged: false, clears only the Privileged flag while still honouring options like --pid=host, --cap-add and --security-opt. A workflow author therefore gets host namespaces and broad capabilities on the runner and escapes to root on the host, even though the operator believes privileged mode is disabled. On a build or GPU-CI node this hands over the Docker socket, every other tenant's job on that runner, and the runner's registration token - and a self-hosted runner typically sits inside the cluster network with registry and artifact credentials.

Who can reach it

Any user who can get a workflow to run on a Docker-backed act_runner - a repository contributor or anyone able to open a build-triggering pull request on a repo that runner serves. Low privilege, no host access needed.

What to do

Update act_runner past the affected act 0.262.0 line once a fixed release is available; the record does not name a fixed version, so the actionable step today is configuration: restrict which repositories can use Docker-backed runners, and do not treat privileged: false as a hardening boundary. Replace rather than clean any runner host you believe ran untrusted workflows. Runner service restart, not a cluster-wide maintenance window.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.