Critical Portainer Flaws Grant Restricted Users Root Access to the Host

A dangerous pair of critical authorization failures within the Portainer container management platform allows standard, restricted users to instantly break out of their isolation and seize absolute root control over the underlying host infrastructure.

Portainer Community Edition has long marketed itself as a lightweight, user-friendly delivery platform designed to simplify the orchestration of Docker, Swarm, and Kubernetes environments. However, a newly disclosed security advisory has exposed two severe flaws—tracked as CVE-2026-44848 and CVE-2026-44849—each carrying a critical CVSS score of 9.4.

The findings reveal structural gaps in Portainer’s proxy architecture and validation logic. If a non-administrative user is granted access to even a single Docker or Swarm endpoint, they can completely dismantle the administrator’s security policy, access the underlying host filesystem, and execute code with root privileges.

The first vulnerability, tracked as CVE-2026-44848, centers on a massive oversight within Portainer’s Role-Based Access Control (RBAC) layer. While Portainer successfully intercepts and filters standard Docker API requests (like containers and images), it completely neglected to protect the endpoints handling third-party Docker plugins.

Because the Docker plugin management endpoints (/plugins/*) were never registered with an internal proxy handler, incoming requests from low-privileged users passed straight through to the underlying Docker daemon without any authorization checks.

An authenticated, non-admin user can easily exploit this by executing a multi-step sequence:

1. Pull a Malicious Plugin: The user triggers POST /plugins/pull to fetch a custom, malicious plugin from any public or private registry.
2. Grant Arbitrary Privileges: Because Portainer does not validate the request body, the restricted user can grant the plugin high-risk system privileges, including CAP_SYS_ADMIN and host-path storage mounts.
3. Execute as Host Root: Upon hitting POST /plugins/{name}/enable, the Docker daemon triggers the plugin. Docker plugins naturally execute with full root privileges on the host system.

By deploying a crafted plugin with a host-path mount pointing to /, a restricted user bypasses all container boundaries, gaining total read and write access to the host operating system.

The second vulnerability, tracked as CVE-2026-44849, exposes a severe validation breakdown affecting Docker Swarm deployments.

To keep standard users isolated, Portainer administrators configure seven specific Endpoint Security Settings designed to block regular accounts from launching dangerous container configurations (such as privileged mode, host PID sharing, custom capabilities, or raw bind mounts). While these rules are strictly enforced on standard container creation paths, researchers discovered they are almost entirely absent on the Docker Swarm service APIs.

When a non-admin user interacts with a Swarm cluster, Portainer fails to parse the incoming payloads correctly:

• Service Creation (POST /services/create): Only 1 out of 7 security checks are applied. Crucial parameters like CapabilityAdd, Sysctls, and Seccomp/AppArmor security options are completely ignored by Portainer’s validator and forwarded straight to the Swarm manager. A user can instantly launch a service with CAP_SYS_ADMIN or disable system call filtering entirely.
• Service Updates (POST /services/{id}/update): Enforces 0 out of 7 security checks. The endpoint validates that the user owns the service, but it does not inspect the request body or fetch the administrator’s security policy.

An attacker can easily bypass the strict “No Bind Mounts” policy by creating a benign service, and then immediately issuing an update request to inject CapabilityAdd: [“ALL”] alongside a raw bind mount linking the container’s internal storage directly to the host’s root (/) directory.

Furthermore, the check meant to stop bind mounts was found to be incredibly surface-level. It only inspects the top-level Type: “bind” field.

An attacker can declare a standard Type: “volume” mount, but use advanced VolumeOptions.DriverConfig to pass local-driver arguments: {type: “none”, o: “bind”, device: “/var/run/docker.sock”}. The local volume driver materializes this as a bind mount, completely blinding Portainer’s security policy and allowing the container to steal SSH keys or Portainer’s own internal database.

Because these bugs impact the fundamental architecture of Portainer’s proxying capabilities, security maintainers have backported fixes across all active branches.

Affected Branch Cluster	First Vulnerable Version	Formal Security Fix Version
2.33.x (LTS)	Version 2.33.0	Version 2.33.8
2.39.x (LTS)	Version 2.39.0	Version 2.39.2
2.40.x (STS)	Version 2.40.0	Version 2.41.0

Note: All releases prior to 2.33.0 are officially End-of-Life (EOL) and will not receive security fixes. Users on EOL versions must migrate to a supported Long-Term Support (LTS) branch immediately.

For large enterprise environments where production update freeze cycles prevent immediate deployment, administrators must rapidly apply the following tactical workarounds to reduce exposure:

• Revoke Endpoint Access via RBAC: The most effective immediate block is to temporarily revoke Docker and Docker Swarm endpoint permissions for all non-admin users via Portainer’s RBAC panel. This completely eliminates the network attack surface without causing operational downtime for genuine administrators.
• Isolate Manager Nodes via Placement Constraints: Configure strict placement constraints to segregate manager and worker nodes within the Swarm cluster. Ensuring that standard user workloads are legally barred from running on manager nodes heavily limits the exposure of the Swarm control plane if an internal breakout occurs on a worker node.
• Deploy Daemon-Side Volume Allowlists: To neutralize the volume-driver bind bypass, implement a daemon-side allowlist on your underlying Docker daemons to explicitly block the creation of local-driver volumes utilizing type: none or o: bind options on untrusted endpoints.