GPU VulnDB

Database/Control plane, storage & DevOps

Gitea Runner: workflow-controlled container options bypass forced non-privileged mode and give root on the runner host

CVSS 8.8CVE-2026-73802Control plane, storage & DevOpscurated

Impact

The runner passes container options taken from the workflow definition into the Docker job container config. Even with privileged mode forced off, host namespace settings, added capabilities and security-profile overrides still take effect, so a workflow author can break out of the job container and run commands as root on the runner host. On a GPU fleet this matters where CI runners sit on or beside accelerator nodes: host root gives the attacker the runner's registry and deploy credentials, any other tenants' jobs on the same host, and the GPU device nodes the host exposes. Jobs are self-service, so the attacker only needs the ability to push a workflow to a repository that targets an affected Docker-backed runner.

Who can reach it

Any authenticated user who can cause a workflow to run on an affected Docker-backed Gitea runner - typically anyone able to push a branch or open a pull request in a repository that uses that runner. No access to the runner host itself is needed.

What to do

Upgrade Gitea Runner to 3.0.0, which is where the fix shipped. That means stopping the runner daemon and restarting it on the new version; queued jobs drain or restart, but the host does not need a reboot. Until upgraded, restrict which repositories may target Docker-backed runners and treat any workflow-author as holding host root on those runner machines.

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.