Portainer a publié la version 2.45.0 le 27 août 2026 à 04h25 UTC, poussée par le compte portainer-bot depuis un commit signé et vérifié par GitHub (d79ba72), avec un tag « Latest » sur le dépôt. C’est la première version bâtie sur une nouvelle base Long Term Support (LTS), qui succède à la lignée 2.39.x dont la mise à jour 2.39.6 avait été traitée ici le 18 août. Le changelog officiel décrit 2.45.0 comme une version qui « reprend les travaux des versions STS 2.40 à 2.44 » : plusieurs mois de correctifs Short Term Support arrivent d’un coup dans une base LTS que les environnements de production, plus prudents dans leurs mises à jour, peuvent enfin adopter.
Ce regroupement apporte une série de correctifs d’autorisation dans le code propre de Portainer, une longue liste de mises à jour de dépendances qui referment des CVE tierces, et quelques nouveautés côté Kubernetes. Aucune des failles corrigées dans le code de Portainer lui-même ne porte de numéro CVE dédié, et rien dans le changelog ne mentionne une exploitation active. Une distinction à garder en tête pour la suite.
Une faille critique de contournement du proxy Docker
Le correctif le plus sérieux referme une brèche dans la façon dont Portainer autorise les requêtes adressées à l’API Docker via son proxy. Les préfixes de version d’API Docker que Portainer ne reconnaissait pas, par exemple /v1.47.0/ ou /v01.47/, échappaient totalement au contrôle d’autorisation au lieu d’être rejetés. Un utilisateur non-administrateur pouvait ainsi atteindre directement l’API Docker, en habillant simplement sa requête d’un préfixe de version que le proxy ne savait pas interpréter. Aucun numéro de CVE n’est associé à cette faille.
Une faille d’autorisation sur le shell Kubernetes
Une seconde faille touchait le shell Kubernetes sur les environnements gérés par agent. Des paramètres de requête fournis par l’appelant pouvaient outrepasser le pod réellement ciblé par le serveur, ce qui permettait à un utilisateur standard d’ouvrir un shell vers n’importe quel pod du cluster, pas seulement ceux qu’il était autorisé à atteindre. Sur un environnement Kubernetes partagé, c’est toute la différence entre toucher sa propre charge de travail et toucher celle de tout le monde. Ce correctif ne porte lui non plus aucun numéro de CVE.
D’autres correctifs d’autorisation, sans numéro de CVE
Plusieurs correctifs d’autorisation plus modestes complètent le travail de sécurité réalisé dans le code propre de Portainer. Là encore, aucun n’a reçu d’identifiant CVE :
- Les restrictions de bind-mount pour les utilisateurs non-administrateurs, initialement corrigées pour CVE-2026-44849 (GHSA-5fxq-qcf3-244w), s’appliquent désormais aussi aux déploiements de stacks Compose et Swarm, refermant une brèche laissée ouverte par le correctif d’origine.
- Les endpoints Kubernetes à espace de noms unique vérifient l’autorisation propre au namespace de l’appelant, plutôt que de s’exécuter avec des droits d’administrateur.
- Les utilisateurs en lecture seule et Helpdesk ne peuvent plus consulter les données des secrets Kubernetes.
- Les utilisateurs standards ne peuvent plus gérer les accès aux registres.
- Les refus d’autorisation Kubernetes renvoient un code HTTP 403 au lieu d’une erreur 500 générique.
Les CVE appartiennent aux dépendances tierces, pas à Portainer
Les mises à jour de dépendances sont la véritable source de la plupart des CVE listées dans cette version, et elles concernent les bibliothèques utilisées par Portainer, pas son propre code. Go passe en version 1.26.6, qui corrige CVE-2026-39821, une faille critique notée CVSS 9.6 permettant à un nom d’hôte forgé de contourner la validation IDNA utilisée dans les contrôles d’accès basés sur le nom d’hôte. Cette même mise à jour de Go referme aussi CVE-2026-42505, CVE-2026-39822, CVE-2026-56862, CVE-2026-56860, CVE-2026-56859, CVE-2026-56858, CVE-2026-56853, CVE-2026-46600 et CVE-2026-33818.
Au-delà de la chaîne d’outils Go, oras-go passe en 2.6.2 (CVE-2026-50163), go-git en 5.19.2 (CVE-2026-71556, CVE-2026-71557), OpenTelemetry en 1.44.0 (CVE-2026-41178), et klauspost/compress en 1.18.7. L’image kubectl-shell embarque désormais libcurl 8.21.0-r0, qui referme à elle seule 17 CVE, ainsi que c-ares 1.34.8-r0 (CVE-2026-33630).
Nouveaux add-ons Kubernetes et contrôles de policy
Côté fonctionnalités, 2.45.0 introduit des add-ons Kubernetes installables : des paquets Helm qui se déploient dans le cluster Kubernetes local de Portainer, aux côtés de la plateforme elle-même. Plusieurs nouveaux types de policy apparaissent aussi : une policy de bannière, une policy de confirmation de changement personnalisée pour Docker comme pour Kubernetes, et des profils Pod Security Standards appliqués par namespace. Le drainage des nœuds Kubernetes gagne des options de purge plus avancées avec bascule d’agent. De nouvelles API natives de Portainer gèrent désormais l’écriture des secrets, configmaps, deployments et persistent volume claims, au lieu de relayer ces appels vers kube-apiserver. S’ajoutent un dry-run générique pour les manifestes Kubernetes, la possibilité de configurer les réglages Edge Compute dès l’installation ou via des options en ligne de commande, et des événements d’authentification qui journalisent la véritable IP cliente via X-Forwarded-For lorsqu’un proxy de confiance se trouve devant Portainer.
Quelques corrections de bugs à signaler
Supprimer une stack désinstalle désormais la release Helm sous-jacente au lieu de la laisser tourner. Les charges de travail des Edge stacks ne persistent plus sur Kubernetes une fois la stack elle-même supprimée. Et les identifiants de sauvegarde Azure Blob, qui échouaient auparavant à l’enregistrement, fonctionnent maintenant correctement.
Quelle branche est concernée, et faut-il migrer ?
Portainer fait tourner deux trains de publication. Les versions STS, la lignée 2.40 à 2.44, livrent des fonctionnalités plus rapidement et sont numérotées séparément de la LTS. 2.45.0 LTS est la branche plus lente dans laquelle ce travail STS vient se fondre, et elle succède à la lignée 2.39.x. Si vous faites tourner la LTS pour une cadence plus tranquille, 2.45.0 est la version qui vous est destinée. Le fait que la numérotation STS ait pris de l’avance ne signifie pas que vous avez pris du retard.
Aucun des correctifs d’autorisation évoqués ici ne porte de numéro de CVE, et Portainer n’en décrit aucun comme exploité. Mais le contournement du proxy Docker et la faille du shell Kubernetes sont deux brèches bien réelles qui laissaient des utilisateurs non-administrateurs atteindre des ressources auxquelles ils n’auraient pas dû avoir accès. Quiconque fait tourner Portainer avec plus d’un compte utilisateur, administrateur ou non, a une bonne raison de migrer vers 2.45.0.
Pour comprendre la place de Portainer dans une installation Docker auto-hébergée, notre fiche application Portainer détaille l’installation réelle de la Community Edition, la licence zlib sous laquelle il est vraiment publié, et le compromis du socket Docker à bien comprendre avant de le déployer. Nous avions aussi couvert la précédente mise à jour LTS dans « Portainer Docker 2.39.6 LTS : protection SSRF et correctif Swarm ».
Source : les notes de version de Portainer 2.45.0 sur GitHub.