{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Portainer Community Edition is a lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments. From 2.33.0 to before 2.33.8, 2.39.2, and 2.41.0, 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. This vulnerability is fixed in 2.33.8, 2.39.2, and 2.41.0."
    }
  ],
  "id": "CVE-2026-44850",
  "lastModified": "2026-05-29T15:06:44.207",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8.5,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "LOW",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.1,
        "impactScore": 4.7,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-05-28T22:16:59.107",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/portainer/portainer/security/advisories/GHSA-7fw3-x4r2-g7wc"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Undergoing Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-863"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0"
            },
            {
              "fixed": "2.33.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.39.0"
            },
            {
              "fixed": "2.39.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/portainer/portainer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.40.0"
            },
            {
              "fixed": "2.41.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T16:23:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPortainer 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.\n\nThe two fields are interchangeable on the Docker daemon \u2014 both produce real bind mounts at runtime \u2014 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.\n\nExploitation 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\u0027s user can \u2014 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.\n\n## Severity\n\n**High**\n\nThe vulnerability is exploitable over the network with low attack complexity, no attack requirement, and no user interaction. It requires a low-privilege authenticated session \u2014 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\u0027s filesystem and any container running alongside the attacker\u0027s. This is a restriction bypass rather than a cross-authority escalation \u2014 the user already had container-create rights, and the bind-mount restriction is a defence-in-depth control on top of that capability \u2014 which is the reason the rating is held at High rather than promoted to Critical despite the host-level reach.\n\n## Affected Versions\n\nThe 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.\n\nFixes are included in the following releases:\n\n| Branch       | First vulnerable | Fixed in   |\n|--------------|------------------|------------|\n| 2.33.x (LTS) | 2.33.0           | **2.33.8** |\n| 2.39.x (LTS) | 2.39.0           | **2.39.2** |\n| 2.41.x (STS) | all prior        | **2.41.0** |\n\nPortainer 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.\n\n## Workarounds\n\nAdministrators who cannot immediately upgrade can reduce exposure by:\n\n- **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.\n- **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.\n- **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.\n\nNone of these replace the fix.\n\n## Affected Code\n\nThe 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`:\n\n```\n// package/server-ce/api/http/proxy/factory/docker/containers.go\ntype PartialContainer struct {\n    HostConfig struct {\n        Privileged bool           `json:\"Privileged\"`\n        PidMode    string         `json:\"PidMode\"`\n        Devices    []any          `json:\"Devices\"`\n        Sysctls    map[string]any `json:\"Sysctls\"`\n        CapAdd     []string       `json:\"CapAdd\"`\n        CapDrop    []string       `json:\"CapDrop\"`\n        Binds      []string       `json:\"Binds\"`\n    } `json:\"HostConfig\"`\n}\n\nif !securitySettings.AllowBindMountsForRegularUsers \u0026\u0026 len(partialContainer.HostConfig.Binds) \u003e 0 {\n    for _, bind := range partialContainer.HostConfig.Binds {\n        if strings.HasPrefix(bind, \"/\") {\n            return forbiddenResponse, ErrBindMountsForbidden\n        }\n    }\n}\n```\n\nThe 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 \u2014 the Docker daemon does not accept mount changes via container update \u2014 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.\n\nThe same change applies cleanly on each LTS branch \u2014 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.\n\n## Impact\n\nA regular user who has been explicitly restricted from using bind mounts can bypass the restriction and:\n\n- **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`.\n- **Compromise other containers on the same host.** The host\u0027s `/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.\n- **Reach the Docker socket.** Mounting `/var/run/docker.sock` into the attacker\u0027s container hands them full Docker API access on the host, regardless of any authorisation enforced by Portainer above the proxy.\n- **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.\n\nThe 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.\n\n## Timeline\n\n- 2026-03-04: Reported via GitHub Security Advisory by **offensiveee** (Assaf Alassaf).\n- 2026-03-04 \u2013 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.\n- 2026-04-18: Fix merged to `develop`.\n- 2026-06-04: Backports merged to `release/2.33` and `release/2.39`.\n- 2026-04-29: 2.41.0 released with fix.\n- 2026-05-07: 2.33.8, 2.39.2, released with fix.\n\n## Credit\n\n- **offensiveee** (Assaf Alassaf) \u2014 initial report identifying the `HostConfig.Mounts` bypass on container create and the divergence from the Swarm service-create check.\n- **alexwaira** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **ffulbtech** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **Proscan-one** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **jeroengui** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **AyushParkara** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.\n- **marduc812** \u2014 independently reported the same `HostConfig.Mounts` bypass on container create.",
  "id": "GHSA-7fw3-x4r2-g7wc",
  "modified": "2026-05-14T16:23:45Z",
  "published": "2026-05-14T16:23:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/security/advisories/GHSA-7fw3-x4r2-g7wc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/portainer/portainer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.33.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.39.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/portainer/portainer/releases/tag/2.41.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Portainer has a bind-mount restriction bypass via HostConfig.Mounts"
}