| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| github.com/portainer/portainer | ≥ 2.33.0, < 2.33.8≥ 2.39.0, < 2.39.2≥ 2.40.0, < 2.41.0全バージョン | 2.33.82.39.22.41.0 |
| portainer | = 2.40.0≥ 2.33.0, < 2.33.8≥ 2.34.0, < 2.39.1 | 2.33.82.39.1 |
Portainer offers an environment-level Disable bind mounts for non-administrators security setting that blocks regular users from binding host paths into containers they create through the Portainer-mediated Docker API. The check that enforces this setting only inspected the legacy HostConfig.Binds array on the container-create proxy and never looked at the equivalent HostConfig.Mounts array. Any authenticated user with rights to create containers on a Docker environment where the restriction is enabled could submit a bind-typed entry under HostConfig.Mounts and mount any host path into their container.
The two fields are interchangeable on the Docker daemon — both produce real bind mounts at runtime — so a check that inspects only one is functionally equivalent to no check at all. The same primitive is correctly enforced on Swarm service create against TaskTemplate.ContainerSpec.Mounts; the gap was specific to the POST /containers/create proxy path.
Exploitation requires a regular user with container-create rights on an environment that has the restriction enabled. Such a user can mount any host path read-write or read-only into a container they own and use the resulting view of the host filesystem to read or write anything the Docker daemon's user can — typically root. Bind-mount restriction is the primary defence against host filesystem exposure on shared environments where regular users are otherwise permitted to deploy containers.
High
The vulnerability is exploitable over the network with low attack complexity, no attack requirement, and no user interaction. It requires a low-privilege authenticated session — any regular user with container-create rights on an environment where the bind-mount restriction is enabled. The vulnerable system (the Portainer container-create proxy) suffers a confidentiality and integrity breach by virtue of the bypass itself, but the dominant impact is on the subsequent system: the Docker host's filesystem and any container running alongside the attacker's. This is a restriction bypass rather than a cross-authority escalation — the user already had container-create rights, and the bind-mount restriction is a defence-in-depth control on top of that capability — which is the reason the rating is held at High rather than promoted to Critical despite the host-level reach.
The vulnerability has existed since the AllowBindMountsForRegularUsers security setting was introduced. The HostConfig.Mounts field has never been inspected by the container-create proxy on any release line.
Fixes are included in the following releases:
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン| Branch | First vulnerable | Fixed in |
|---|---|---|
| 2.33.x (LTS) | 2.33.0 | 2.33.8 |
| 2.39.x (LTS) | 2.39.0 | 2.39.2 |
| 2.41.x (STS) | all prior | 2.41.0 |
Portainer releases prior to 2.33.0 are end-of-life and will not receive a fix. Users on EOL versions should upgrade to a supported LTS branch.
Administrators who cannot immediately upgrade can reduce exposure by:
HostConfig.Mounts of Type: bind from non-admin Portainer users. Inspect Docker daemon logs and docker inspect output on affected environments. Any non-admin-created container with a bind-typed Mounts entry should be treated as a potential incident.None of these replace the fix.
The enforcement lives in decorateContainerCreationOperation in package/server-ce/api/http/proxy/factory/docker/containers.go. The PartialContainer struct used to deserialise the request body for inspection only contained HostConfig.Binds:
// package/server-ce/api/http/proxy/factory/docker/containers.go
type PartialContainer struct {
HostConfig struct {
Privileged bool `json:"Privileged"`
PidMode string `json:"PidMode"`
Devices []any `json:"Devices"`
Sysctls map[string]any `json:"Sysctls"`
CapAdd []string `json:"CapAdd"`
CapDrop []string `json:"CapDrop"`
Binds []string `json:"Binds"`
} `json:"HostConfig"`
}
if !securitySettings.AllowBindMountsForRegularUsers && len(partialContainer.HostConfig.Binds) > 0 {
for _, bind := range partialContainer.HostConfig.Binds {
if strings.HasPrefix(bind, "/") {
return forbiddenResponse, ErrBindMountsForbidden
}
}
}
The fix adds a Mounts field to PartialContainer and a parallel check that rejects any entry whose Type equals bind, mirroring the existing logic on the Swarm service-create proxy. The container-update path is unaffected — the Docker daemon does not accept mount changes via container update — and Swarm service create was already covered. Compose-stack deployment is not in scope of this advisory; the bind-mount restriction is a daemon-mediated container-create control, and Compose deployment runs Docker through a separate path that is not currently subject to the same restriction.
The same change applies cleanly on each LTS branch — the surrounding code shape on release/2.33 and release/2.39 is identical to develop on the points the patch touches, so the LTS backports are byte-equivalent additions of the Mounts field and the parallel check.
A regular user who has been explicitly restricted from using bind mounts can bypass the restriction and:
root), so any path is reachable. Sensitive examples include /etc/shadow, host SSH keys under /root/.ssh and /home/*/.ssh, and TLS material under /etc/docker./var/lib/docker (or equivalent) is reachable from within the bound mount, exposing the layers, volumes, and live state of every container the daemon manages./var/run/docker.sock into the attacker's container hands them full Docker API access on the host, regardless of any authorisation enforced by Portainer above the proxy.ReadOnly, the attacker can drop SSH keys into authorized_keys, install systemd units, or modify cron, achieving persistence outside of any container the daemon supervises.The bind-mount restriction was the primary defence against this class of host exposure for non-administrator container creators; bypassing it removes the only enforcement point above the daemon for tenants who were granted container-create rights.
develop.release/2.33 and release/2.39.HostConfig.Mounts bypass on container create and the divergence from the Swarm service-create check.HostConfig.Mounts bypass on container create.HostConfig.Mounts bypass on container create.HostConfig.Mounts bypass on container create.HostConfig.Mounts bypass on container create.HostConfig.Mounts bypass on container create.HostConfig.Mounts bypass on container create.