2 techniques observed across 1 entry — derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.1 · compare on the matrix · Navigator layer (JSON)
Privilege Escalation TA0004
T1068Exploitation for Privilege Escalation×1
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions.
Adversaries may break out of a container or virtualized environment to gain access to the underlying host. This can allow an adversary access to other containerized or virtualized resources from the host level or to the host itself. In principle, containerized / virtualized resources should provide a clear separation of application functionality and be isolated from the host environment.
Gitea act_runner through 0.262.0 passes a workflow-defined container.options string straight into Docker's HostConfig, forcing only Privileged=false while merging --pid=host, --cap-add and --security-opt unchanged — a malicious workflow escapes the job container to the host (VulnCheck). Public PoC, CVSS 9.4, mitigation-only this week. Self-hosted Gitea CI is common in DACH developer shops and universities; restrict who can define workflow container options. The companion Gitea-core auth bypass via X-WEBAUTH-USER (CVE-2026-20896, fixed in 1.26.3/1.26.4) remains worth patching on the same estate.
Gitea act_runner through 0.262.0 with the Docker backend passes the workflow-defined container.options string straight into Docker's HostConfig for the job container. When an operator hardens the runner with privileged: false, the code forces only the Privileged flag off but still merges the rest of container.options unchanged — so options such as --pid=host, --cap-add=SYS_PTRACE, --security-opt=seccomp:unconfined or arbitrary bind mounts pass through, allowing any user with write access to a repository whose workflows run on that runner to escape to the host as root despite the hardening (VulnCheck, 2026-06-27; ENISA EUVD EUVD-2026-58053, 2026-06-28). ENISA EUVD scores it CVSS 4.0 9.4 and a public PoC is referenced. Technique class: T1611 Escape to Host via Docker HostConfig injection → T1068. Prerequisite is write access (or accepted external contribution) to a repo whose workflows execute on a Docker-backed runner configured privileged: false — the common hardened setting, which is what makes this dangerous. Self-service CI on internal Gitea + Docker is common in Swiss/EU public-sector and academic IT. Detection: watch Docker daemon audit logs for containers launched with unusual HostConfig flags (pid_mode=host, non-baseline cap_add, custom seccomp); review CI workflow-YAML diffs from external contributors for container.options injection. Mitigation now (vendor fix act_runner >= 0.263.0 was pending at advisory time): strip or allowlist container.options at the runner policy layer, require approval for fork/external-contributor workflow runs, and use a kernel-isolation runtime (e.g. gVisor) for untrusted CI.
passes workflow container.options string to Docker job container HostConfig; forces only Privileged=false but merges options like --pid=host, --cap-add, --security-opt unchanged