CVE-2022-29162 is a vulnerability in the opencontainers project’s runc tool, a widely used CLI utility for spawning and running Linux containers according to the Open Container Initiative (OCI) specification. The vulnerability affects versions of runc prior to 1.1.2 and relates to incorrect default permissions involving Linux process capabilities. Specifically, when using the `runc exec --cap` command, processes were created with non-empty inheritable Linux process capabilities. This is atypical because inheritable capabilities allow a process to elevate its capabilities during an execve(2) system call if the executed program has inheritable file capabilities. Although the container security sandbox was not directly compromised—since the inheritable set never exceeded the container's bounding set—this behavior created an unusual Linux environment that could potentially be leveraged for privilege escalation within the container context. The vulnerability stems from CWE-276 (Incorrect Default Permissions), where the default capability sets were improperly configured, allowing unintended capability inheritance. The issue was addressed in runc version 1.1.2 by modifying the behavior of `runc exec --cap` to exclude inheritable capabilities from the additional capabilities granted to the executed process. Additionally, the `runc spec` command was updated to ensure that the example OCI spec (`config.json`) no longer sets any inheritable capabilities by default. No known exploits have been reported in the wild, and the vulnerability primarily affects container environments running vulnerable runc versions on Linux hosts.

For European organizations, the impact of this vulnerability is primarily related to containerized environments that utilize runc versions prior to 1.1.2. Since runc is a foundational container runtime component used by popular container platforms such as Docker and Kubernetes, organizations relying on container orchestration and deployment could be exposed. The vulnerability could allow processes within containers to gain elevated capabilities unexpectedly, potentially enabling privilege escalation or unauthorized access to resources within the container boundary. While the container sandbox itself remains intact, this flaw could facilitate lateral movement or privilege escalation attacks inside containers, which may lead to data exposure or disruption of containerized applications. Industries with heavy container adoption—such as finance, telecommunications, manufacturing, and cloud service providers—may face increased risk. Additionally, organizations with multi-tenant container environments or those running sensitive workloads in containers should be particularly cautious, as attackers exploiting this flaw could compromise container integrity or confidentiality. However, the absence of known exploits and the medium severity rating suggest that the immediate risk is moderate, but it warrants timely remediation to prevent potential exploitation.

To mitigate this vulnerability effectively, European organizations should: 1) Audit container environments to identify runc versions in use, focusing on versions prior to 1.1.2. 2) Upgrade runc to version 1.1.2 or later to apply the fix that removes inheritable capabilities from processes spawned with `runc exec --cap`. 3) Review and harden container runtime configurations, especially any custom OCI specs (`config.json` files), to ensure no inheritable capabilities are set inadvertently. 4) Implement strict container security policies that limit the use of `--cap` flags and avoid granting unnecessary capabilities to container processes. 5) Monitor container runtime logs and system audit logs for unusual capability changes or execve calls that could indicate attempts to exploit this vulnerability. 6) Employ runtime security tools that can detect anomalous capability escalations or suspicious process behavior within containers. 7) Educate DevOps and security teams about the implications of Linux capabilities and the importance of minimal privilege principles in container environments. These steps go beyond generic patching advice by emphasizing configuration review, monitoring, and operational security best practices tailored to container ecosystems.