CVE-2026-55761

CVE-2026-55761 is a high-severity improper authentication vulnerability in github.com/portainer/portainer (go), affecting versions >= 2.39.0, < 2.39.4. It is fixed in 2.39.4, 2.43.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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)

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.

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.

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.

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

CVE-2026-55761 has a CVSS score of 5.9 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.39.4, 2.43.0); upgrading removes the vulnerable code path.

Affected versions

github.com/portainer/portainer (>= 2.39.0, < 2.39.4) github.com/portainer/portainer (>= 2.40.0, < 2.43.0)

Security releases

github.com/portainer/portainer → 2.39.4 (go) github.com/portainer/portainer → 2.43.0 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

github.com/portainer/portainer to 2.39.4 or later; github.com/portainer/portainer to 2.43.0 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-55761? CVE-2026-55761 is a high-severity improper authentication vulnerability in github.com/portainer/portainer (go), affecting versions >= 2.39.0, < 2.39.4. It is fixed in 2.39.4, 2.43.0. The application does not adequately verify the identity of a user, device, or process before granting access.
  2. How severe is CVE-2026-55761? CVE-2026-55761 has a CVSS score of 5.9 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of github.com/portainer/portainer are affected by CVE-2026-55761? github.com/portainer/portainer (go) versions >= 2.39.0, < 2.39.4 is affected.
  4. Is there a fix for CVE-2026-55761? Yes. CVE-2026-55761 is fixed in 2.39.4, 2.43.0. Upgrade to this version or later.
  5. Is CVE-2026-55761 exploitable, and should I be worried? Whether CVE-2026-55761 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-55761 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-55761?
    • Upgrade github.com/portainer/portainer to 2.39.4 or later
    • Upgrade github.com/portainer/portainer to 2.43.0 or later

Other vulnerabilities in github.com/portainer/portainer

Stop the waste.
Protect your environment with Kodem.