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

Summary

Portainer supports restoring an instance from a backup archive via the /api/restore endpoint. This endpoint is intentionally unauthenticated to allow restoring before the first admin account is created, and remains accessible for the five-minute initialization window that opens each time Portainer starts. Any unauthenticated attacker with network access to a Portainer instance that has not yet been initialised can exploit this window to replace the Portainer database with a crafted archive containing attacker-controlled credentials and gain full administrative access. The same unauthenticated setup window also exposes the administrator-account-creation endpoint (/api/users/admin/init), which an attacker can call to create the first administrator directly; the fix gates both endpoints.

The attack requires the instance to be uninitialized, reachable by the attacker, and within the five-minute window. Once that window expires without initialization, Portainer locks its API and requires a restart to re-enable setup — each restart opens a fresh window. No credentials, session tokens, or local access are required.

Severity

High

The endpoint requires no authentication and no user interaction, but successful exploitation depends on three conditions holding simultaneously: the instance must be uninitialized, reachable from the attacker's network, and within the five-minute setup window that Portainer enforces before locking the instance pending a restart. Once those conditions are met, the attack itself is straightforward — no specialized tooling or elevated privileges are needed. The vulnerable system impact is limited by the precondition: a brand new instance carries no confidential data, no existing users, and no running workloads, so the direct integrity and availability impact is low. The severity is driven entirely by the subsequent-system chain — Portainer CE is typically bound to a Docker socket that grants root-equivalent access to the host, and the compromised admin account inherits credentials and API access for every Docker host, Kubernetes cluster, and edge agent registered in the instance.

Affected Versions

The unauthenticated initialization path has been present since the backup/restore feature was introduced.

Fixes are included in the following releases:

Branch First vulnerable Fixed in

2.39.x (LTS) 2.39.0 2.39.4

2.43.x (STS) all prior 2.43.0

Portainer releases prior to 2.39.0 are end-of-life and will not receive a fix. This includes the 2.33.x LTS line. Users on end-of-life versions should upgrade to a supported branch.

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)