{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/portainer/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Portainer (\u003e= 2.33.0, \u003c 2.33.8)","Portainer (\u003e= 2.39.0, \u003c 2.39.2)","Portainer (\u003e= 2.40.0, \u003c 2.41.0)"],"_cs_severities":["high"],"_cs_tags":["jwt","token-leak","credential-access","CVE-2026-44883","portainer"],"_cs_type":"advisory","_cs_vendors":["Portainer"],"content_html":"\u003cp\u003ePortainer is vulnerable to JWT leakage due to accepting tokens via the \u003ccode\u003e?token=\u0026lt;JWT\u0026gt;\u003c/code\u003e 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 \u003ccode\u003e?token=\u003c/code\u003e parameter was used by Portainer\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user authenticates to Portainer, receiving a JWT.\u003c/li\u003e\n\u003cli\u003eThe user initiates a container attach, exec, or pod shell operation, triggering a request to Portainer that includes the JWT as a \u003ccode\u003e?token=\u003c/code\u003e query parameter.\u003c/li\u003e\n\u003cli\u003eThe request is processed by Portainer\u0026rsquo;s authentication middleware, which accepts the JWT from the query parameter.\u003c/li\u003e\n\u003cli\u003eThe request, including the JWT in the URL, is logged by a reverse proxy or other network monitoring tool.\u003c/li\u003e\n\u003cli\u003eAlternatively, the user navigates to an external site from within the Portainer UI, causing the JWT to be sent in the Referer header.\u003c/li\u003e\n\u003cli\u003eAn attacker gains access to the logs or intercepts the Referer header, obtaining the leaked JWT.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the leaked JWT to authenticate to the Portainer API, impersonating the original user.\u003c/li\u003e\n\u003cli\u003eIf 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003e?token=\u003c/code\u003e are recorded in browser history and forwarded in the \u003ccode\u003eReferer\u003c/code\u003e header. An attacker with a leaked JWT can act as the authenticated user for the remainder of the token\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Portainer to version 2.33.8, 2.39.2, or 2.41.0 or later to remediate the vulnerability as outlined in the advisory.\u003c/li\u003e\n\u003cli\u003eImplement reverse proxy rules to strip the \u003ccode\u003e?token=\u003c/code\u003e parameter from requests before they reach Portainer, as mentioned in the workarounds, but be aware this breaks container attach/exec until Portainer is patched.\u003c/li\u003e\n\u003cli\u003eAudit existing logs for occurrences of \u003ccode\u003e?token=\u003c/code\u003e or \u003ccode\u003e\u0026amp;token=\u003c/code\u003e as mentioned in the workarounds, and treat any captured JWT as compromised by resetting affected user passwords.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Portainer JWT Parameter in Web Logs\u0026rdquo; to identify potential token leaks in web server logs.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Portainer API Access Using Leaked JWT\u0026rdquo; to identify API access attempts using leaked JWTs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-14T16:37:50Z","date_published":"2026-05-14T16:37:50Z","id":"https://feed.craftedsignal.io/briefs/2026-05-portainer-jwt-leak/","summary":"Portainer's authentication middleware accepts JWT bearer tokens passed as the `?token=\u003cJWT\u003e` URL query parameter on any authenticated API endpoint, leading to JWT leakage to logs and referrers, where a leaked token grants the full privileges of the user it was issued to, until the token expires.","title":"Portainer JWT Leak via URL Query Parameter","url":"https://feed.craftedsignal.io/briefs/2026-05-portainer-jwt-leak/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Portainer (\u003e= 2.33.0, \u003c 2.33.8)","Portainer (\u003e= 2.39.0, \u003c 2.39.2)","Portainer (\u003e= 2.40.0, \u003c 2.41.0)","Docker Swarm"],"_cs_severities":["critical"],"_cs_tags":["portainer","docker","swarm","privilege-escalation","vulnerability","CVE-2026-44849"],"_cs_type":"advisory","_cs_vendors":["Portainer","Docker"],"content_html":"\u003cp\u003ePortainer enforces \u003ccode\u003eEndpointSecuritySettings\u003c/code\u003e 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 \u003ccode\u003ePOST /services/create\u003c/code\u003e or \u003ccode\u003ePOST /services/{id}/update\u003c/code\u003e endpoints. This bypass allows the user to escalate privileges, gaining capabilities such as mounting arbitrary host paths, elevating Linux capabilities (e.g., \u003ccode\u003eCAP_SYS_ADMIN\u003c/code\u003e), 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn authenticated, non-admin user gains access to a Docker Swarm endpoint via Portainer RBAC.\u003c/li\u003e\n\u003cli\u003eThe user crafts a \u003ccode\u003ePOST /services/create\u003c/code\u003e request to create a new service, bypassing capability, sysctl, and security-opt checks.\u003c/li\u003e\n\u003cli\u003eAlternatively, the user creates a benign service and then sends a \u003ccode\u003ePOST /services/{id}/update\u003c/code\u003e request to modify the service, bypassing all security checks.\u003c/li\u003e\n\u003cli\u003eThe request includes configurations to elevate Linux capabilities (e.g., \u003ccode\u003eCapabilityAdd: [\u0026quot;ALL\u0026quot;]\u003c/code\u003e), disable syscall filtering (\u003ccode\u003ePrivileges.Seccomp.Mode: \u0026quot;unconfined\u0026quot;\u003c/code\u003e), or disable AppArmor confinement (\u003ccode\u003ePrivileges.AppArmor.Mode: \u0026quot;disabled\u0026quot;\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003e/\u003c/code\u003e, \u003ccode\u003e/var/run/docker.sock\u003c/code\u003e, or SSH keys.\u003c/li\u003e\n\u003cli\u003eThe Docker daemon creates or updates the service with the elevated privileges, bypassing Portainer\u0026rsquo;s intended security restrictions.\u003c/li\u003e\n\u003cli\u003eThe attacker can then leverage the elevated privileges to access the host filesystem (e.g., via \u003ccode\u003echroot /host\u003c/code\u003e) or perform other actions with root-equivalent access on the Swarm manager host.\u003c/li\u003e\n\u003cli\u003eThe final objective is to gain unauthorized access to sensitive data or systems, or to disrupt services running on the Docker Swarm cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows a non-admin Portainer user to escalate privileges and gain root-equivalent access on the Swarm manager host. This bypasses the administrator\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Portainer to versions 2.33.8, 2.39.2, or 2.41.0 to remediate CVE-2026-44849.\u003c/li\u003e\n\u003cli\u003eUntil an upgrade can be performed, temporarily revoke Swarm endpoint access for non-admin users via Portainer RBAC, as described in the advisory.\u003c/li\u003e\n\u003cli\u003eImplement a daemon-side allowlist to block the creation of local-driver volumes that use \u003ccode\u003etype: none\u003c/code\u003e / \u003ccode\u003eo: bind\u003c/code\u003e on untrusted endpoints, mitigating the volume-driver-bind variant of the vulnerability.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided in this brief to your SIEM to detect exploitation attempts targeting the Portainer API.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-14T16:37:27Z","date_published":"2026-05-14T16:37:27Z","id":"https://feed.craftedsignal.io/briefs/2026-05-portainer-swarm-bypass/","summary":"Portainer is vulnerable to an endpoint security bypass via Swarm service create/update, enabling non-admin users with access to a Docker Swarm endpoint to bypass `EndpointSecuritySettings` restrictions and gain elevated privileges such as configuring services with elevated Linux capabilities, disabling syscall filtering and AppArmor confinement, setting arbitrary sysctl values, and mounting arbitrary host paths.","title":"Portainer Endpoint Security Bypass via Docker Swarm Service API","url":"https://feed.craftedsignal.io/briefs/2026-05-portainer-swarm-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Portainer (\u003e= 2.33.0, \u003c 2.33.8)","Portainer (\u003e= 2.39.0, \u003c 2.39.2)","Portainer (\u003e= 2.40.0, \u003c 2.41.0)"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","vulnerability","container","CVE-2026-44850"],"_cs_type":"advisory","_cs_vendors":["Portainer"],"content_html":"\u003cp\u003ePortainer, a container management platform, contains a vulnerability (CVE-2026-44850) where the \u0026ldquo;Disable bind mounts for non-administrators\u0026rdquo; security setting can be bypassed. This setting aims to prevent regular users from binding host paths into containers they create through the Portainer-mediated Docker API. However, the check only inspected the \u003ccode\u003eHostConfig.Binds\u003c/code\u003e array and not the equivalent \u003ccode\u003eHostConfig.Mounts\u003c/code\u003e array. An authenticated user with container-create rights on an environment where the restriction is enabled could exploit this vulnerability and mount any host path into their container by submitting a \u003ccode\u003ebind\u003c/code\u003e-typed entry under \u003ccode\u003eHostConfig.Mounts\u003c/code\u003e. This bypass can be exploited to gain unauthorized access to the Docker host\u0026rsquo;s filesystem, compromising the entire system. Fixes were released in versions 2.33.8, 2.39.2, and 2.41.0.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker authenticates to Portainer as a regular user with container-create rights.\u003c/li\u003e\n\u003cli\u003eThe targeted Portainer environment has the \u0026ldquo;Disable bind mounts for non-administrators\u0026rdquo; security setting enabled.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003ePOST /containers/create\u003c/code\u003e request to the Docker API through the Portainer proxy.\u003c/li\u003e\n\u003cli\u003eIn the request body, the attacker includes a \u003ccode\u003eHostConfig.Mounts\u003c/code\u003e array with a \u003ccode\u003ebind\u003c/code\u003e-typed entry. This entry specifies the host path to be mounted into the container.\u003c/li\u003e\n\u003cli\u003eThe Portainer proxy, which only checks \u003ccode\u003eHostConfig.Binds\u003c/code\u003e, fails to detect the malicious bind mount configuration in \u003ccode\u003eHostConfig.Mounts\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Docker daemon creates the container with the specified bind mount, granting the attacker\u0026rsquo;s container access to the host filesystem.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands within the container to read or write to the mounted host path, potentially accessing sensitive data or modifying system configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises the host system, other containers, or achieves persistence by writing to authorized_keys or systemd units.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows a regular user to bypass bind mount restrictions and gain unauthorized access to the Docker host filesystem. This can lead to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eReading or writing any path on the Docker host filesystem, including sensitive files like \u003ccode\u003e/etc/shadow\u003c/code\u003e or SSH keys under \u003ccode\u003e/root/.ssh\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eCompromising other containers on the same host by accessing their layers, volumes, and live state within \u003ccode\u003e/var/lib/docker\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eGaining full Docker API access by mounting \u003ccode\u003e/var/run/docker.sock\u003c/code\u003e into the container.\u003c/li\u003e\n\u003cli\u003eWriting persistence to the host by dropping SSH keys into \u003ccode\u003eauthorized_keys\u003c/code\u003e or installing systemd units.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Portainer to versions 2.33.8, 2.39.2, or 2.41.0 or later to patch CVE-2026-44850.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Portainer HostConfig Mounts Bind Type (CVE-2026-44850)\u003c/code\u003e to detect attempts to exploit this vulnerability by monitoring container creation events.\u003c/li\u003e\n\u003cli\u003eAudit recent container creations for \u003ccode\u003eHostConfig.Mounts\u003c/code\u003e of \u003ccode\u003eType: bind\u003c/code\u003e from non-admin Portainer users as suggested in the advisory.\u003c/li\u003e\n\u003cli\u003eRevoke container-create rights from non-administrator accounts on affected environments until the patched release is deployed as described in the advisory.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-14T16:30:41Z","date_published":"2026-05-14T16:30:41Z","id":"https://feed.craftedsignal.io/briefs/2026-05-portainer-bind-mount-bypass/","summary":"Portainer versions 2.33.0 through 2.33.7, 2.39.0 through 2.39.1, and 2.40.0 through 2.40.9 are vulnerable to CVE-2026-44850, a bind-mount restriction bypass via the `HostConfig.Mounts` array allowing regular users to mount host paths into containers and potentially compromise the host filesystem.","title":"Portainer Bind Mount Restriction Bypass via HostConfig.Mounts (CVE-2026-44850)","url":"https://feed.craftedsignal.io/briefs/2026-05-portainer-bind-mount-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Portainer CE","Portainer"],"_cs_severities":["high"],"_cs_tags":["git","symlink","file-read","portainer","cve-2026-44881","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Portainer"],"content_html":"\u003cp\u003ePortainer 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 \u003ccode\u003ego-git\u003c/code\u003e v5 to clone Git repositories, which translates Git symlink entries into OS symlinks without proper validation, except for \u003ccode\u003e.gitmodules\u003c/code\u003e. By crafting a repository containing a \u003ccode\u003edocker-compose.yml\u003c/code\u003e file that is a symbolic link to a sensitive file (e.g., \u003ccode\u003e/etc/passwd\u003c/code\u003e, Kubernetes service account token), an attacker can trick Portainer into reading and disclosing the contents of the linked file via the \u003ccode\u003eGET /api/stacks/{id}/file\u003c/code\u003e endpoint. Git-stack auto-update amplifies the issue by allowing deferred exploitation through a malicious commit that replaces \u003ccode\u003edocker-compose.yml\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker creates a Git repository with a \u003ccode\u003edocker-compose.yml\u003c/code\u003e file configured as a symbolic link to a sensitive file (e.g., \u003ccode\u003e/etc/passwd\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the Portainer API or web interface to create a new stack, specifying the attacker-controlled Git repository as the source.\u003c/li\u003e\n\u003cli\u003ePortainer clones the Git repository using \u003ccode\u003ego-git\u003c/code\u003e, which creates the symlink on the filesystem.\u003c/li\u003e\n\u003cli\u003eAn authenticated user (admin or non-admin, depending on configuration) triggers the file read by accessing the stack through Portainer\u0026rsquo;s \u003ccode\u003eGET /api/stacks/{id}/file\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003ePortainer reads the \u003ccode\u003edocker-compose.yml\u003c/code\u003e file, which resolves to the attacker-specified target file due to the presence of the symlink.\u003c/li\u003e\n\u003cli\u003eThe contents of the sensitive file are returned in the HTTP response to the user who initiated the request.\u003c/li\u003e\n\u003cli\u003eIf auto-update is enabled, an attacker can push a malicious commit to an existing legitimate repository to replace the \u003ccode\u003edocker-compose.yml\u003c/code\u003e file with a symbolic link.\u003c/li\u003e\n\u003cli\u003eThe file read is then triggered on the next scheduled update cycle with no further interaction required, leaking sensitive data without further user action.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003e/etc/shadow\u003c/code\u003e, \u003ccode\u003e/root/.ssh/*\u003c/code\u003e, \u003ccode\u003e/proc/self/environ\u003c/code\u003e, and the Portainer BoltDB (\u003ccode\u003eportainer.db\u003c/code\u003e) containing user password hashes, API tokens, and agent credentials. In Kubernetes environments, the attacker can read the cluster service account token mounted at \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e, granting the attacker the Portainer pod\u0026rsquo;s cluster API access. Similarly, Docker Swarm secrets mounted into the Portainer container at \u003ccode\u003e/run/secrets/\u003c/code\u003e can be exposed. These leaked credentials can lead to onward compromise of managed Docker/Kubernetes environments, container registries, and Portainer itself.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Portainer version 2.33.8, 2.39.2, or 2.41.0, where the vulnerability is fixed.\u003c/li\u003e\n\u003cli\u003eDisable \u003cstrong\u003eAllow non-admin users to manage their stacks\u003c/strong\u003e in environment settings to restrict stack creation to administrators, reducing the attack surface.\u003c/li\u003e\n\u003cli\u003eCarefully review and avoid deploying Git-backed stacks from untrusted repositories.\u003c/li\u003e\n\u003cli\u003eDisable auto-update on existing stacks to prevent deferred exploitation.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Portainer Stack File Access to Sensitive Paths\u003c/code\u003e to identify requests accessing sensitive files through the stack file endpoint.\u003c/li\u003e\n\u003cli\u003eAudit existing stack working directories for unexpected symlink entries under \u003ccode\u003e/data/compose/\u003c/code\u003e (or your configured data directory) using \u003ccode\u003efind /data/compose -type l\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003ePatch CVE-2026-44881 across all Portainer instances.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-14T16:30:14Z","date_published":"2026-05-14T16:30:14Z","id":"https://feed.craftedsignal.io/briefs/2026-05-portainer-git-symlink-read/","summary":"Portainer is vulnerable to an arbitrary file read vulnerability due to Git symlink injection when deploying stacks from Git repositories, allowing authenticated users to read sensitive files accessible to the Portainer process.","title":"Portainer Arbitrary File Read via Git Symlink Injection","url":"https://feed.craftedsignal.io/briefs/2026-05-portainer-git-symlink-read/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Portainer (\u003e= 2.33.0, \u003c 2.33.8)"],"_cs_severities":["high"],"_cs_tags":["authorization","kubernetes","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Portainer"],"content_html":"\u003cp\u003ePortainer, a web UI for managing container environments, contains an authorization bypass vulnerability (CVE-2026-44882) within its Kubernetes proxy functionality. The vulnerability exists in the \u003ccode\u003ekubeClientMiddleware\u003c/code\u003e component responsible for validating user tokens before proxying requests to Kubernetes clusters. Due to a missing \u003ccode\u003ereturn\u003c/code\u003e statement after an error check, the middleware fails to properly terminate execution, leading to a nil \u003ccode\u003etokenData\u003c/code\u003e value being passed to subsequent authorization checks, effectively bypassing them. This allows a low-privileged Portainer user to access Kubernetes API endpoints without proper authorization. The vulnerability affects Portainer versions 2.33.0 through 2.33.7.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker authenticates to Portainer with a valid, low-privileged user account.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access a Kubernetes API endpoint within a managed cluster through the Portainer UI.\u003c/li\u003e\n\u003cli\u003ePortainer\u0026rsquo;s \u003ccode\u003eAuthenticatedAccess\u003c/code\u003e bouncer validates the initial Portainer session, allowing the request to proceed.\u003c/li\u003e\n\u003cli\u003eThe request reaches the \u003ccode\u003ekubeClientMiddleware\u003c/code\u003e in \u003ccode\u003eapi/http/handler/kubernetes/handler.go\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esecurity.RetrieveTokenData\u003c/code\u003e fails, because the user lacks specific permissions for the target Kubernetes endpoint.\u003c/li\u003e\n\u003cli\u003eThe middleware writes an HTTP 403 error to the response stream but fails to terminate execution due to a missing \u003ccode\u003ereturn\u003c/code\u003e statement.\u003c/li\u003e\n\u003cli\u003eExecution continues with a nil \u003ccode\u003etokenData\u003c/code\u003e value, bypassing the intended authorization check.\u003c/li\u003e\n\u003cli\u003eThe request is forwarded to the Kubernetes API server using Portainer\u0026rsquo;s service account credentials, potentially allowing unauthorized access and modification of cluster resources, depending on the permissions granted to Portainer\u0026rsquo;s service account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows a low-privileged Portainer user to bypass Kubernetes authorization checks and access Kubernetes API endpoints that they should not have access to. The impact includes the ability to read and modify namespaced Kubernetes resources such as pods, secrets, config maps, and deployments. Depending on the service account permissions, this could lead to lateral movement within the cluster if exposed secrets contain credentials for other services or infrastructure components.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Portainer version 2.33.8 or later to remediate the vulnerability (CVE-2026-44882).\u003c/li\u003e\n\u003cli\u003eRestrict Kubernetes endpoint access within Portainer to only those users who require it, as described in the \u0026ldquo;Workarounds\u0026rdquo; section of the advisory.\u003c/li\u003e\n\u003cli\u003eEnsure the service account used by Portainer to proxy cluster requests follows the principle of least privilege, limiting the potential impact of a successful authorization bypass, as described in the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Portainer Kubernetes Authorization Bypass Attempt\u0026rdquo; to detect attempts to exploit this vulnerability by monitoring for 403 errors followed by Kubernetes API requests.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-14T16:29:49Z","date_published":"2026-05-14T16:29:49Z","id":"https://feed.craftedsignal.io/briefs/2026-05-portainer-auth-bypass/","summary":"Portainer versions 2.33.0 through 2.33.7 are vulnerable to an authorization bypass in the `kubeClientMiddleware` component, allowing users with valid Portainer sessions to bypass Kubernetes authorization checks and access Kubernetes API endpoints on environments that their role should not permit (CVE-2026-44882).","title":"Portainer Kubernetes Authorization Bypass Vulnerability (CVE-2026-44882)","url":"https://feed.craftedsignal.io/briefs/2026-05-portainer-auth-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Portainer (\u003e= 2.33.0, \u003c 2.33.8)","Portainer (\u003e= 2.39.0, \u003c 2.39.2)","Portainer (\u003e= 2.40.0, \u003c 2.41.0)","Docker"],"_cs_severities":["critical"],"_cs_tags":["privilege-escalation","execution","CVE-2026-44848"],"_cs_type":"advisory","_cs_vendors":["Portainer"],"content_html":"\u003cp\u003ePortainer, a web-based management UI for Docker, has a critical missing authorization vulnerability (CVE-2026-44848) affecting versions 2.33.0-2.33.7, 2.39.0-2.39.1, and 2.40.0. This flaw allows a standard (non-admin) user with access to a Docker endpoint to bypass Role-Based Access Control (RBAC) and directly interact with the Docker daemon\u0026rsquo;s plugin management endpoints.  Specifically, the \u003ccode\u003e/plugins/*\u003c/code\u003e endpoints were not properly registered with an authorization handler. This oversight enables a malicious user to install, enable, and execute arbitrary Docker plugins, gaining root-level privileges on the underlying Docker host. This vulnerability was reported on 2026-03-16 and patched in subsequent releases, highlighting the importance of timely updates for Portainer deployments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA non-admin user authenticates to Portainer with access to a Docker endpoint.\u003c/li\u003e\n\u003cli\u003eThe user crafts a \u003ccode\u003ePOST\u003c/code\u003e request to the \u003ccode\u003e/plugins/pull\u003c/code\u003e endpoint, specifying a malicious Docker plugin from a public or private registry.\u003c/li\u003e\n\u003cli\u003ePortainer forwards the request to the Docker daemon without proper authorization checks, bypassing RBAC.\u003c/li\u003e\n\u003cli\u003eDocker pulls the specified plugin image from the registry.\u003c/li\u003e\n\u003cli\u003eThe user crafts a \u003ccode\u003ePOST\u003c/code\u003e request to the \u003ccode\u003e/plugins/{name}/enable\u003c/code\u003e endpoint to enable the pulled plugin.\u003c/li\u003e\n\u003cli\u003eAgain, Portainer forwards the request to the Docker daemon without authorization.\u003c/li\u003e\n\u003cli\u003eDocker enables the plugin, granting it requested privileges such as \u003ccode\u003eCAP_SYS_ADMIN\u003c/code\u003e and host-path mounts.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eUpgrade Portainer:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApply Workaround:\u003c/strong\u003e 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 \u0026ldquo;Workarounds\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMonitor Docker API Access:\u003c/strong\u003e Implement network monitoring to detect unauthorized access to the Docker API, focusing on \u003ccode\u003e/plugins/*\u003c/code\u003e endpoints, to catch potential exploit attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-14T16:29:27Z","date_published":"2026-05-14T16:29:27Z","id":"https://feed.craftedsignal.io/briefs/2026-05-portainer-rce/","summary":"Portainer versions 2.33.0 through 2.33.7, 2.39.0 through 2.39.1, and 2.40.0 expose a missing authorization vulnerability (CVE-2026-44848) on the Docker plugin management endpoints, allowing a non-admin user with access to a Docker endpoint to install and enable arbitrary Docker plugins from any registry, ultimately leading to root privileges on the Docker host and unauthorized file system access.","title":"Portainer Missing Authorization on Docker Plugin Endpoints Leads to Host RCE (CVE-2026-44848)","url":"https://feed.craftedsignal.io/briefs/2026-05-portainer-rce/"}],"language":"en","title":"CraftedSignal Threat Feed — Portainer","version":"https://jsonfeed.org/version/1.1"}