Ce mail provient de l'extérieur, restons vigilants

=====================================================================

                            CERT-Renater

                Note d'Information No. 2026/VULN532
_____________________________________________________________________

DATE                : 21/05/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Docker Engine versions prior to 
                                        29.5.1,
                     docker/daemon (Go) versions up to and including
                                        28.5.2,
               moby/v2/daemon (Go) versions prior to v2.0.0-beta.14.

=====================================================================
https://github.com/moby/moby/security/advisories/GHSA-rg2x-37c3-w2rh
https://github.com/moby/moby/security/advisories/GHSA-x86f-5xw2-fm2r
https://github.com/moby/moby/security/advisories/GHSA-vp62-88p7-qqf5
_____________________________________________________________________

Race condition in docker cp allows bind mount redirection to host path
High
vvoland published GHSA-rg2x-37c3-w2rh May 18, 2026

Package
Docker Engine

Affected versions
< 29.5.1

Patched versions
29.5.1

github.com/docker/docker/daemon (Go)
Affected versions
<= v28.5.2
None
github.com/moby/moby/v2/daemon (Go)
Patched versions
< v2.0.0-beta.14
v2.0.0-beta.14


Description

Summary

A race condition during docker cp mount setup allows a malicious
container to redirect a bind mount target to an arbitrary host
path, potentially overwriting host files or causing denial of
service.

Details

When copying files into a container, the daemon sets up a temporary
filesystem view by bind-mounting volumes into a private mount
namespace. During this setup, the mount destination is created
inside the container root and then a bind mount is attached using
the container-relative path resolved to an absolute host path.

Between mountpoint creation and the mount() syscall, a process
running inside the container can replace the destination (or a
parent path component) with a symlink pointing to an arbitrary
location on the host. The mount() syscall follows the symlink,
causing the volume to be bind-mounted onto an arbitrary host
path instead of the intended container path.


Impact

A malicious container can redirect a volume bind mount to an
arbitrary host path. The impact depends on the volume content
and mount options:

    If the volume is writable, arbitrary host files at the
redirected path could be overwritten with the volume's
contents.
    If the volume is read-only, the host path is masked by
the mount for the duration of the operation, causing denial
of service.
    In all cases the mount is temporary (torn down after the
docker cp completes), but the effects of any writes persist.

Conditions for exploitation

    A container must have at least one volume mount.
    A process inside the container must be able to rapidly
create and swap symlinks at the volume mount destination path.
    An operator must initiate a docker cp into that container,
or call the PUT /containers/{id}/archive or
HEAD /containers/{id}/archive API endpoints.


Not affected

    Containers that do not have volume mounts are not affected,
as the race occurs during volume bind-mount setup.

Workarounds

    Only run containers from trusted images.
    Avoid using docker cp with untrusted running containers.
    Use authorization plugins to restrict access to the
archive API endpoints (PUT /containers/{id}/archive,
HEAD /containers/{id}/archive).

Severity
High
7.2/ 10

CVSS v3 base metrics
Attack vector
Local
Attack complexity
High
Privileges required
Low
User interaction
Required
Scope
Changed
Confidentiality
None
Integrity
High
Availability
High
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H

CVE ID
CVE-2026-42306

Weaknesses
Weakness CWE-61
Weakness CWE-367

Credits

    @vvoland vvoland Remediation developer

_____________________________________________________________________


`PUT /containers/{id}/archive` executes container binary on the host
High
vvoland published GHSA-x86f-5xw2-fm2r May 18, 2026

Package
Docker Engine

Affected versions
< 29.5.1
Patched versions
29.5.1

github.com/docker/docker/daemon (Go)
Affected versions
<= v28.5.2
Patched versions
none
github.com/moby/moby/v2/daemon (Go)
Affected versions
< v2.0.0-beta.14
Patched versions
v2.0.0-beta.14


Description

Summary

When a user uploads a compressed archive into a container, a malicious
image can execute arbitrary code with daemon (host root) privileges.

Details

When handling PUT /containers/{id}/archive requests with compressed
archives, the daemon decompresses them using external system binaries.
Due to incorrect ordering of operations, these binaries are resolved
from the container's filesystem rather than the host's. A container
image that includes a trojanized decompression binary can achieve
code execution as the daemon process whenever a compressed archive
is uploaded to that container.

The executed binary runs with the daemon's full privileges,
including host root UID and unrestricted capabilities.


Impact

Arbitrary code execution as host root, crossing the container-to-host
trust boundary.
Conditions for exploitation

    A user must run a container from a malicious image that
