CVE-2026-44850: Portainer Bind Mount Restriction Bypass – HIGH Severity Security Flaw

Technical summary

Portainer's environment-level 'Disable bind mounts for non-administrators' setting is designed to block unprivileged users from submitting bind-mount directives through the Portainer proxy to the Docker API. The validation logic only inspects the legacy HostConfig.Binds array during container creation but omits validation of the functionally equivalent HostConfig.Mounts array. An attacker with valid authentication and container-creation permissions can embed a bind-type mount directive in HostConfig.Mounts to bypass the restriction. This maps to CWE-863 (Incorrect Authorization) and allows unauthorized host-path mounting despite policy controls being explicitly configured. The fix validates both arrays comprehensively.

Business impact

This vulnerability undermines a core multi-tenancy and least-privilege control in containerized environments. Organizations relying on Portainer's bind-mount restriction to prevent privileged users from accessing sensitive host data—such as secrets, configuration files, or system directories—face a breakdown of that isolation. Compromised or malicious authenticated users can exfiltrate or modify host state without administrative approval. In shared container platforms or managed hosting scenarios, this can facilitate lateral movement, data theft, or sabotage. Risk is highest in regulated industries where container isolation is a compliance requirement.

Affected systems

Portainer Community Edition versions 2.33.0 through 2.33.7, 2.39.0 through 2.39.1, and any 2.40.x release are vulnerable. Fixed versions are 2.33.8, 2.39.2, and 2.41.0 or later. Organizations using Portainer to manage Docker, Swarm, Kubernetes, or ACI environments with the bind-mount restriction policy enabled are at risk. The vulnerability requires valid authentication and container-creation privileges, so it does not affect Portainer instances with strong authentication or restricted user permissions.

Exploitability

Exploitation requires valid Portainer credentials and authorized container-creation capabilities on a Docker environment where the bind-mount restriction is explicitly enabled. No public exploit code is known. The attack is straightforward—submitting a standard Docker API request with HostConfig.Mounts instead of HostConfig.Binds—and would be detected by standard API logging if monitored. The CVSS 3.1 score of 8.5 (HIGH) reflects the need for prior authentication and valid user role, but also the wide scope impact (containers can reach host resources) and high confidentiality risk.

Remediation

Upgrade to Portainer Community Edition 2.33.8, 2.39.2, or 2.41.0 or later, depending on your current branch. After upgrade, the container-creation proxy will validate both HostConfig.Binds and HostConfig.Mounts arrays, blocking bind-mount directives for unprivileged users even if submitted via alternate API fields. Verify the upgrade in a non-production environment first. Older versions in branch 2.40.x should transition to 2.41.0 or adopt the 2.39.2 patch.

Patch guidance

Identify your current Portainer version via the web UI (Settings > System) or API (`GET /api/system`). If running 2.33.0–2.33.7, upgrade to 2.33.8. If running 2.39.0–2.39.1, upgrade to 2.39.2. If running any 2.40.x version, upgrade to 2.41.0 or later. Download from Portainer's official releases page and follow their documented upgrade procedure, including backup of the Portainer database. Test container-creation restrictions in a staging environment to confirm the fix enforces the policy on both Binds and Mounts arrays.

Detection guidance

Review Portainer container-creation audit logs for authenticated users submitting requests with non-empty HostConfig.Mounts arrays while the bind-mount restriction is supposedly enabled. Such requests should be rejected post-patch; if accepted pre-patch, they indicate successful bypass attempts. Monitor for host-path mount activity originating from Portainer-managed containers using `docker inspect` or `docker mount` commands and cross-reference with intended policy. Inspect container runtime logs for unexpected mount namespaces. Correlate Portainer API logs with Docker daemon logs to identify discrepancies between intended and actual mount configuration.

Why prioritize this

This vulnerability merits prompt patching because it directly bypasses a security policy that organizations intentionally configure to enforce access control and data isolation. The attacker profile (authenticated user with existing privileges) is realistic in multi-user or shared container platforms. The impact (host-path access) is substantial for confidentiality and integrity. While not yet tracked in the CISA KEV catalog, the simplicity of exploitation and widespread use of Portainer in container orchestration make it a near-term risk.

Risk score, explained

CVSS 3.1 score of 8.5 (HIGH) reflects: Attack Vector Network (AV:N) because Portainer is typically network-accessible; Attack Complexity Low (AC:L) because the bypass is trivial; Privileges Required Low (PR:L) because valid authentication and container-creation role are needed; User Interaction None (UI:N) because the attack is direct API submission; Scope Changed (S:C) because the attacker escapes container constraints and impacts the host; Confidentiality High (C:H) because host data is readable; Integrity Low (I:L) because host data can be modified but not fully compromised; Availability None (A:N). The score appropriately penalizes the bypass of an explicit security control.

Frequently asked questions