Gitea runner CVE-2026-73802: verify the full CI isolation policy

GitHub Advisory Database updated its CVE-2026-73802 entry on 2 October. It concerns the Gitea runner executing jobs through Docker. The advisory describes a case where disabling privileged mode does not remove other dangerous settings supplied by a workflow author. The project published its advisory on 15 August; the October database entry is not the first disclosure date.

According to Gitea’s advisory, workflow container options can preserve host namespace access, expanded capabilities and security profile overrides. In the described configuration, the author of an executed workflow can run commands as root on the host. The issue crosses the boundary between job configuration and CI infrastructure permissions.

Who should assess exposure

Prioritise shared runners processing code or workflows from people with a lower level of trust. Establish who can change a job definition and cause it to execute: a team member, collaborator or external contributor. A private repository alone does not answer that question.

We do not extend the description to every Gitea server installation or every CI product. What matters is the runner, its container execution path and whether workflow-controlled options can reach it. Assess the actual configuration rather than relying solely on a declaration of privileged: false.

Why one flag is insufficient

Docker Engine’s security documentation describes container security through namespaces, capabilities, configuration and host protections. Checking one flag does not establish how the other mechanisms behave.

Breachroad’s conclusion is that a workflow definition should be treated as a request to execute code. Permission to edit a job should not allow its author to independently expand access to the host, network or other projects’ secrets through an extra parameter. Runner policy should constrain the resulting configuration, including after settings from different sources are combined.

Reading remediation status

For the Go module gitea.com/gitea/runner, GitHub’s database identifies versions before 1.0.9-0.20260731160927-34bfa1915022 as affected and that version as patched. The project’s advisory uses a different numbering scheme: its affected field contains < 3.0.0, while patched contains > 3.0.0. This metadata discrepancy needs consideration when selecting a deployment artifact.

We recommend confirming which release or image in the deployed distribution contains the relevant change. We do not treat a “3.0.0” label alone as proof of remediation. The CI owner should record the version, artifact provenance and evidence that disallowed settings are rejected. Until that is established, restrict untrusted workflows on shared infrastructure.

Training example: tests and deployments on one host

In our fictional example, an organisation sends pull-request tests and production deployments to one host. The platform operator sees privileged mode disabled and assumes jobs cannot affect one another. The team should ask which data and networks would be reachable if the container boundary were crossed.

Our proposed approach separates these trust levels: distinct execution environments, approved container options, restricted connectivity and credentials available only for the relevant stage. A separate working directory alone does not create that boundary. An ephemeral runner also needs assessment of data, images and caches carried into subsequent jobs.

What to review now

1. Identify runners, their owners, versions and the repositories using each host.
2. Establish who can execute a modified workflow and which options actually reach the container.
3. Separate jobs with different trust levels and remove unnecessary access to secrets and deployment infrastructure.
4. In a controlled environment, confirm policy enforcement after updating. Retain the outcome and the artifact configuration used.

If the assessment identifies unauthorised execution on the host, initiate incident response and evaluate reachable credentials and other jobs. An absence of visible repository changes does not establish that the host was secure.

Training for IT and DevSecOps teams helps rehearse workflow trust assessment and escalation. Our CI/CD security guide explains the foundations.

Sources and Breachroad recommendations

The mechanism and version metadata come from the linked Gitea and GitHub advisories. Docker’s documentation explains isolation mechanisms. The example, assessment order and proposed infrastructure separation are our recommendations. We do not claim that the advisory establishes an active attack against a particular organisation. Sources were checked on 4 October 2026.