CVE-2026-55761: Portainer Auth Bypass Vulnerability

CVE-2026-55761 Overview

CVE-2026-55761 is an authentication bypass vulnerability [CWE-287] in Portainer Community Edition, a lightweight service delivery platform for managing Docker, Swarm, Kubernetes, and ACI environments. The flaw exists in versions 2.39.0 through 2.39.3 and 2.40.0 up to 2.43.0. During the five-minute setup window for uninitialized instances, the /api/restore and /api/users/admin/init endpoints remain reachable without authentication. A network attacker can restore a crafted backup or create the first administrator account to obtain full administrative access. Portainer resolved the issue in versions 2.39.4 and 2.43.0.

Critical Impact
Unauthenticated network attackers can seize administrative control over Portainer instances during the setup window, gaining management access to all connected container orchestration environments.

Affected Products

Portainer Community Edition versions 2.39.0 through 2.39.3
Portainer Community Edition versions 2.40.0 up to (but not including) 2.43.0
Uninitialized Portainer instances exposed on the network during the five-minute setup window

Discovery Timeline

2026-07-08 - CVE-2026-55761 published to the National Vulnerability Database (NVD)
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-55761

Vulnerability Analysis

Portainer initializes new deployments through a bootstrap flow that exposes two sensitive REST endpoints before any administrator credentials exist. The /api/users/admin/init endpoint creates the first administrator account, and /api/restore accepts a backup archive to restore configuration and state. Both endpoints are intentionally unauthenticated to allow the operator to complete setup.

The problem is that the setup window remains open for five minutes on any uninitialized instance. Any attacker with network reach during that window can call either endpoint first. Restoring a crafted backup lets the attacker seed their own users, endpoints, and credentials into Portainer. Calling admin/init sets the initial administrator password, locking the legitimate operator out.

Because Portainer typically holds credentials for Docker sockets, Kubernetes API servers, and container registries, administrative takeover extends directly to workload execution and secret disclosure across every connected environment.

Root Cause

The root cause is missing authentication on privileged setup endpoints during a time-based unlock window. There was no shared secret, token, or local-only requirement gating who could complete the bootstrap.

Attack Vector

Exploitation requires only network access to the Portainer HTTP API on an uninitialized instance. The attacker sends a POST request to /api/users/admin/init with attacker-chosen credentials, or uploads a crafted backup to /api/restore. No prior authentication, user interaction, or privileges are required.

// Patch excerpt: introduces a setup token requirement for admin init and restore
// Source: https://github.com/portainer/portainer/commit/49f19107cf9a3540cbe406c9eb7f24390e1af02b
TrustedOrigins: kingpin.Flag("trusted-origins", "List of trusted origins for CSRF protection. Separate multiple origins with a comma.").Envar(portainer.TrustedOriginsEnvVar).String(),
CSP:            kingpin.Flag("csp", "Content Security Policy (CSP) header").Envar(portainer.CSPEnvVar).Default("true").Bool(),
CompactDB:      kingpin.Flag("compact-db", "Enable database compaction on startup").Envar(portainer.CompactDBEnvVar).Default("false").Bool(),
NoSetupToken:   kingpin.Flag("no-setup-token", "Disable the setup token requirement for admin initialization and restore on an uninitialized instance").Envar(portainer.NoSetupTokenEnvVar).Bool(),
SetupToken:     kingpin.Flag("setup-token", "Set a custom setup token for admin initialization and restore on an uninitialized instance (overrides auto-generation)").Envar(portainer.SetupTokenEnvVar).String(),

The fix wires in a new api/http/security/setuptoken package and adds --setup-token and --no-setup-token CLI flags so that admin initialization and restore now require a token generated at startup.

Detection Methods for CVE-2026-55761

Indicators of Compromise

Unexpected POST requests to /api/users/admin/init or /api/restore in Portainer access logs from external or non-operator source IPs.
New administrator accounts appearing in Portainer immediately after container startup or restart.
Portainer configuration containing unfamiliar environment endpoints, Docker socket bindings, or registry credentials.
Unexpected restore events or backup imports recorded in Portainer audit history.

Detection Strategies

Alert on HTTP requests to /api/users/admin/init and /api/restore that originate from any address outside the administrator workstation range.
Correlate Portainer container start events with any successful admin/init call occurring more than a few seconds later from a remote host.
Detect creation of new stacks, environments, or user accounts within the first minutes after a fresh Portainer deployment.

Monitoring Recommendations

Forward Portainer application and reverse-proxy logs to a centralized log store and retain the setup window activity.
Monitor container orchestration audit logs (Docker, Kubernetes) for privileged actions initiated through Portainer service accounts after suspicious admin creation.
Track version strings served by Portainer to identify instances still running affected releases.

How to Mitigate CVE-2026-55761

Immediate Actions Required

Upgrade Portainer Community Edition to version 2.39.4 or 2.43.0 or later.
Restrict network access to the Portainer management port so only trusted administrator workstations can reach it during and after initial setup.
Audit existing Portainer instances for unknown administrator accounts, endpoints, and registry credentials, and rotate any secrets that were reachable through the platform.

Patch Information

The vendor addressed the issue in Portainer Release 2.39.4 and Portainer Release 2.43.0. The fix, tracked in Portainer Commit 49f19107 and Portainer Commit d2b56efc, adds a required setup token for admin initialization and restore. Additional context is available in the GitHub Security Advisory GHSA-x626-fcwx-f5pc and Portainer Issue Discussion.

Workarounds

Deploy Portainer only behind a network policy or firewall that blocks external access until the administrator account is created.
Complete the setup flow immediately after starting the container, keeping the five-minute window as short as possible.
On patched versions, use the --setup-token flag to enforce a custom setup token, and avoid the --no-setup-token override in production.

bash

# Configuration example: enforce a setup token on a patched Portainer instance
docker run -d \
  -p 9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:2.43.0 \
  --setup-token "$(openssl rand -hex 32)"