Attack Chain

1. A user authenticates to Portainer, receiving a JWT.
2. The user initiates a container attach, exec, or pod shell operation, triggering a request to Portainer that includes the JWT as a ?token= query parameter.
3. The request is processed by Portainer’s authentication middleware, which accepts the JWT from the query parameter.
4. The request, including the JWT in the URL, is logged by a reverse proxy or other network monitoring tool.
5. Alternatively, the user navigates to an external site from within the Portainer UI, causing the JWT to be sent in the Referer header.
6. An attacker gains access to the logs or intercepts the Referer header, obtaining the leaked JWT.
7. The attacker uses the leaked JWT to authenticate to the Portainer API, impersonating the original user.
8. If the compromised token belongs to an administrator, the attacker gains full API access, including user management, container exec, and stack deployment, potentially compromising the host filesystem of managed environments.

Impact

Successful exploitation of this vulnerability can lead to significant data breaches and system compromise. Leaked tokens can be captured by intermediate systems like reverse proxies, exposing the full JWT in plaintext. URLs containing ?token= are recorded in browser history and forwarded in the Referer header. An attacker with a leaked JWT can act as the authenticated user for the remainder of the token’s validity, gaining full API access, including user management, container exec, and stack deployment. If the leaked token belongs to an administrator, the attacker gains full control over Portainer and its managed environments.

Recommendation

• Upgrade Portainer to version 2.33.8, 2.39.2, or 2.41.0 or later to remediate the vulnerability as outlined in the advisory.
• Implement reverse proxy rules to strip the ?token= parameter from requests before they reach Portainer, as mentioned in the workarounds, but be aware this breaks container attach/exec until Portainer is patched.
• Audit existing logs for occurrences of ?token= or &token= as mentioned in the workarounds, and treat any captured JWT as compromised by resetting affected user passwords.
• Deploy the Sigma rule “Detect Portainer JWT Parameter in Web Logs” to identify potential token leaks in web server logs.
• Deploy the Sigma rule “Detect Portainer API Access Using Leaked JWT” to identify API access attempts using leaked JWTs.

Attack Chain

1. An authenticated, non-admin user gains access to a Docker Swarm endpoint via Portainer RBAC.
2. The user crafts a POST /services/create request to create a new service, bypassing capability, sysctl, and security-opt checks.
3. Alternatively, the user creates a benign service and then sends a POST /services/{id}/update request to modify the service, bypassing all security checks.
4. The request includes configurations to elevate Linux capabilities (e.g., CapabilityAdd: ["ALL"]), disable syscall filtering (Privileges.Seccomp.Mode: "unconfined"), or disable AppArmor confinement (Privileges.AppArmor.Mode: "disabled").
5. The request may also include configurations for arbitrary sysctl values inside the container namespace, and/or bind mounts of any host path, including sensitive paths such as /, /var/run/docker.sock, or SSH keys.
6. The Docker daemon creates or updates the service with the elevated privileges, bypassing Portainer’s intended security restrictions.
7. The attacker can then leverage the elevated privileges to access the host filesystem (e.g., via chroot /host) or perform other actions with root-equivalent access on the Swarm manager host.
8. The final objective is to gain unauthorized access to sensitive data or systems, or to disrupt services running on the Docker Swarm cluster.

Impact

Successful exploitation allows a non-admin Portainer user to escalate privileges and gain root-equivalent access on the Swarm manager host. This bypasses the administrator’s security policy and enables the attacker to perform actions such as accessing sensitive data, modifying system configurations, or disrupting services. The impact is significant because it undermines the security model of Portainer and Docker Swarm, potentially leading to unauthorized access to critical infrastructure and data. The vulnerability affects every Portainer release with Docker Swarm support prior to versions 2.33.8, 2.39.2, and 2.41.0.

Recommendation

