Lire cet article en français : Portainer Docker 2.39.6 LTS : protection SSRF et correctif Swarm
Portainer shipped 2.39.6 on August 12, 2026 at 23:03 UTC, from signed commit 723d1a2, and GitHub has it tagged as Latest. This one is almost entirely a security and bug-fix release. There is no new dashboard and nothing new to click around in. What you get instead is a configurable SSRF protection mechanism, a path traversal fix in the Swarm compose deployer, and a long run of dependency bumps that clear out CVEs inherited from upstream libraries.
Worth stating up front, because release notes with this many CVE numbers in them tend to get read the wrong way: nothing in Portainer’s notes describes an attack seen in the wild, and the two fixes that belong to Portainer’s own code do not carry CVE identifiers at all. That distinction matters, and I come back to it below.
SSRF protection with an allowlist and three modes
The headline addition is a new mechanism for blocking server-side request forgery, with an allowlist you configure from Portainer’s settings. It runs in one of three modes: off, audit, or enforce.
SSRF is the class of bug where you trick a server into making a request on your behalf to somewhere it was never meant to reach. It matters more for Portainer than for a typical web app, because Portainer is built to fetch things: stack definitions from Git, registries, webhooks. A management plane sitting inside your network is a useful thing for an attacker to point back at your own internal services.
The three-mode design is the sensible way to ship something like this, and the names point the obvious way: audit lets you watch what the policy would catch before enforce starts actually catching it. Switching on a network allowlist in an environment nobody documented is how you break deployments at 2am, so if you run Portainer against an internal Git server or a registry on an odd hostname, spend a while in audit first.
Path traversal in the Swarm compose deployer
The second security fix is more concrete. In the Swarm compose deployer, the file paths used for configs and secrets could escape the project root. That is a path traversal, and in a component whose whole job is reading files off disk and handing them to a container, escaping the intended directory is precisely the thing you do not want it doing.
Portainer’s notes attach no CVE number to this one and say nothing about anyone having used it. If you deploy Swarm stacks that reference configs or secrets, this is the fix that should move 2.39.6 up your list.
One default changed: EdgeID is now server-enforced
Small change, easy to skim past. The EdgeID is now imposed by the server on an Edge agent’s first connection rather than taken from the agent. If you script your Edge onboarding, check that provisioning flow against the new behaviour before you update.
The CVE list is about dependencies, not about Portainer
Here is where these release notes are easy to misread. 2.39.6 pulls in a stack of dependency updates, and each one carries CVE numbers from the upstream project it came from. Those CVEs are not Portainer vulnerabilities. They are flaws in libraries and toolchains that Portainer compiles against, and bumping the dependency is how they stop being your problem.
The dependency updates in this release:
- Go toolchain 1.25.11 to 1.25.12 (CVE-2026-42505, CVE-2026-39822)
go-git/v5to 5.19.2 (CVE-2026-71556, CVE-2026-71557)oras-go/v2to 2.6.2 (CVE-2026-50163)otelto 1.44.0 (CVE-2026-41178)klauspost/compressto 1.18.7 (GHSA-259r-337f-4rfw)golang.org/x/netto 0.56.0 andgolang.org/x/textto 0.39.0 in the updater (CVE-2026-46600, CVE-2026-56852)containerdv1 to 1.7.33 (CVE-2026-53488, CVE-2026-47262)grpcto 1.82.1 (GHSA-hrxh-6v49-42gf)
So the accurate summary of 2.39.6 is this: two security improvements in Portainer’s own code, neither of them with a CVE assigned, plus routine hygiene on the dependency tree. Anyone telling you this release patches a dozen Portainer CVEs is reading the changelog wrong.
The bug fixes
The Swarm fixes are the ones most likely to have bitten you already. Creating a stack from a worker node was throwing “Invalid Swarm ID” or a 503, and starting or stopping a Swarm stack could fail with “This node is not a swarm manager”. Both are fixed, along with a forced re-pull of private Docker Hub images failing on Swarm stacks and image builds returning unauthorized when a private registry appeared in a FROM line.
Elsewhere: deleting a team was wrongly stripping a user’s direct access to an environment they had been granted individually, which is nasty precisely because it looks like somebody fat-fingered a config rather than like a bug. Kubernetes gets two fixes, with Ingress service ports no longer displaying as 0 and kubectl port-forward working again against Agent 2.35 and newer on older clusters.
Known issues Portainer flags
Two carry forward into this release. Async Edge environments can display an invalid update scheduling date. And Podman support remains limited: there is no automatic onboarding, and the supported configuration is CentOS 9 with Podman 5 in rootful mode. If Podman is your runtime, that constraint has not moved.
Which branch is this, and should you take it?
2.39.6 sits on the LTS branch. Portainer numbers its STS branch separately, currently 2.44, so seeing a higher number elsewhere does not mean you have fallen behind. If you deliberately chose LTS for a slower release cadence, this is the Portainer update you want and 2.44 is not.
Nothing in the notes is marked as breaking and the bug fixes are real, so this is a low-risk one to take. The only item worth a second look is the EdgeID default, and only if you automate Edge onboarding.
If you are new to why a management layer on top of containers became a thing people run at home, our piece on the history of Docker covers how the ecosystem got here, and our Portainer app profile walks through the install, the zlib licence, and what mounting the Docker socket actually exposes.
Sources: the Portainer 2.39.6 release notes on GitHub, and the Portainer release notes in the official documentation.