{"id":"CVE-2026-55761","aliases":["EUVD-2026-42297","GHSA-x626-fcwx-f5pc","GO-2026-6324","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"Portainer: Unauthenticated Restore Endpoint Allows Admin Takeover on Uninitialised Portainer Instances","description":"Portainer Community Edition is a lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments. In versions 2.39.0 through 2.39.3 and 2.40.0 until 2.43.0, unauthenticated restore and administrator initialization endpoints (/api/restore and /api/users/admin/init) remain accessible during the five-minute setup window for uninitialized instances, allowing a network attacker to restore a crafted backup or create the first administrator account and gain full administrative access. This issue is fixed in versions 2.39.4 and 2.43.0.","severity":{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00493,"percentile":0.42849,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-287"],"published":"2026-07-08T15:03:54Z","modified":"2026-10-28T02:30:58Z","fixes":[{"ecosystem":"Go","package":"github.com/portainer/portainer","fixed_in":["2.39.4","2.43.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/portainer/portainer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.39.0"},{"fixed":"2.39.4"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/portainer/portainer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.40.0"},{"fixed":"2.43.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/portainer/portainer","ranges":[{"type":"SEMVER","events":[{"introduced":"2.39.0"},{"fixed":"2.39.4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/portainer/portainer","ranges":[{"type":"SEMVER","events":[{"introduced":"2.40.0"},{"fixed":"2.43.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/portainer/portainer","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39}],"products":[{"vendor":"portainer","product":"portainer"}],"references":[{"url":"https://github.com/portainer/portainer/security/advisories/GHSA-x626-fcwx-f5pc","tags":["x_refsource_CONFIRM","Exploit","Mitigation","Vendor Advisory","advisory","web"]},{"url":"https://github.com/portainer/portainer/issues/2770","tags":["x_refsource_MISC","Issue Tracking","report","web"]},{"url":"https://github.com/portainer/portainer/commit/49f19107cf9a3540cbe406c9eb7f24390e1af02b","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/portainer/portainer/commit/d2b56efcb4e43c4168bb6688eee9f6bf22867312","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/portainer/portainer/releases/tag/2.39.4","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://github.com/portainer/portainer/releases/tag/2.43.0","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55761","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-x626-fcwx-f5pc"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55761.json","tags":["advisory"]},{"url":"https://github.com/portainer/portainer","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623692-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-20909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-22547","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24690","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25712","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25718","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26232","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26247","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26307","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27657","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27878","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28705","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54746","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54754","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54755","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55064","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55065","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55066","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55067","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55108","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55484","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55621","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55761","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55763","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55764","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55784","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55785","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55873","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55874","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56854","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78662","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623712-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-55761","title":"Portainer: Unauthenticated Restore Endpoint Allows Admin Takeover on Uninitialised Portainer Instances","description":"Portainer Community Edition is a lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments. In versions 2.39.0 through 2.39.3 and 2.40.0 until 2.43.0, unauthenticated restore and administrator initialization endpoints (/api/restore and /api/users/admin/init) remain accessible during the five-minute setup window for uninitialized instances, allowing a network attacker to restore a crafted backup or create the first administrator account and gain full administrative access. This issue is fixed in versions 2.39.4 and 2.43.0.","status":"published","published":"2026-07-08T15:03:54.158Z","modified":"2026-07-08T15:52:30.257Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H","level":"high","assessor":"cna"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T14:20:12.260247Z"}],"euvd":[{"id":"EUVD-2026-42297","description":"Portainer Community Edition is a lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments. In versions 2.39.0 through 2.39.3 and 2.40.0 until 2.43.0, unauthenticated restore and administrator initialization endpoints (/api/restore and /api/users/admin/init) remain accessible during the five-minute setup window for uninitialized instances, allowing a network attacker to restore a crafted backup or create the first administrator account and gain full administrative access. This issue is fixed in versions 2.39.4 and 2.43.0.","status":"published","published":"2026-07-08T15:03:54Z","modified":"2026-07-08T15:52:30Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H","level":"high"}],"updated_at":"2026-11-02T18:20:10.578977Z"}],"ghsa":[{"id":"GHSA-x626-fcwx-f5pc","title":"Portainer has Unauthenticated Restore Endpoint that Allows Admin Takeover on Uninitialized Instances","description":"## Summary\nPortainer 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.\n\nThe 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.\n\n## Severity\n**High**\n\nThe 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.\n\n## Affected Versions\n\nThe unauthenticated initialization path has been present since the backup/restore feature was introduced.\n\nFixes are included in the following releases:\n\n| Branch       | First vulnerable | Fixed in   |\n|--------------|------------------|------------|\n| 2.39.x (LTS) | 2.39.0           | **2.39.4** |\n| 2.43.x (STS) | all prior        | **2.43.0** |\n\nPortainer 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.\n\n## Workarounds\nAdministrators who cannot immediately upgrade can reduce exposure by:\n\n- **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.\n- **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.\n- **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.\n- **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.\n\nNone of these replace the fix.\n\n## Affected Code\nThe 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:\n\n```go\n// api/http/handler/backup/handler.go — NewHandler\nh.Handle(\"/restore\", bouncer.PublicAccess(httperror.LoggerHandler(h.restore))).Methods(http.MethodPost)\n```\n\nThe restore handler then checks only whether the instance has been initialised before proceeding:\n\n```go\n// api/http/handler/backup/restore.go — restore\nfunc (h *Handler) restore(w http.ResponseWriter, r *http.Request) *httperror.HandlerError {\n    initialized, err := h.adminMonitor.WasInitialized()\n    if err != nil {\n        return httperror.InternalServerError(\"Failed to check system initialization\", err)\n    }\n    if initialized {\n        return httperror.BadRequest(\"Cannot restore already initialized instance\", errors.New(\"system already initialized\"))\n    }\n    h.adminMonitor.Stop()\n    // Proceeds to restore the archive unconditionally\n```\n\nThe 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.\n\n## Impact\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Timeline\n- 2026-05-07: Reported privately by **um3b0shi**.\n- 2026-06-04: Fix merged to `develop`.\n- 2026-06-24: 2.43.0 (STS) released with the fix.\n- 2026-06-25: 2.39.4 (LTS) released with the backported fix.\n\n## Credit\n- **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.","status":"published","published":"2026-08-28T20:28:19Z","modified":"2026-08-28T20:28:20Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H","level":"high"},{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T14:41:08.084849Z"}],"nvd":[{"id":"CVE-2026-55761","description":"Portainer Community Edition is a lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments. In versions 2.39.0 through 2.39.3 and 2.40.0 until 2.43.0, unauthenticated restore and administrator initialization endpoints (/api/restore and /api/users/admin/init) remain accessible during the five-minute setup window for uninitialized instances, allowing a network attacker to restore a crafted backup or create the first administrator account and gain full administrative access. This issue is fixed in versions 2.39.4 and 2.43.0.","status":"published","published":"2026-07-08T16:16:31.02Z","modified":"2026-07-10T17:48:26.79Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T14:12:28.040501Z"}],"osv":[{"id":"CVE-2026-55761","title":"Portainer: Unauthenticated Restore Endpoint Allows Admin Takeover on Uninitialised Portainer Instances","description":"Portainer Community Edition is a lightweight service delivery platform for containerized applications that can be used to manage Docker, Swarm, Kubernetes and ACI environments. In versions 2.39.0 through 2.39.3 and 2.40.0 until 2.43.0, unauthenticated restore and administrator initialization endpoints (/api/restore and /api/users/admin/init) remain accessible during the five-minute setup window for uninitialized instances, allowing a network attacker to restore a crafted backup or create the first administrator account and gain full administrative access. This issue is fixed in versions 2.39.4 and 2.43.0.","status":"published","published":"2026-07-08T15:03:54.158Z","modified":"2026-10-28T02:30:58.523124985Z","cvss":[{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H","level":"high"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T15:45:11.22012Z"},{"id":"GHSA-x626-fcwx-f5pc","title":"Portainer has Unauthenticated Restore Endpoint that Allows Admin Takeover on Uninitialized Instances","description":"## Summary\nPortainer 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.\n\nThe 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.\n\n## Severity\n**High**\n\nThe 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.\n\n## Affected Versions\n\nThe unauthenticated initialization path has been present since the backup/restore feature was introduced.\n\nFixes are included in the following releases:\n\n| Branch       | First vulnerable | Fixed in   |\n|--------------|------------------|------------|\n| 2.39.x (LTS) | 2.39.0           | **2.39.4** |\n| 2.43.x (STS) | all prior        | **2.43.0** |\n\nPortainer 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.\n\n## Workarounds\nAdministrators who cannot immediately upgrade can reduce exposure by:\n\n- **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.\n- **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.\n- **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.\n- **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.\n\nNone of these replace the fix.\n\n## Affected Code\nThe 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:\n\n```go\n// api/http/handler/backup/handler.go — NewHandler\nh.Handle(\"/restore\", bouncer.PublicAccess(httperror.LoggerHandler(h.restore))).Methods(http.MethodPost)\n```\n\nThe restore handler then checks only whether the instance has been initialised before proceeding:\n\n```go\n// api/http/handler/backup/restore.go — restore\nfunc (h *Handler) restore(w http.ResponseWriter, r *http.Request) *httperror.HandlerError {\n    initialized, err := h.adminMonitor.WasInitialized()\n    if err != nil {\n        return httperror.InternalServerError(\"Failed to check system initialization\", err)\n    }\n    if initialized {\n        return httperror.BadRequest(\"Cannot restore already initialized instance\", errors.New(\"system already initialized\"))\n    }\n    h.adminMonitor.Stop()\n    // Proceeds to restore the archive unconditionally\n```\n\nThe 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.\n\n## Impact\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Timeline\n- 2026-05-07: Reported privately by **um3b0shi**.\n- 2026-06-04: Fix merged to `develop`.\n- 2026-06-24: 2.43.0 (STS) released with the fix.\n- 2026-06-25: 2.39.4 (LTS) released with the backported fix.\n\n## Credit\n- **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.","status":"published","published":"2026-08-28T20:28:19Z","modified":"2026-09-02T19:55:44.93768057Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"},{"version":"4.0","score":7.1,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H","level":"high"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T15:46:59.484835Z"},{"id":"GO-2026-6324","title":"Portainer has Unauthenticated Restore Endpoint that Allows Admin Takeover on Uninitialized Instances in github.com/portainer/portainer","description":"Portainer has Unauthenticated Restore Endpoint that Allows Admin Takeover on Uninitialized Instances in github.com/portainer/portainer.\n\nNOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.\n\n(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)\n\nThe additional affected modules and versions are: github.com/portainer/portainer from v2.39.0 before v2.39.4, from v2.40.0 before v2.43.0.","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:45:12.634762853Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"openSUSE-SU-2026:21812-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:52:09Z","modified":"2026-09-10T18:23:18.964541257Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:23692-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.31116925Z","updated_at":"2026-11-02T15:54:03.991985Z"},{"id":"SUSE-SU-2026:23712-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.805639295Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}