• Upgrade Portainer to versions 2.33.8, 2.39.2, or 2.41.0 to remediate CVE-2026-44849.
• Until an upgrade can be performed, temporarily revoke Swarm endpoint access for non-admin users via Portainer RBAC, as described in the advisory.
• Implement a daemon-side allowlist to block the creation of local-driver volumes that use type: none / o: bind on untrusted endpoints, mitigating the volume-driver-bind variant of the vulnerability.
• Deploy the Sigma rules provided in this brief to your SIEM to detect exploitation attempts targeting the Portainer API.

Attack Chain

1. An attacker authenticates to Portainer as a regular user with container-create rights.
2. The targeted Portainer environment has the “Disable bind mounts for non-administrators” security setting enabled.
3. The attacker crafts a POST /containers/create request to the Docker API through the Portainer proxy.
4. In the request body, the attacker includes a HostConfig.Mounts array with a bind-typed entry. This entry specifies the host path to be mounted into the container.
5. The Portainer proxy, which only checks HostConfig.Binds, fails to detect the malicious bind mount configuration in HostConfig.Mounts.
6. The Docker daemon creates the container with the specified bind mount, granting the attacker’s container access to the host filesystem.
7. The attacker executes commands within the container to read or write to the mounted host path, potentially accessing sensitive data or modifying system configurations.
8. The attacker compromises the host system, other containers, or achieves persistence by writing to authorized_keys or systemd units.

Impact

Successful exploitation allows a regular user to bypass bind mount restrictions and gain unauthorized access to the Docker host filesystem. This can lead to:

• Reading or writing any path on the Docker host filesystem, including sensitive files like /etc/shadow or SSH keys under /root/.ssh.
• Compromising other containers on the same host by accessing their layers, volumes, and live state within /var/lib/docker.
• Gaining full Docker API access by mounting /var/run/docker.sock into the container.
• Writing persistence to the host by dropping SSH keys into authorized_keys or installing systemd units.

This vulnerability affects installations where the bind-mount restriction was relied upon as the primary defense against host exposure, particularly in shared environments with non-administrator container creators.

Recommendation

• Upgrade Portainer to versions 2.33.8, 2.39.2, or 2.41.0 or later to patch CVE-2026-44850.
• Deploy the Sigma rule Detect Portainer HostConfig Mounts Bind Type (CVE-2026-44850) to detect attempts to exploit this vulnerability by monitoring container creation events.
• Audit recent container creations for HostConfig.Mounts of Type: bind from non-admin Portainer users as suggested in the advisory.
• Revoke container-create rights from non-administrator accounts on affected environments until the patched release is deployed as described in the advisory.

Attack Chain

1. A non-admin user authenticates to Portainer with access to a Docker endpoint.
2. The user crafts a POST request to the /plugins/pull endpoint, specifying a malicious Docker plugin from a public or private registry.
3. Portainer forwards the request to the Docker daemon without proper authorization checks, bypassing RBAC.
4. Docker pulls the specified plugin image from the registry.
5. The user crafts a POST request to the /plugins/{name}/enable endpoint to enable the pulled plugin.
6. Again, Portainer forwards the request to the Docker daemon without authorization.
7. Docker enables the plugin, granting it requested privileges such as CAP_SYS_ADMIN and host-path mounts.
8. The malicious Docker plugin executes with root privileges on the Docker host, allowing the user to read and modify files, effectively gaining complete control of the system.

Impact

This vulnerability allows an attacker with limited Portainer privileges to achieve root-level access on the Docker host. The attacker can then read and modify sensitive data, install malware, or disrupt services. Given the widespread use of Portainer in managing Docker environments, a successful exploit could lead to significant data breaches, system compromise, and operational disruption. Organizations using vulnerable Portainer versions are at high risk and should apply the provided patches or workarounds immediately.

Recommendation

• Upgrade Portainer: Immediately upgrade to the latest version of your supported branch (2.33.8, 2.39.2, or 2.41.0) to address the vulnerability as indicated in the advisory.
• Apply Workaround: As an interim measure, revoke Docker endpoint access for non-admin users via Portainer RBAC until the patched release is deployed as suggested in the “Workarounds” section.
• Monitor Docker API Access: Implement network monitoring to detect unauthorized access to the Docker API, focusing on /plugins/* endpoints, to catch potential exploit attempts.