Portainer Docker 2.39.6 LTS : protection SSRF et correctif Swarm

Read this article in English: Portainer Update 2.39.6 LTS Adds SSRF Protection and a Swarm Path Traversal Fix

Portainer a publié la version 2.39.6 le 12 août 2026 à 23h03 UTC, depuis le commit signé 723d1a2, et GitHub la marque comme Latest. C’est une version presque entièrement consacrée à la sécurité et aux corrections de bugs. Pas de nouveau tableau de bord, rien de neuf à cliquer. À la place, vous récupérez un mécanisme de protection SSRF configurable, un correctif de traversée de répertoire (path traversal) dans le déployeur compose de Swarm, et une longue série de montées de version sur les dépendances qui évacuent des CVE héritées de bibliothèques tierces.

Autant le dire tout de suite, parce que des notes de version bourrées de numéros de CVE se lisent souvent de travers : rien chez Portainer ne décrit une exploitation observée dans la nature, et les deux correctifs qui relèvent du code de Portainer lui-même ne portent aucun identifiant CVE. La distinction compte, et j’y reviens plus bas.

Protection SSRF : une liste blanche et trois modes

L’ajout principal est un mécanisme de blocage des attaques SSRF (server-side request forgery), avec une liste blanche que l’on configure depuis les réglages de Portainer. Il fonctionne selon trois modes : off, audit ou enforce.

Une faille SSRF, c’est la catégorie de bug où l’on piège un serveur pour qu’il émette une requête à votre place, vers un endroit qu’il n’aurait jamais dû atteindre. Le sujet est plus sensible pour Portainer que pour une application web ordinaire, parce que Portainer est justement conçu pour aller chercher des choses ailleurs : des définitions de stack sur Git, des registres, des webhooks. Un plan de gestion posé au milieu de votre réseau est une cible commode pour qui veut le retourner contre vos propres services internes.

Le découpage en trois modes est la bonne manière de livrer ce genre de fonctionnalité, et les noms parlent d’eux-mêmes : audit vous laisse observer ce que la politique attraperait avant qu’enforce ne se mette à l’attraper pour de bon. Activer une liste blanche réseau dans un environnement que personne n’a jamais documenté, c’est la recette pour casser ses déploiements à 2 h du matin. Si votre Portainer tape sur un serveur Git interne ou sur un registre au nom d’hôte exotique, restez un moment en audit.

Traversée de répertoire dans le déployeur compose de Swarm

Le second correctif de sécurité est plus concret. Dans le déployeur compose de Swarm, les chemins de fichiers utilisés pour les configs et les secrets pouvaient sortir de la racine du projet. C’est une traversée de répertoire, et dans un composant dont tout le métier consiste à lire des fichiers sur le disque pour les passer à un conteneur, sortir du dossier prévu est exactement ce qu’on ne veut pas le voir faire.

Portainer n’attache aucun numéro de CVE à ce correctif et ne mentionne personne qui s’en serait servi. Si vous déployez des stacks Swarm qui référencent des configs ou des secrets, c’est ce point-là qui doit faire remonter 2.39.6 dans votre liste.

Un comportement par défaut change : l’EdgeID est imposé par le serveur

Petit changement, facile à survoler. L’EdgeID est désormais imposé par le serveur lors de la première connexion d’un agent Edge, au lieu d’être repris de l’agent. Si vous scriptez l’enrôlement de vos agents Edge, confrontez ce flux de provisioning au nouveau comportement avant de mettre à jour.

La liste de CVE concerne les dépendances, pas Portainer

C’est ici que ces notes de version se lisent le plus facilement de travers. La 2.39.6 embarque une pile de mises à jour de dépendances, et chacune traîne derrière elle les numéros de CVE du projet amont dont elle provient. Ces CVE ne sont pas des vulnérabilités de Portainer. Ce sont des défauts dans des bibliothèques et des chaînes d’outils avec lesquelles Portainer est compilé, et monter la dépendance de version est précisément la manière de faire en sorte qu’elles cessent d’être votre problème.

