Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with workflow-run rights
-
DeliveryCraft workflow with privileged:false plus container.options host flags
-
ExploitRunner merges --pid=host/--cap-add/--security-opt into HostConfig
-
ExecutionJob container starts with host namespaces and broad capabilities
-
PersistEscape container to host as root
-
ImpactFull host compromise
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Least privilege enforcement
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires (1) a Gitea act_runner configured with the Docker backend, (2) the ability to run a workflow on that runner - i.e., an authenticated user with workflow-execution/push rights (PR:L), and (3) that the workflow's container.options field is honored by the runner. The decisive condition is that act_runner merges attacker-controlled container.options (e.g. --pid=host, --cap-add, --security-opt) into the Docker HostConfig while only forcing Privileged off; privileged: false being set does NOT prevent the attack. Limiting factors that reduce real-world risk: the attacker must already be authorized to submit workflows, the runner must use the Docker (not host/LXC) backend, and instances that block or sanitize container.options or restrict runners to trusted workflows are not exploitable. |
| Impact | Signals are largely consistent and point to a genuine high priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with vulnerable- and subsequent-system impacts all High and a 9.4 score reflects a remotely reachable, low-complexity escape that crosses a trust boundary (container to host). PR:L correctly captures that the attacker must be able to submit/run a workflow, so this is not unauthenticated - exposure depends on who can push workflows to a Docker-backed runner. A public POC exists, increasing real-world likelihood, but the issue is NOT in CISA KEV and no EPSS score was provided, so widespread active exploitation is not confirmed; treat the POC as proof of practicality rather than evidence of mass exploitation. The main caveat: real risk is gated by trust model - instances that only run trusted internal workflows face limited exposure, while runners exposed to untrusted contributors (public forks, multi-tenant CI) are at severe risk. |
| Exploit ScenarioDerived | A developer with permission to run CI on a Docker-backed Gitea act_runner authors a workflow that sets privileged: false but adds container.options like '--pid=host --cap-add=SYS_ADMIN --security-opt apparmor=unconfined'. The runner clears only the Privileged flag and applies the rest, giving the job container host namespace access and elevated capabilities, from which the attacker escapes to the host and gains root. A public POC for exactly this technique is available. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 28, 2026
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-execution rights break out to the host as root even when privileged mode is disabled. The runner passes a workflow's container.options string straight into the Docker job container's HostConfig and only forces the Privileged flag off, leaving dangerous options like --pid=host, --cap-add, and --security-opt intact. Publicly available exploit code exists (reported by VulnCheck), though it is not listed in CISA KEV.
RemediationAI
No vendor-released patched version of act_runner is identified in the provided data, so the exact fix version is not independently confirmed - consult the VulnCheck advisory (https://www.vulncheck.com/advisories/gitea-act-runner-container-hardening-bypass-via-workflow-container-options) for the latest fixed release and upgrade once available. As compensating controls: restrict workflow execution to trusted users only and never expose Docker-backed runners to untrusted or public-fork workflows (trade-off: limits open contribution/CI for external PRs); disable or strip the container.options capability so workflow authors cannot inject HostConfig flags (trade-off: breaks legitimate workflows that rely on custom options); enforce a Docker allow-list/deny-list or a runtime security policy that blocks --pid=host, --cap-add, and --security-opt regardless of workflow input; and where feasible run runners with rootless Docker or in disposable, isolated VMs so a successful escape lands in a throwaway host (trade-off: added operational overhead).
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Gitea act_runner is the CI/CD execution agent for Gitea (the act fork that interprets GitHub-Actions-style workflows). When using the Docker backend, each job runs in a container whose HostConfig is derived in part from the workflow author's container.options field. The flaw is a CWE-269 (Improper Privilege Management) hardening bypass: the runner's privileged: false setting is meant to be a security boundary, but the implementation only clears HostConfig.Privileged and merges the remaining attacker-supplied flags unchanged. Options such as --pid=host (shares the host PID namespace), --cap-add (grants Linux capabilities like CAP_SYS_ADMIN), and --security-opt (e.g. disabling seccomp/AppArmor) survive, so the container retains capabilities far beyond what disabling privileged mode implies - recreating the very isolation gaps privileged mode was supposed to remove.
Know when Gitea gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Attacker needs only authenticated workflow-run rights (PR:L) over the network with no user interaction; container-to-host escape changes scope (S:C) with full host C/I/A impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
Gitea act_runner with the Docker backend (through act 0.262.0) passes a workflow's container.options string to the Docker job container's HostConfig and, when configured with privileged: false, forces only the Privileged flag off while merging options such as --pid=host, --cap-add, and --security-opt unchanged. A user who can run a workflow on a Docker-backed runner can create a job container with host namespaces and broad capabilities and escape to the host as root despite privileged mode being disabled.
Articles & Coverage 1
Executive ViewAI
Gitea act_runner (Docker backend, versions through 0.262.0) contains a critical container escape vulnerability (CVE-2026-58053, CVSS 9.4) for which publicly available exploit code exists. Authenticated users with workflow-execution rights can break out of containers and execute commands as root on the CI/CD host, bypassing privilege restrictions entirely. This directly enables compromise of the software supply chain, unauthorized code execution in production systems, and lateral movement to any infrastructure accessible from the CI/CD environment.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) Enforce least-privilege RBAC and disable workflow-execution capability for all non-essential users; (2) Disable Docker backend entirely and require alternative runner backends, or take runners offline; (3) Isolate CI/CD runners on a dedicated network segment with egress controls to prevent lateral movement; (4) Deploy container runtime security with strict capability dropping and syscall filtering; (5) Enable comprehensive audit logging at container runtime and kernel level; (6) Require multi-factor approval and signed commits for all workflow definitions.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allVendor StatusVendor
Debian
| Release | Status | Fixed Version | Urgency |
|---|---|---|---|
| (unstable) | fixed | (unfixed) | - |
EUVD-2026-39973
GHSA-8qf9-pc52-j7cm
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB