L’essentiel
CVE-2026-49869 est un contournement d’authentification noté CVSS 10.0 dans Kestra OSS, qui offre à un attaquant non authentifié une exécution de code à distance en root. L’exception prévue pour l’endpoint public de configuration ne vérifie que la fin du chemin — endsWith("/configs") — : toute requête dont le chemin se termine par configs échappe donc à la Basic Auth. L’attaquant peut ensuite créer et lancer, dans le conteneur worker, un workflow contenant des tâches shell ou Python. La CISA l’a ajoutée au catalogue KEV le 2 septembre 2026.
Si Kestra se trouve quelque part dans votre pipeline de données : passez dès maintenant en 1.3.21 ou 1.0.45 et retirez d’Internet toute instance exposée. Les hôtes d’orchestration sont des cibles de choix parce qu’ils détiennent les clés de tout ce qu’ils automatisent — ce dossier relève du même niveau d’urgence que votre réponse à incident cloud et DevOps.
En quoi consiste exactement la faille
Kestra est un orchestrateur open source piloté par événements, utilisé pour construire et planifier des pipelines de données et des workflows d’automatisation — le type d’outil qui tourne discrètement au cœur d’une plateforme data et déclenche tout le reste. Comme beaucoup d’outils de ce genre, il est livré avec la Basic Auth activée par défaut et un unique endpoint public, la configuration de l’instance, censé être accessible sans connexion. Le bug réside dans la manière dont cette exception est appliquée.
L’AuthenticationFilter décide d’exiger ou non des identifiants en appelant request.getPath().endsWith("/configs"). Il s’agit d’une comparaison par suffixe, pas d’une correspondance exacte : elle n’exempte pas seulement l’endpoint /configs prévu, mais tout chemin d’API dont le dernier segment est configs. Il suffit à l’attaquant d’ajouter ce segment à une route protégée pour passer l’authentification. Une fois à l’intérieur, il peut créer un flow Kestra contenant des tâches de script — shell, Python, Node, Bash — et l’exécuter ; ces tâches tournent en root dans le conteneur worker Linux. C’est une exécution de code à distance sur l’hôte d’orchestration, sans identifiants ni interaction utilisateur.
L’avis de sécurité décrit aussi une falsification de requête côté serveur (SSRF) : la fonction http() du moteur de templates Pebble ne filtre aucune URI, si bien qu’un template forgé peut appeler des services internes ou l’endpoint de métadonnées du fournisseur cloud. Sur une instance hébergée dans le cloud, c’est un accès direct aux identifiants de l’instance et au mouvement latéral. Le contournement noté CVSS 10.0 fait les gros titres, mais c’est la SSRF qui transforme la compromission d’un hôte en compromission de tout l’environnement.
Pourquoi les plateformes d’orchestration sont sans cesse visées
Ce n’est pas un problème isolé de Kestra, mais le dernier épisode d’une série de failles critiques dans les plateformes de workflow et d’automatisation. n8n, Langflow, MLflow et des outils similaires ont tous connu au cours de l’année écoulée des RCE sans authentification ou par contournement d’authentification. Le phénomène est structurel : ces plateformes existent pour exécuter du code arbitraire et atteindre tout ce qu’elles automatisent. Elles accumulent donc, par conception, identifiants de bases de données, clés cloud, jetons d’API et accès au réseau interne. Une seule faille d’authentification sur un tel hôte ne compromet pas un serveur : elle ouvre une tête de pont vers les pipelines, les entrepôts de données et les comptes cloud qui se trouvent derrière.
Elles restent aussi facilement exposées. Ces outils commencent comme une commodité interne, reçoivent une URL publique pour une démo rapide ou un collègue en télétravail, puis restent accessibles. « Exécute du code par conception », « détient tous les secrets » et « parfois sur l’Internet ouvert » : c’est exactement le profil que recherchent les attaquants. Toute équipe qui exploite une plateforme data — en particulier celles qui montent rapidement des pipelines data et ML — devrait traiter chaque orchestrateur et serveur d’automatisation comme une infrastructure de premier rang, parce que c’est ainsi que les attaquants le traitent.
Ce que cela change pour les équipes en France
La conséquence immédiate est opérationnelle : une inscription au KEV assortie d’une preuve de concept publique signifie que l’exploitation n’a rien d’hypothétique, et les instances non corrigées accessibles depuis Internet doivent être considérées comme compromises. L’échéance de la CISA ne s’impose qu’aux agences fédérales américaines, mais le signal — « c’est utilisé dans des attaques en ce moment » — vaut pour tout le monde. Si vous ne pouvez pas démontrer que votre instance Kestra a été corrigée avant d’être exposée, la bonne posture est la réponse à incident, pas une simple mise à jour : renouvelez les secrets et analysez les journaux.
Pour les organisations régulées s’ajoute la dimension conformité. Au titre de NIS2, de DORA pour le secteur financier, ou d’un audit ISO 27001, une vulnérabilité connue et exploitée sur un système qui touche des données de production est exactement le type de constat que l’auditeur ou le régulateur s’attend à voir détecté et corrigé dans un délai défini. Si des données personnelles ont pu être extraites via une instance compromise, l’article 33 du RGPD impose en outre une notification à la CNIL dans les 72 heures. Les organisations qui s’en sortent proprement sont celles qui peuvent présenter un inventaire, un historique de correctifs et un journal de rotation des identifiants — pas celles qui découvrent des semaines plus tard que l’outil faisait partie du parc.
La leçon de fond concerne la chaîne d’approvisionnement logicielle. La plupart des équipes n’ont pas écrit Kestra, mais elles portent le risque de l’exploiter. L’infrastructure open source auto-hébergée échange la dépendance à un fournisseur contre l’obligation de suivre les avis de sécurité et de corriger vite. C’est un coût réel, qui doit être budgété comme tel : quelqu’un doit tenir l’inventaire de ce que vous hébergez, s’abonner aux avis de sécurité et pouvoir corriger en quelques heures lorsqu’un CVSS 10.0 arrive au KEV.
Que faire dès maintenant
Si Kestra est présent dans votre stack, l’ordre des étapes compte plus que chaque étape prise isolément.
- Vérifier si vous utilisez Kestra, et en quelle version. Contrôlez les images de conteneurs, les charts Helm et les déploiements auto-hébergés ; les versions concernées vont jusqu’à la 1.3.20 incluse.
- Mettre à jour immédiatement. Passez en 1.3.21, 1.0.45 ou toute version 1.4.0+. Aucun contournement durable ne permet de laisser une version vulnérable exposée.
- Retirer l’instance d’Internet. Placez toute instance exposée derrière un VPN ou sur un réseau privé ; un orchestrateur ne devrait presque jamais être directement accessible depuis le Web.
- Renouveler chaque secret accessible. Considérez comme exposés les identifiants de bases de données, clés cloud et jetons d’API que l’instance pouvait atteindre, et renouvelez-les — la SSRF rend cette étape obligatoire sur les hôtes cloud.
- Rechercher les abus. Analysez les journaux à la recherche de créations ou d’exécutions de flows inattendues, et de requêtes sortantes vers les endpoints de métadonnées, autour et avant la date du correctif.
- Intégrer l’outil à votre veille. Assurez-vous que cette plateforme et vos autres outils auto-hébergés figurent dans un flux surveillé, pour que la prochaine entrée au KEV ne vous prenne pas au dépourvu.
Ceci ne constitue pas un conseil juridique, et votre exposition réelle dépend de la façon dont Kestra est déployé chez vous. Mais la direction est sans ambiguïté : un contournement d’authentification CVSS 10.0 sur un hôte qui exécute du code et détient des secrets, désormais au KEV, se corrige aujourd’hui — et les équipes qui savent déjà ce qu’elles hébergent le referment en quelques heures plutôt qu’en quelques semaines.
Questions fréquentes
Qu’est-ce que la CVE-2026-49869 dans Kestra ?
Un contournement d’authentification noté CVSS 10.0 dans Kestra OSS. L’AuthenticationFilter autorise l’endpoint public de configuration via une vérification par suffixe, request.getPath().endsWith("/configs"), au lieu d’une correspondance exacte. Tout chemin d’API dont le dernier segment est configs échappe donc à la Basic Auth : un attaquant non authentifié atteint les endpoints protégés, crée un workflow avec des tâches de script et l’exécute en root dans le conteneur worker.
Quelles versions de Kestra sont concernées et lesquelles corrigent la faille ?
Sont concernées les versions de Kestra OSS jusqu’à la 1.3.20 incluse avec la Basic Auth activée, c’est-à-dire la configuration par défaut. La faille est corrigée dans les versions 1.0.45, 1.3.21 et toutes les versions 1.4.0 et ultérieures. La mise à jour est la mesure principale ; aucun contournement sûr ne permet de laisser une version vulnérable exposée.
La CVE-2026-49869 est-elle exploitée ?
La CISA l’a inscrite à son catalogue KEV le 2 septembre 2026 – signe qu’il existe des preuves fiables d’exploitation active –, avec une échéance au 5 septembre pour les agences fédérales civiles américaines. Une preuve de concept publique et un scanner existent : toute instance non corrigée accessible depuis Internet doit être considérée comme compromise jusqu’à preuve du contraire.
Que peut faire un attaquant après l’exploitation ?
Créer et lancer des workflows Kestra avec des tâches shell, Python, Node ou Bash, exécutées en root dans le conteneur worker – soit une exécution de code à distance complète sur l’hôte d’orchestration. Une SSRF secondaire via la fonction Pebble http(), qui ne filtre pas les URI, peut viser les métadonnées cloud ou des services internes pour voler des identifiants et progresser latéralement.
Quelles obligations de notification peuvent s’appliquer en France ?
Si des données personnelles ont pu être extraites via une instance compromise, l’article 33 du RGPD impose de notifier la CNIL dans les 72 heures après en avoir pris connaissance. Les entités relevant de NIS2 ont en plus des obligations de signalement des incidents significatifs, et le secteur financier celles de DORA. L’obligation applicable dépend du secteur, de la taille de l’organisation et des données touchées.
Que doivent faire les équipes qui utilisent Kestra ?
Passer immédiatement en 1.3.21, 1.0.45 ou 1.4.0+. Retirer d’Internet toute instance exposée et la placer derrière un VPN. Renouveler identifiants, clés cloud et secrets accessibles à l’instance. Puis analyser les journaux à la recherche de créations ou d’exécutions de workflows inattendues autour et avant la date du correctif.
Sources
Kestra — Avis de sécurité officiel GHSA-5vc5-wxxq-3fjx, CVE-2026-49869 (source primaire)
CISA — Known Exploited Vulnerabilities Catalog (source primaire)
LinuxSecurity — Kestra critical Linux container RCE flaw exploited, CISA warns