Portainer has a bind-mount restriction bypass via HostConfig.Mounts

Affected Versions

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:

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.

Workarounds

Administrators who cannot immediately upgrade can reduce exposure by:

• Revoke container-create rights from non-administrator accounts on affected environments. If the bind-mount restriction is being relied on as a hard guarantee, audit which non-administrator accounts have container-create rights on environments where it is set, and downgrade those accounts to roles that lack container-create until the patched release is deployed. Stack and service deployment that depends on container-create will stop working for those users until the patched release is in place.
• Audit recent container creations for 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.
• Segregate tenants by environment. Where the per-environment toggle was being used to share an environment between tenants of different trust levels, splitting the workloads onto separate environments is a stronger control than the toggle and remains in place after upgrade.

None of these replace the fix.

Affected Code

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.

Impact

A regular user who has been explicitly restricted from using bind mounts can bypass the restriction and:

• Read or write any path on the Docker host filesystem. The mount runs as the daemon user (typically 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.
• Compromise other containers on the same host. The host's /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.
• Reach the Docker socket. Mounting /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.
• Write persistence to the host. Without 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.

Timeline

• 2026-03-04: Reported via GitHub Security Advisory by offensiveee (Assaf Alassaf).
• 2026-03-04 – 2026-04-17: Six further independent reports of the same primitive received via GitHub Security Advisory (alexwaira, ffulbtech, Proscan-one, jeroengui, AyushParkara, marduc812) and consolidated against this advisory.
• 2026-04-18: Fix merged to develop.
• 2026-06-04: Backports merged to release/2.33 and release/2.39.
• 2026-04-29: 2.41.0 released with fix.
• 2026-05-07: 2.33.8, 2.39.2, released with fix.

Credit

• offensiveee (Assaf Alassaf) — initial report identifying the HostConfig.Mounts bypass on container create and the divergence from the Swarm service-create check.
• alexwaira — independently reported the same HostConfig.Mounts bypass on container create.
• ffulbtech — independently reported the same HostConfig.Mounts bypass on container create.
• Proscan-one — independently reported the same HostConfig.Mounts bypass on container create.
• jeroengui — independently reported the same HostConfig.Mounts bypass on container create.
• AyushParkara — independently reported the same HostConfig.Mounts bypass on container create.
• marduc812 — independently reported the same HostConfig.Mounts bypass on container create.