https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 08:15:07 +0000 https://db.gcve.eu/vuln/ghsa-pwhc-rpq9-4c8w <p><strong>Affected:</strong> Go: github.com/containerd/containerd, Go: github.com/containerd/containerd/v2</p> <p>### Impact</p> <p>An overly broad default permission vulnerability was found in containerd.</p> <p>- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700 - Allowed local users on the host to potentially access the metadata store and the content store - `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700 - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host. - `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700</p> <p>The directory paths may differ depending on the daemon configuration. When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.</p> <p>### Patches</p> <p>This bug has been fixed in the following containerd versions:</p> <p>* 2.2.0 * 2.1.5 * 2.0.7 * 1.7.29</p> <p>Users should update to these versions to resolve the issue. These updates automatically change the permissions of the existing directories.</p> <p>&gt; [!NOTE] &gt; &gt; `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711. &gt; This is an expected behavior for supporting userns-remapped containers.</p> <p>### Workarounds</p> <p>The system administrator on the host can manually chmod th…</p> <p><strong>Affected:</strong> Go: github.com/containerd/containerd, Go: github.com/containerd/containerd/v2</p> <p>### Impact</p> <p>An overly broad default permission vulnerability was found in containerd.</p> <p>- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700 - Allowed local users on the host to potentially access the metadata store and the content store - `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700 - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host. - `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700</p> <p>The directory paths may differ depending on the daemon configuration. When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.</p> <p>### Patches</p> <p>This bug has been fixed in the following containerd versions:</p> <p>* 2.2.0 * 2.1.5 * 2.0.7 * 1.7.29</p> <p>Users should update to these versions to resolve the issue. These updates automatically change the permissions of the existing directories.</p> <p>&gt; [!NOTE] &gt; &gt; `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711. &gt; This is an expected behavior for supporting userns-remapped containers.</p> <p>### Workarounds</p> <p>The system administrator on the host can manually chmod th…</p> https://db.gcve.eu/vuln/ghsa-pwhc-rpq9-4c8w