Portainer — CraftedSignal Threat Feed

Portainer JWT Leak via URL Query Parameter

hello@craftedsignal.io — Thu, 14 May 2026 16:37:50 +0000

Portainer is vulnerable to JWT leakage due to accepting tokens via the ?token= URL query parameter. This vulnerability, present since the introduction of JWT authentication, allows the JWT to be exposed in reverse proxy logs, browser history, and HTTP Referer headers. The ?token= parameter was used by Portainer’s browser-based container attach, exec, and pod shell features, impacting any user with exec or attach rights. The issue was reported on 2026-03-06, and fixed in versions 2.33.8, 2.39.2, and 2.41.0. Exploitation requires an attacker to obtain a leaked token, but once obtained, it grants the privileges of the user it was issued to, including administrative access.

Attack Chain

A user authenticates to Portainer, receiving a JWT.
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.
The request is processed by Portainer’s authentication middleware, which accepts the JWT from the query parameter.
The request, including the JWT in the URL, is logged by a reverse proxy or other network monitoring tool.
Alternatively, the user navigates to an external site from within the Portainer UI, causing the JWT to be sent in the Referer header.
An attacker gains access to the logs or intercepts the Referer header, obtaining the leaked JWT.
The attacker uses the leaked JWT to authenticate to the Portainer API, impersonating the original user.
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.

Portainer Endpoint Security Bypass via Docker Swarm Service API

hello@craftedsignal.io — Thu, 14 May 2026 16:37:27 +0000

Portainer enforces EndpointSecuritySettings restrictions to limit container configurations for non-admin users. However, these restrictions are not fully applied when creating or updating Docker Swarm services through the Portainer API. A non-admin user with access to a Docker Swarm endpoint can bypass these security measures by using the POST /services/create or POST /services/{id}/update endpoints. This bypass allows the user to escalate privileges, gaining capabilities such as mounting arbitrary host paths, elevating Linux capabilities (e.g., CAP_SYS_ADMIN), disabling syscall filtering, and disabling AppArmor confinement. The vulnerability affects all Portainer releases with Docker Swarm support prior to versions 2.33.8, 2.39.2, and 2.41.0, undermining the administrator’s security policy on Swarm-enabled endpoints. The volume driver local-bind variant was disclosed on 2026-03-12, and the Swarm service create/update bypass was disclosed on 2026-04-05.

Attack Chain

An authenticated, non-admin user gains access to a Docker Swarm endpoint via Portainer RBAC.
The user crafts a POST /services/create request to create a new service, bypassing capability, sysctl, and security-opt checks.
Alternatively, the user creates a benign service and then sends a POST /services/{id}/update request to modify the service, bypassing all security checks.
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").
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.
The Docker daemon creates or updates the service with the elevated privileges, bypassing Portainer’s intended security restrictions.
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.
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.

Portainer Arbitrary File Read via Git Symlink Injection

hello@craftedsignal.io — Thu, 14 May 2026 16:30:14 +0000

Portainer is susceptible to an arbitrary file read vulnerability (CVE-2026-44881) stemming from Git symlink injection during stack deployment from Git repositories. An attacker with the ability to create or update Git-backed stacks can exploit this flaw. The vulnerability arises because Portainer uses go-git v5 to clone Git repositories, which translates Git symlink entries into OS symlinks without proper validation, except for .gitmodules. By crafting a repository containing a docker-compose.yml file that is a symbolic link to a sensitive file (e.g., /etc/passwd, Kubernetes service account token), an attacker can trick Portainer into reading and disclosing the contents of the linked file via the GET /api/stacks/{id}/file endpoint. Git-stack auto-update amplifies the issue by allowing deferred exploitation through a malicious commit that replaces docker-compose.yml with a symlink. This vulnerability affects Portainer releases from the introduction of Git-based stack deployment until the fixes in versions 2.33.8, 2.39.2, and 2.41.0.

Attack Chain

An attacker creates a Git repository with a docker-compose.yml file configured as a symbolic link to a sensitive file (e.g., /etc/passwd).
The attacker uses the Portainer API or web interface to create a new stack, specifying the attacker-controlled Git repository as the source.
Portainer clones the Git repository using go-git, which creates the symlink on the filesystem.
An authenticated user (admin or non-admin, depending on configuration) triggers the file read by accessing the stack through Portainer’s GET /api/stacks/{id}/file endpoint.
Portainer reads the docker-compose.yml file, which resolves to the attacker-specified target file due to the presence of the symlink.
The contents of the sensitive file are returned in the HTTP response to the user who initiated the request.
If auto-update is enabled, an attacker can push a malicious commit to an existing legitimate repository to replace the docker-compose.yml file with a symbolic link.
The file read is then triggered on the next scheduled update cycle with no further interaction required, leaking sensitive data without further user action.

Impact

Successful exploitation of this vulnerability allows an attacker to read arbitrary files accessible to the Portainer process, typically running as root in containerized deployments. This includes sensitive files such as /etc/shadow, /root/.ssh/*, /proc/self/environ, and the Portainer BoltDB (portainer.db) containing user password hashes, API tokens, and agent credentials. In Kubernetes environments, the attacker can read the cluster service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token, granting the attacker the Portainer pod’s cluster API access. Similarly, Docker Swarm secrets mounted into the Portainer container at /run/secrets/ can be exposed. These leaked credentials can lead to onward compromise of managed Docker/Kubernetes environments, container registries, and Portainer itself.

Recommendation

Upgrade to Portainer version 2.33.8, 2.39.2, or 2.41.0, where the vulnerability is fixed.
Disable Allow non-admin users to manage their stacks in environment settings to restrict stack creation to administrators, reducing the attack surface.
Carefully review and avoid deploying Git-backed stacks from untrusted repositories.
Disable auto-update on existing stacks to prevent deferred exploitation.
Deploy the Sigma rule Detect Portainer Stack File Access to Sensitive Paths to identify requests accessing sensitive files through the stack file endpoint.
Audit existing stack working directories for unexpected symlink entries under /data/compose/ (or your configured data directory) using find /data/compose -type l.
Patch CVE-2026-44881 across all Portainer instances.