Dokploy CVE-2026 : mise à jour critique 0.29.13

Le 25 septembre 2026, deux advisories de sécurité ont été publiés simultanément pour Dokploy, l'outil de déploiement auto-hébergé alternatif à Heroku/Render. La combinaison des deux constitue la menace la plus grave qui ait touché l'écosystème des PaaS self-hosted en 2026 : aucun compte requis, root sur l'hôte en moins d'une minute, et la surface exposée est toute instance inférieure à la version 0.29.13.

CVE-2026-45631 (CVSS 10.0) porte sur un secret JWT hardcodé dans le code source. CVE-2026-72863 (CVSS 9.9) porte sur des handlers WebSocket qui authentifient sans autoriser. Pris séparément, chacun est déjà critique. Chaînés, ils forment une attaque complète : le premier fournit l'identité administrative, le second fournit l'exécution.

L'advisory GitHub GHSA-w3gm-rc4p-9rhj décrit une vulnérabilité de classe CWE-798 — utilisation d'identifiants hardcodés. Dokploy utilise la bibliothèque better-auth pour la gestion des sessions et des tokens JWT. Dans les versions 0.27.0 à 0.29.2 inclus, la valeur par défaut de la variable BETTER_AUTH_SECRET était laissée à better-auth-secret-123456789 dans le code source publié sur GitHub.

Cette valeur est celle qui signe tous les tokens JWT d'administration de Dokploy. Quiconque la connaît — et elle est publique depuis le premier commit de la version 0.27.0 — peut forger un token JWT valide avec les droits administrateur, sans disposer d'aucun compte sur l'instance cible. L'API admin de Dokploy accepte alors toutes les requêtes : lecture de l'ensemble des secrets de déploiement, exécution de commandes via l'API, modification des configurations de services.

Le score CVSS 10.0 est le maximum absolu de l'échelle. Il reflète l'absence totale de barrière : le vecteur est réseau, aucune interaction utilisateur n'est requise, aucune authentification préalable n'est nécessaire, et la confidentialité, l'intégrité et la disponibilité de l'hôte sont toutes compromises.

L'advisory GitHub GHSA-7r6p-v9gw-pwc8 décrit un contrôle d'accès insuffisant sur les handlers WebSocket exposant les terminaux Docker de Dokploy. La vulnérabilité est de classe CWE-285 — autorisation incorrecte.

Dokploy permet à chaque utilisateur d'accéder à un terminal interactif dans ses propres conteneurs via WebSocket. La vérification mise en place authentifiait l'utilisateur — elle confirmait la présence d'un token valide — mais n'autorisait pas : elle ne vérifiait pas que le service demandé appartient bien à l'utilisateur qui fait la demande. N'importe quel utilisateur avec un compte valide, même sans droits d'administration, pouvait donc ouvrir un terminal dans n'importe quel conteneur de n'importe quel autre utilisateur.

L'impact réel dépasse le conteneur lui-même. Dokploy s'exécute avec les droits root et monte le socket Docker de l'hôte (/var/run/docker.sock). Depuis un shell dans un conteneur, la commande docker run --rm -v /:/host alpine chroot /host sh donne un shell root sur le système de fichiers de l'hôte. Toutes les versions inférieures à 0.29.13 sont concernées.

La chaîne CVE-2026-45631 + CVE-2026-72863 constitue une attaque complète réalisable depuis n'importe quel réseau, sans compte préexistant, en deux étapes.

Étape 1 — Forger un token administrateur (CVE-2026-45631). L'attaquant connaît la valeur better-auth-secret-123456789 depuis le code source public. Il génère un JWT signé avec cette valeur, revendiquant le rôle admin. L'API Dokploy accepte ce token sans vérification supplémentaire. L'attaquant dispose maintenant d'un accès administrateur complet : liste de tous les services, secrets d'environnement, clés de déploiement.

Étape 2 — Accéder au terminal d'un conteneur (CVE-2026-72863). Avec son token admin forgé, l'attaquant ouvre une connexion WebSocket vers le terminal d'un conteneur arbitraire. La vérification d'autorisation absente laisse passer la requête. L'attaquant dispose d'un shell dans le conteneur.

Résultat — Root sur l'hôte. Dokploy tournant en root avec le socket Docker monté, l'attaquant pivote du conteneur vers l'hôte. L'ensemble du système de fichiers, les secrets de tous les projets hébergés, les clés SSH et les variables d'environnement de production sont accessibles. L'opération complète ne requiert aucune interaction de l'opérateur et aucun compte préexistant sur l'instance.

Avant de procéder à la mise à jour, évaluez précisément l'exposition de votre instance.

Vérifier la version installée : docker exec dokploy cat /app/package.json | grep '"version"'

Si la version affichée est inférieure à 0.29.13, votre instance est vulnérable à CVE-2026-72863. Si elle est comprise entre 0.27.0 et 0.29.2, elle est vulnérable aux deux CVEs simultanément.