contains a trojanized decompression binary.
    The user must then upload a compressed archive (xz or gzip)
into that container, either by piping a compressed archive via
docker cp - or by calling the PUT /containers/{id}/archive API
directly with compressed content.

Not affected

Standard docker cp usage is not affected, because the CLI sends
uncompressed tar by default:

docker cp ./file.txt mycontainer:/file.txt

This can only be exploited when explicitly passing a xz or
gzip-compressed archive to docker cp or the PUT
/containers/{id}/archive API, for example:

cat archive.tar.xz | docker cp - mycontainer:/dir

Decompression formats using pure Go implementations (bzip2,
zstd, and gzip when the container image does not contain an
unpigz binary) are also not affected.


Workarounds

    Only run containers from trusted images.
    Use authorization plugins to limit access to the
PUT /containers/{id}/archive endpoint.
    Avoid piping compressed archives into containers
created from untrusted images.

Severity
High
7.2/ 10

CVSS v3 base metrics
Attack vector
Local
Attack complexity
High
Privileges required
Low
User interaction
Required
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N

CVE ID
CVE-2026-41567

Weaknesses
No CWEs

Credits

    @manizada manizada Reporter
    @vvoland vvoland Remediation developer

_____________________________________________________________________


Race condition in docker cp allows creation of arbitrary empty files
on the host via symlink swap

Moderate
vvoland published GHSA-vp62-88p7-qqf5 May 18, 2026

Package
Docker Engine

Affected versions
< 29.5.1
Patched versions
29.5.1

github.com/docker/docker/daemon (Go)
Affected versions
<= v28.5.2
Patched versions
None

github.com/moby/moby/v2/daemon (Go)
Affected versions
< v2.0.0-beta.14
Patched versions
v2.0.0-beta.14

Description

Summary

A race condition during docker cp mount setup allows a malicious container
to create empty files or directories at arbitrary absolute paths on
the host filesystem.

This advisory covers the race during mountpoint creation. The related
race during the subsequent mount syscall is tracked in
GHSA-rg2x-37c3-w2rh


Details

When copying files into a container, the daemon sets up a temporary
filesystem view by bind-mounting volumes into a private mount namespace.
During this setup, the mount destination path is first resolved within
the container's root filesystem using GetResourcePath, and then used to
create the mountpoint (file or directory) if it does not already exist
via createIfNotExists.

Between path resolution and mountpoint creation, a process running
inside the container can swap a path component for a symlink pointing
to an arbitrary location on the host. Because createIfNotExists operates
on the already-resolved absolute path using standard os.MkdirAll and
os.OpenFile — which follow symlinks in intermediate path components —
the symlink is followed and the file or directory is created outside
the container root filesystem, as root.


Impact

A malicious container can create empty files or directories at
arbitrary absolute paths on the host filesystem, running as root.
This enables persistent denial of service — for example:

    Converting /etc/docker/daemon.json into a directory prevents
the daemon from restarting
    Creating /etc/nologin prevents user logins
    Overwriting critical system paths with empty files can break
host services

The container does not gain read or write access to existing host
files — only the ability to create new empty files or directories
at chosen paths.


Conditions for exploitation

    A container must be running with a process that can rapidly
create and swap symlinks at a volume mount destination path.
    An operator must initiate a docker cp into that container,
or call the PUT /containers/{id}/archive or
HEAD /containers/{id}/archive API endpoints.

Not affected

    Containers that do not have volume mounts are not affected,
as the race occurs during volume bind-mount setup.

Patches

Mountpoint creation is now scoped to the container root using
os.Root (Go 1.24+), which refuses to follow symlinks that escape
the opened root directory. All filesystem operations in
createIfNotExists (MkdirAll, OpenFile) are performed through
the os.Root handle, so even if a symlink swap occurs after path
resolution, the creation stays confined to the container root.


Workarounds

    Only run containers from trusted images.
    Avoid using docker cp with untrusted running containers.
    Use authorization plugins to restrict access to the archive
API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive).

Severity
Moderate
6.1/ 10

CVSS v3 base metrics
Attack vector
Local
Attack complexity
High
Privileges required
Low
User interaction
Required
Scope
Changed
Confidentiality
None
Integrity
Low
Availability
High
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:H

CVE ID
CVE-2026-41568

Weaknesses
Weakness CWE-61
Weakness CWE-367

Credits

    @manizada manizada Reporter
    @vvoland vvoland Remediation developer

=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================




