high CVSS 7.5

CVE-2026-44883·Docker vulnerability

Portainer Community Edition is a lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments. From 2.33.0 to before 2.33.8, 2.39.2, and 2.41.0, Portainer's authentication middleware accepts JWT bearer tokens passed as the ?token=<JWT> URL query parameter on any authenticated API endpoint, in addition to the standard Authorization: Bearer header. URLs are recorded in reverse-proxy access logs, browser history, and HTTP Referer headers on outbound navigation, so any JWT passed this way can be harvested by anyone with access to those logs or by an external site the user subsequently visits. A leaked token grants the full privileges of the user it was issued to, until the token expires (default 8 hours, configurable). The ?token= parameter was used by Portainer's browser-based container attach, exec, and pod shell features, so any user with exec or attach rights on a container was exposed — not only administrators. This vulnerability is fixed in 2.33.8, 2.39.2, and 2.41.0.

Severity
high
Software
Docker
Fixed in
2.41.0
Published
2026-05-28

Affected versions

From: 2.40.0

Until: 2.41.0

Fixed in: 2.41.0

How to fix this CVE

Update Docker to version 2.41.0 or later to eliminate the JWT token leakage vulnerability through URL query parameters. This fix removes the insecure ?token= parameter handling that previously exposed authentication credentials in logs and browser history. Immediately audit your reverse-proxy access logs and browser history for any leaked tokens, and consider rotating credentials for any accounts that may have been compromised.

sudo dnf update docker-ce -y

Defensia detects this vulnerability

What an exploitation attempt looks like

Sample log line indicative of exploitation attempts:

GET.*\?token=[A-Za-z0-9\-_.]+\s|Referer:.*\?token=[A-Za-z0-9\-_.]+

WAF mitigation (if patching is not yet possible)

Add this rule to your WAF to block exploitation attempts while you schedule the patch. 

Implement a WAF rule to block or strip ?token= query parameters from all requests to Portainer endpoints. Example: SecRule ARGS:token "@rx [A-Za-z0-9\-_.]" "id:1000,phase:2,deny,status:403,log"

How to check if you are affected

  1. Run 'docker --version' and verify the version is 2.41.0 or later; vulnerable versions are 2.40.0 through 2.40.x
  2. Check if Portainer is deployed by running 'docker ps | grep portainer' and note the image version tag
  3. Search reverse-proxy access logs (nginx, Apache, HAProxy) for patterns containing '?token=' in the request URI using 'grep -r "?token=" /var/log/'
  4. Verify the patch by checking Portainer's release notes or running a test authentication request without the ?token= parameter to confirm the parameter is no longer processed

FAQ

What is CVE-2026-44883?

CVE-2026-44883 is a token exposure vulnerability in Portainer Community Edition where JWT authentication tokens could be passed as URL query parameters (?token=) instead of secure HTTP headers, causing them to be logged in access logs, browser history, and HTTP Referer headers. This allowed attackers with log access to harvest valid authentication tokens and impersonate users.

Is CVE-2026-44883 being actively exploited?

No, CVE-2026-44883 is not listed on the CISA Known Exploited Vulnerabilities catalog and no public exploits are currently available. However, the vulnerability is trivial to exploit if an attacker gains access to logs or intercepts referrer headers.

What versions of Docker are affected by CVE-2026-44883?

Portainer Community Edition versions 2.33.0 through 2.33.7, 2.39.0 through 2.39.1, and 2.40.0 through 2.40.x are vulnerable. The vulnerability is fixed in versions 2.33.8, 2.39.2, and 2.41.0 or later.

How do I check if my server is vulnerable to CVE-2026-44883?

Run 'docker ps' to list running containers and identify Portainer by image name, then check its version with 'docker inspect <container_id> | grep -i version'. If the version is between 2.33.0-2.33.7, 2.39.0-2.39.1, or 2.40.0-2.40.x, your installation is vulnerable.

Does Defensia detect CVE-2026-44883?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Docker or Portainer is installed on a monitored server, CVE-2026-44883 will appear in your dashboard with remediation steps.

Related Docker CVEs

CVE-2026-44329CVSS 10free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's SMF mounts the UPI management route group without OAuth2/bearer-token authorization middleware. A network attacker who can reach SMF on the SBI can hit UPI endpoints with no Authorization header at all, and the requests reach the SMF business handlers. In the running Docker lab this was directly demonstrated for read (GET /upi/v1/upNodesLinks), write (POST /upi/v1/upNodesLinks with attacker-controlled UP-node and link payload), and delete (DELETE /upi/v1/upNodesLinks/{nodeID}) operations. This vulnerability is fixed in 4.2.2.
CVE-2026-40281CVSS 10Gotenberg is a Docker-powered stateless API for PDF files. In versions 8.30.1 and earlier, the metadata write endpoint validates metadata keys for control characters but leaves metadata values unsanitized. A newline character in a metadata value splits the ExifTool stdin line into two separate arguments, allowing injection of arbitrary ExifTool pseudo-tags such as -FileName, -Directory, -SymLink, and -HardLink. This is a bypass of the incomplete key-sanitization fix introduced in v8.30.1. An unauthenticated attacker can rename or move any PDF being processed to an arbitrary path in the container filesystem, overwrite arbitrary files, or create symlinks and hard links at arbitrary paths.
CVE-2026-57572CVSS 10Crawl4AI is an open-source LLM-friendly web crawler and scraper. Prior to 0.9.0, the Docker API server accepted request-supplied browser_config.extra_args, which flowed into Chromium's launch arguments. An attacker could inject Chromium switches that replace a child-process launch command together with --no-zygote, causing Chromium to fork or exec an attacker-controlled command as the container's runtime user. The Docker API is unauthenticated by default, so a single request yields arbitrary command execution. This issue is fixed in version 0.9.0.
CVE-2026-53576CVSS 10Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.45 and 1.3.21, the authentication filter for the REST API (@Filter("/api/v1/**")) treats any request whose path ends in /configs as the public instance-config endpoint and forwards it without a credential check. kestra addresses its resources by URL path segments that the caller chooses (/api/v1/{tenant}/flows/{namespace}, /api/v1/{tenant}/executions/{namespace}/{id}, /api/v1/{tenant}/namespaces/{namespace}/kv/{key}). An anonymous caller picks the literal configs as the final segment, and the request bypasses Basic-Auth entirely. Because the bypass reaches the flow-create and execution-trigger routes, an unauthenticated caller creates a flow containing a Shell or Process task and runs it. The task executes as root inside the kestra container. The official docker-compose.yml mounts /var/run/docker.sock, so root in the container reaches the host Docker daemon. This vulnerability is fixed in 1.0.45 and 1.3.21.
CVE-2026-33587CVSS 10Lack of user input sanitisation in Open Notebook v1.8.3 allows the application user to execute Python code (and subsequently OS commands) on the docker container via Server-Side Template Injection (SSTI) for user-created transformations.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2026-44883. Free for 1 server.

Get started free