Vérifier la valeur du secret JWT : grep BETTER_AUTH_SECRET /etc/dokploy/.env

Si la valeur est better-auth-secret-123456789 ou si la variable est absente, CVE-2026-45631 est activement exploitable sur votre instance, quelle que soit la version.

Vérifier l'exposition réseau : si votre interface Dokploy est accessible depuis Internet sans restriction d'IP (pare-feu, Cloudflare Access, VPN), la surface d'attaque est publique. Un attaquant n'a besoin d'aucun accès réseau préalable pour exploiter CVE-2026-45631.

La mise à jour corrige les deux CVEs. Ces mesures complémentaires réduisent la surface d'attaque résiduelle.

Restreindre l'accès réseau à l'interface Dokploy. L'interface d'administration de Dokploy n'a aucune raison d'être accessible depuis Internet. Limitez l'accès au port 3000 (ou au port que vous utilisez) aux seules IP de votre équipe via le pare-feu de l'hôte, ou placez Dokploy derrière un VPN. Un ufw deny 3000 suivi d'un ufw allow from <votre-ip> to any port 3000 est la mesure minimale.

Activer l'authentification multifacteur (MFA). Dokploy supporte le TOTP depuis la version 0.28.0. Activez-le pour tous les comptes d'administration.

Auditer les secrets d'environnement des projets. Dokploy stocke les variables d'environnement de vos applications. Si l'instance a été exposée pendant la fenêtre de vulnérabilité (versions 0.27.0 à 0.29.12), considérez que tous vos secrets de production ont pu être lus. Rotation recommandée pour les clés d'API, les tokens de base de données et les secrets d'application.

Socket Docker et principe de moindre privilège. Le socket Docker monté en volume est une surface d'attaque documentée et exploitée dans CVE-2026-72863. Dokploy en a besoin pour fonctionner, mais l'accès peut être restreint via des politiques Docker socket proxy comme Tecnativa/docker-socket-proxy pour limiter les opérations autorisées.

Ces deux vulnérabilités sont sérieuses, mais la réponse des mainteneurs de Dokploy mérite d'être prise en compte avant de tirer des conclusions sur la maturité du projet.

Les advisories ont été publiés le 25 septembre 2026. Le correctif pour CVE-2026-45631 était disponible en version 0.29.3, et le correctif pour CVE-2026-72863 en version 0.29.13 — les deux dans un délai raisonnable après divulgation responsable. Le projet maintient un programme de sécurité via GitHub Security Advisories, ce qui indique une maturité minimale en matière de gestion des vulnérabilités.

Dokploy est un projet jeune (première version stable en 2024) avec une adoption rapide : plus de 15 000 étoiles GitHub et un rythme de releases soutenu. La présence d'un secret hardcodé dans les versions initiales reflète une dette de sécurité typique des projets en phase de croissance rapide, où la facilité d'installation a primé sur la robustesse du durcissement par défaut.

Le projet reste un choix pertinent pour les équipes qui veulent un PaaS self-hosted accessible, à condition de suivre les mises à jour de sécurité et d'appliquer les mesures de durcissement décrites dans cet article.

Si ces vulnérabilités vous amènent à réévaluer votre choix de PaaS self-hosted, voici les alternatives actives sur le segment.

Coolify est l'alternative la plus proche en termes de fonctionnalités. Open source, maintenu activement, avec un modèle de sécurité plus mature sur la gestion des secrets (pas de valeur par défaut hardcodée documentée à ce jour). Son interface est plus complexe mais sa base de code est plus grande et plus auditée.

Caprover est une option éprouvée, plus ancienne et donc avec un historique de sécurité plus long. Il est moins actif en termes de nouvelles fonctionnalités mais plus stable.

Portainer avec des stacks Docker reste une approche valide pour les équipes qui n'ont pas besoin d'un PaaS complet. Portainer porte ses propres CVEs historiques — notamment sur l'escalade de privilèges via l'API Docker — mais la version 3.x a revu sa gestion des autorisations.

Quelle que soit l'alternative choisie, appliquer les mêmes mesures de durcissement (accès réseau restreint, MFA, rotation régulière des secrets) reste la ligne de base non négociable.

CVE-2026-45631 (CVSS 10.0) et CVE-2026-72863 (CVSS 9.9) se chaînent en une attaque sans compte vers root sur l'hôte. Toute instance Dokploy inférieure à 0.29.13 avec le secret par défaut better-auth-secret-123456789 est compromettable depuis n'importe quel réseau.

La correction requiert deux gestes distincts et tous deux obligatoires : la mise à jour vers la version 0.29.13 minimum (docker compose pull && docker compose up -d), et la régénération de BETTER_AUTH_SECRET dans le fichier .env (openssl rand -base64 48). L'un sans l'autre ne ferme qu'une moitié de la surface.

Après la mise à jour, restreignez l'accès réseau à l'interface d'administration, activez le MFA, et si l'instance a été exposée pendant la fenêtre de vulnérabilité, effectuez une rotation de tous les secrets d'application hébergés.