Les dépendances mises à jour dans cette version :

• chaîne d’outils Go 1.25.11 vers 1.25.12 (CVE-2026-42505, CVE-2026-39822)
• go-git/v5 vers 5.19.2 (CVE-2026-71556, CVE-2026-71557)
• oras-go/v2 vers 2.6.2 (CVE-2026-50163)
• otel vers 1.44.0 (CVE-2026-41178)
• klauspost/compress vers 1.18.7 (GHSA-259r-337f-4rfw)
• golang.org/x/net vers 0.56.0 et golang.org/x/text vers 0.39.0 dans l’updater (CVE-2026-46600, CVE-2026-56852)
• containerd v1 vers 1.7.33 (CVE-2026-53488, CVE-2026-47262)
• grpc vers 1.82.1 (GHSA-hrxh-6v49-42gf)

Le résumé exact de la 2.39.6 tient donc en peu de mots : deux améliorations de sécurité dans le code propre à Portainer, aucune des deux avec un CVE attribué, plus de l’hygiène de routine sur l’arbre de dépendances. Si quelqu’un vous explique que cette version corrige une douzaine de CVE Portainer, il lit mal le changelog.

Les corrections de bugs

Les correctifs Swarm sont ceux qui vous ont le plus probablement déjà mordu. Créer une stack depuis un nœud worker renvoyait « Invalid Swarm ID » ou une erreur 503, et démarrer ou arrêter une stack Swarm pouvait échouer sur « This node is not a swarm manager ». Les deux sont réglés, tout comme le re-pull forcé d’images Docker Hub privées qui échouait sur les stacks Swarm, et les builds d’image qui renvoyaient unauthorized dès qu’un registre privé apparaissait dans une ligne FROM.

Ailleurs, supprimer une équipe retirait à tort à un utilisateur son accès direct à un environnement qui lui avait été accordé individuellement. Celui-là est vicieux, précisément parce qu’il ressemble à une config mal saisie plutôt qu’à un bug. Kubernetes récupère deux correctifs : les ports de service Ingress ne s’affichent plus à 0, et kubectl port-forward refonctionne avec l’Agent 2.35 et plus récent sur les clusters anciens.

Les problèmes connus signalés par Portainer

Deux se reportent sur cette version. Les environnements Edge en mode asynchrone peuvent afficher une date de planification de mise à jour invalide. Et le support de Podman reste limité : pas d’enrôlement automatique, et la configuration supportée se résume à CentOS 9 avec Podman 5 en mode rootful. Si Podman est votre runtime, cette contrainte n’a pas bougé.

LTS ou STS : faut-il prendre cette version ?

La 2.39.6 se situe sur la branche LTS. Portainer numérote sa branche STS à part, actuellement en 2.44 : croiser un numéro plus élevé ailleurs ne veut donc pas dire que vous avez pris du retard. Si vous avez délibérément choisi la LTS pour un rythme de sorties plus lent, c’est cette mise à jour de Portainer qu’il vous faut, pas la 2.44.

Rien dans les notes n’est marqué comme cassant et les corrections de bugs sont réelles, donc la mise à jour est peu risquée. Le seul point qui mérite un second regard, c’est le changement sur l’EdgeID, et seulement si vous automatisez l’enrôlement de vos agents Edge.

Si vous découvrez seulement maintenant pourquoi une couche de gestion posée au-dessus des conteneurs est devenue un truc qu’on installe chez soi, notre article sur l’histoire de Docker retrace comment l’écosystème en est arrivé là. Et pour Portainer lui-même, notre fiche Portainer détaille l’installation, la licence zlib et ce que le montage du socket Docker expose réellement.

Sources : les notes de version de Portainer 2.39.6 sur GitHub, et les notes de version Portainer dans la documentation officielle.