Portainer shipped 2.45.0 on August 27, 2026 at 04:25 UTC, pushed by the portainer-bot account from signed, GitHub-verified commit d79ba72, with the release tagged “Latest” on the repository. It’s the first release on a new Long Term Support base, and it succeeds the 2.39.x LTS line whose 2.39.6 update we covered here on August 18. Portainer’s own changelog describes 2.45.0 as a release that “rolls up work from the 2.40 to 2.44 STS releases.” In plain terms, several months of Short Term Support work now ship together in one LTS base that slower-moving production environments can move to.
That rollup brings a set of authorization fixes in Portainer’s own code, a long list of dependency updates that close third-party CVEs, and a handful of new Kubernetes features. None of the fixes in Portainer’s own code carry a dedicated CVE identifier, and nothing in the changelog points to any of them being exploited in the wild. That distinction is worth keeping in mind while reading through the list below.
A critical Docker proxy authorization bypass
The most serious fix closes a hole in how Portainer authorizes requests to the Docker API through its proxy. Docker API version prefixes that Portainer didn’t recognize, things like /v1.47.0/ or /v01.47/, skipped the authorization check entirely instead of being rejected. That let non-admin users reach the Docker API directly, just by dressing up a request in a version prefix Portainer’s proxy couldn’t parse. No CVE number is attached to this one.
A Kubernetes shell authorization flaw
A separate flaw hit the Kubernetes shell feature on agent-managed environments. Query parameters supplied by the caller could override the pod the server actually meant to target, which meant a standard user could open a shell into any pod in the cluster, not just the ones they were authorized to reach. On a shared Kubernetes environment, that’s the whole difference between a user touching their own workload and touching everyone else’s. This fix carries no CVE number either.
More authorization fixes, none with a CVE number
Several smaller authorization fixes round out the security work in Portainer’s own code. Again, none of them were assigned a CVE identifier:
- Bind-mount restrictions for non-admin users, originally patched for CVE-2026-44849 (GHSA-5fxq-qcf3-244w), now also apply to Compose and Swarm stack deployments, closing a gap the original fix left open.
- Single-namespace Kubernetes endpoints now check the caller’s own namespace authorization instead of running with admin rights.
- Read-only and Helpdesk users can no longer view Kubernetes secrets data.
- Standard users can no longer manage registry access.
- Kubernetes authorization denials now return HTTP 403 instead of a generic 500 error.
The CVE list belongs to third-party dependencies, not Portainer
The dependency updates are where most of the CVE numbers in this release actually come from, and they belong to the libraries Portainer builds against, not to Portainer’s own code. Go was updated to 1.26.6, which fixes CVE-2026-39821, a Critical-severity, CVSS 9.6 flaw that let a crafted hostname bypass IDNA validation used in hostname-based access controls. The same Go update also covers CVE-2026-42505, CVE-2026-39822, CVE-2026-56862, CVE-2026-56860, CVE-2026-56859, CVE-2026-56858, CVE-2026-56853, CVE-2026-46600, and CVE-2026-33818.
Beyond the Go toolchain, oras-go moved to 2.6.2 (CVE-2026-50163), go-git to 5.19.2 (CVE-2026-71556, CVE-2026-71557), OpenTelemetry to 1.44.0 (CVE-2026-41178), and klauspost/compress to 1.18.7. The kubectl-shell image picks up libcurl 8.21.0-r0, which alone closes 17 CVEs, plus c-ares 1.34.8-r0 (CVE-2026-33630).
New Kubernetes add-ons and policy controls
Away from security, 2.45.0 adds installable Kubernetes add-ons: Helm-based packages that deploy into Portainer’s local Kubernetes cluster alongside the platform itself. A few new policy types join the mix too: a Banner policy, a Custom Change Confirmation policy for both Docker and Kubernetes, and Pod Security Standards profiles applied per namespace. Kubernetes node draining gets more advanced purge options with agent failover. New native Portainer APIs now handle writing secrets, configmaps, deployments, and persistent volume claims, instead of proxying those calls straight through to kube-apiserver. There’s also a generic dry-run for Kubernetes manifests, Edge Compute settings can now be configured at initial install and via CLI flags, and authentication events log the real client IP through X-Forwarded-For when a trusted proxy sits in front of Portainer.
A few bug fixes worth noting
Removing a stack now uninstalls its underlying Helm release instead of leaving it running. Edge stack workloads no longer linger on Kubernetes after the stack itself gets deleted. And Azure Blob backup credentials that previously failed to save now do.
Which branch is this, and should you take it?
Portainer runs two release trains. STS releases, the 2.40 through 2.44 line, ship features faster and are numbered separately from LTS. 2.45.0 LTS is the slower-moving branch that this STS work rolls into, and it succeeds 2.39.x. If you deliberately run LTS for a calmer update cadence, 2.45.0 is the release meant for you. STS numbering running ahead of it doesn’t mean you’ve fallen behind.
None of the authorization fixes here carry a CVE number, and Portainer doesn’t describe any of them as exploited. But the Docker proxy bypass and the Kubernetes shell flaw are both real gaps that let non-admin users reach things they shouldn’t. Anyone running Portainer with more than one user account, admin or not, has a reason to move to 2.45.0.
For background on how Portainer fits into a self-hosted Docker setup, our Portainer app profile covers the Community Edition install, the zlib license it actually ships under, and the Docker socket trade-off worth understanding before you deploy it. We also covered the previous LTS update in Portainer 2.39.6 LTS Adds SSRF Protection and a Swarm Path Traversal Fix.
Source: the Portainer 2.45.0 release notes on GitHub.