Gitea act_runner CVE-2026-73802

Requires a Docker-backed Gitea act_runner (versions before the fix; the go module affected range is < 1.0.9-0.20260731160927-34bfa1915022, fixed in release v3.0.0) and an attacker able to submit or trigger a workflow against a repository served by that runner (authenticated per PR:L - a repo collaborator, or an untrusted fork/PR contributor on a shared runner). The exploit is honored against default configurations: crucially, the condition is NOT that privileged mode is enabled - the flaw specifically defeats the 'runner privileged mode disabled' control, because sanitizeConfig() filters only Binds and Mounts while leaving PidMode=host, IpcMode=host, CapAdd=ALL, and SecurityOpt seccomp/apparmor=unconfined intact in the HostConfig. Limiting factors: only the Docker/container backend is affected; the attacker must have workflow-execution rights; and impact severity scales with tenancy - Critical for shared/multi-tenant runners with untrusted submitters, lower for single-tenant trusted-maintainer runners.

All severity signals point to a genuine high-priority issue for the right deployment profile. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) describes a low-complexity, low-privilege, no-interaction attack that escapes the container boundary (S:C) to full root compromise of the runner host. The GHSA advisory publishes a complete, working attacker workflow YAML, so publicly available exploit code exists and the barrier to reproduction is effectively zero. However, this is NOT in CISA KEV, so there is no confirmed active exploitation, and no EPSS probability was provided in the input, so widespread opportunistic exploitation cannot be quantified from this data. No SSVC decision was supplied either. The PR:L requirement is important context: the attacker must be able to submit or trigger a workflow against a repository served by a shared Docker-backed act_runner, so real-world risk is concentrated in multi-tenant/shared-runner and public fork-PR setups where untrusted users can run workflows - exactly the scenario the advisory rates Critical. For single-tenant runners used only by trusted maintainers, real risk is materially lower (the advisory rates it High) because the privileged-mode-disabled control that operators rely on is silently bypassed. Net: a real priority wherever untrusted workflow submission is possible; a defense-in-depth bypass rather than a demonstrated internet-wide mass-exploitation event, given EPSS and KEV evidence are absent.

An attacker with workflow-submission access to a repository served by a shared Docker-backed Gitea act_runner pushes (or opens a fork PR containing) a workflow whose jobs.<job>.container.options includes --pid=host --ipc=host --cap-add=ALL and seccomp/apparmor=unconfined. Because privileged mode being disabled only forces Privileged=false, these flags survive into the job container's Docker HostConfig, letting a step run nsenter -t 1 to enter host namespaces and execute arbitrary commands as root on the runner host. A working proof-of-concept workflow is published directly in the GHSA advisory, so no exploit development is required.