Portainer has Unauthenticated Restore Endpoint that Allows Admin Takeover on Uninitialized Instances

Workarounds

Administrators who cannot immediately upgrade can reduce exposure by:

• Provision the administrator account at deploy time. Start any network-reachable instance with --admin-password or --admin-password-file, supplying a pre-set administrator password. The admin account then exists from first boot, so the instance is never in the uninitialised state that the restore and admin-init endpoints depend on — there is no setup window for an attacker to race. This is the most effective workaround for new, internet- or network-facing deployments. Instances on genuinely trusted networks (air-gapped or isolated private LANs) don't require it.
• Restrict network access to Portainer before completing initial setup. Use firewall rules, VPC security groups, or a reverse proxy to prevent untrusted networks from reaching the Portainer API while the instance is uninitialised. Remove the restriction once an admin account has been created and initial setup is complete.
• Complete initial setup immediately after deployment. The initialization endpoints stop accepting requests once the instance has an administrator account. Minimising the uninitialised window limits the exploitation opportunity.
• Audit existing deployments for unauthorised admin accounts. If a deployment may have been accessible before setup was completed, review the admin account list and rotate all credentials.

None of these replace the fix.

Affected Code

The vulnerability is in api/http/handler/backup/handler.go and api/http/handler/backup/restore.go. The handler registers the restore endpoint with bouncer.PublicAccess, bypassing all authentication middleware:

// api/http/handler/backup/handler.go — NewHandler
h.Handle("/restore", bouncer.PublicAccess(httperror.LoggerHandler(h.restore))).Methods(http.MethodPost)

The restore handler then checks only whether the instance has been initialised before proceeding:

// api/http/handler/backup/restore.go — restore
func (h *Handler) restore(w http.ResponseWriter, r *http.Request) *httperror.HandlerError {
    initialized, err := h.adminMonitor.WasInitialized()
    if err != nil {
        return httperror.InternalServerError("Failed to check system initialization", err)
    }
    if initialized {
        return httperror.BadRequest("Cannot restore already initialized instance", errors.New("system already initialized"))
    }
    h.adminMonitor.Stop()
    // Proceeds to restore the archive unconditionally

The fix introduces a one-time setup token that gates the public initialization endpoints — both administrator account creation (/api/users/admin/init) and restore (/api/restore) — while an instance is uninitialised. On startup, when no administrator account exists and no admin password was supplied through configuration, Portainer generates a cryptographically random token and writes it to the server logs. The restore and admin-init handlers reject any request that does not present this token in an X-Setup-Token header, returning 403 Forbidden. Deployments that provision the administrator password at deploy time (--admin-password / --admin-password-file) require no token; the requirement can be pinned to an operator-chosen value (--setup-token) or disabled on trusted networks (--no-setup-token). The same change is backported to release/2.39 for the 2.39.4 release.

Impact

• Full administrative access to Portainer. The attacker replaces the database with one containing their own admin credentials and can then authenticate as a full administrator with no legitimate-user involvement.
• Host-level compromise. Portainer CE typically runs with access to the Docker socket (/var/run/docker.sock); an attacker with Portainer admin access can use container creation APIs to mount the host filesystem and execute commands as root.
• Access to all managed environments. The compromised Portainer admin account has credentials and API access for every Docker host, Kubernetes cluster, and edge agent registered in that instance, including any stored registry credentials, environment variables, and secrets.
• Persistence across credential changes. Because the attacker controls the database, they can re-insert admin credentials or maintain secondary accounts even if a legitimate user later resets the primary password via the UI.

Timeline

• 2026-05-07: Reported privately by um3b0shi.
• 2026-06-04: Fix merged to develop.
• 2026-06-24: 2.43.0 (STS) released with the fix.
• 2026-06-25: 2.39.4 (LTS) released with the backported fix.

Credit

• um3b0shi — discovered and reported the unauthenticated admin takeover via the /api/restore endpoint. Coverage of the companion administrator-account-creation endpoint (/api/users/admin/init) was added by the Portainer team as part of the fix.