CVE-2022-36109 is a medium-severity vulnerability affecting Moby, the open-source containerization project underlying Docker Engine. The vulnerability arises from improper setup of supplementary groups within containers when using the Dockerfile instruction `USER $USERNAME`. Specifically, supplementary groups are not correctly assigned, which can allow an attacker who already has direct access to a container to manipulate their supplementary group memberships. This manipulation can bypass primary group restrictions, potentially granting unauthorized access to sensitive information or the ability to execute code within the container environment. The root cause is an incorrect authorization mechanism (CWE-863) related to group permission handling inside containers. The issue affects all Moby versions prior to 20.10.18. The vendor fixed the vulnerability in version 20.10.18, and remediation requires stopping and restarting running containers to apply the corrected permissions. For users unable to upgrade immediately, a workaround involves avoiding the `USER $USERNAME` Dockerfile instruction and instead using `ENTRYPOINT ["su", "-", "user"]` to ensure supplementary groups are properly set up. No known exploits have been reported in the wild, but the vulnerability poses a risk in environments where attackers can gain container access. This vulnerability does not allow initial container compromise but escalates privileges within the container by circumventing group-based access controls, potentially leading to unauthorized data access or code execution inside the container context.

For European organizations, this vulnerability could have significant implications, especially for those heavily reliant on containerized applications and microservices architectures using Docker or Moby. Attackers who gain access to a container—through other vulnerabilities, misconfigurations, or insider threats—could exploit this flaw to escalate privileges within the container, bypassing group restrictions. This could lead to unauthorized access to sensitive data stored or processed within containers, or execution of malicious code that could affect containerized workloads. While the vulnerability does not directly allow container escape or host compromise, it increases the risk profile of container environments by weakening internal access controls. Organizations in sectors such as finance, healthcare, critical infrastructure, and technology, which often deploy containerized applications, could face data breaches, service disruptions, or compliance violations if this vulnerability is exploited. Additionally, the need to restart containers to apply fixes may impact operational continuity if not managed properly. Given the widespread use of Docker and Moby in European enterprises, failure to address this vulnerability could undermine container security and trust in software supply chains.

1. Upgrade all Moby/Docker Engine installations to version 20.10.18 or later as soon as possible to apply the official fix. 2. Stop and restart all running containers after the upgrade to ensure corrected group permissions are applied. 3. For environments where immediate upgrade is not feasible, modify Dockerfiles to avoid the `USER $USERNAME` instruction. Instead, use `ENTRYPOINT ["su", "-", "user"]` to properly initialize supplementary groups within containers. 4. Implement strict container access controls and monitoring to prevent unauthorized container access, as exploitation requires direct container access. 5. Employ runtime security tools that monitor container processes and permissions to detect anomalous privilege escalations. 6. Regularly audit container configurations and user/group permissions to ensure adherence to least privilege principles. 7. Integrate vulnerability scanning in CI/CD pipelines to detect use of vulnerable Moby/Docker versions and insecure Dockerfile instructions. 8. Educate developers and DevOps teams on secure container image building practices, emphasizing correct user and group handling. These measures, combined, will reduce the risk of exploitation and strengthen container security posture beyond generic patching advice.