Une faille CVSS 10 exécute du code en root dans Kestra sans authentification
Le 2 septembre 2026, la CISA a inscrit CVE-2026-49869 au catalogue KEV : une injection de commandes CVSS 10 dans l’orchestrateur open source Kestra, causée par une comparaison de chemin qui laisse passer tout endpoint se terminant par « configs ». Passez en 1.0.45 ou 1.3.21 avant l’échéance fédérale du 5 septembre, puis vérifiez que l’instance n’a pas déjà servi de point d’entrée.
2 septembre 2026. CISA ajoute sept vulnérabilités au catalogue KEV, dont CVE-2026-49869, une injection de commandes CVSS 10.0 dans Kestra. 5 septembre 2026. Échéance fédérale imposée par la directive BOD 26-04 : trois jours pour corriger. 26 juin 2026. La faille était pourtant déjà documentée dans un avis de sécurité GitHub — il lui aura fallu deux mois pour entrer dans le radar des agences. Pourquoi c’est grave : une seule comparaison de suffixe laisse passer tout chemin se terminant par « configs », et Kestra exécute par défaut des scripts shell et Python. Résultat : un shell root dans le conteneur worker, sans identifiants.
Une comparaison de suffixe qui ouvre toute l’API
La cause racine tient en une ligne. Dans Kestra OSS, la classe AuthenticationFilter met sur liste blanche le point de terminaison public de configuration en testant request.getPath().endsWith("/configs"). Le contrôle n’est pas une égalité exacte de chemin, mais une comparaison par suffixe : tout chemin d’API dont le dernier segment vaut « configs » contourne l’authentification Basic Auth, quelle que soit la portion qui le précède.
La conséquence est immédiate. Un attaquant non authentifié peut créer puis exécuter des workflows arbitraires, sans aucun identifiant. L’avis GitHub l’énonce sans détour : la faille « résulte directement en une exécution de code à distance non authentifiée en root à l’intérieur du conteneur worker de Kestra ». Les CWE associés confirment la nature du défaut — CWE-287 (authentification incorrecte), CWE-78 (injection de commandes OS), CWE-184 et CWE-918. Le score CVSS 3.1 est au plafond, 10.0, avec un vecteur sans appel : AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Réseau, complexité faible, aucun privilège, aucune interaction, scope changé, impact total sur la triade CIA.
Le correctif est déjà publié, dans Kestra 1.0.45 et 1.3.21. Toute version antérieure des deux branches est affectée.
Un orchestrateur, donc une exécution de code par défaut
Ce qui transforme une erreur d’authentification en RCE root tient à la nature même de l’outil. Kestra est une plateforme d’orchestration event-driven : son métier est de déclencher des tâches, dont l’exécution de scripts. Et elle livre, activés par défaut, les plugins d’exécution plugin-script-shell et plugin-script-python, ainsi que des runners Docker et Kubernetes.
Autrement dit, il n’y a pas besoin d’enchaîner une seconde vulnérabilité pour transformer l’accès en exécution de code. Contourner l’authentification suffit : l’attaquant soumet un workflow qui invoque le plugin shell, et le code s’exécute avec les droits du process worker — root dans un déploiement conteneurisé classique. C’est précisément ce que CISA résume dans le KEV : « un attaquant distant non authentifié peut créer et exécuter des workflows arbitraires sans identifiants ».
La leçon dépasse Kestra. Tout orchestrateur auto-hébergé — Airflow, Prefect, Temporal, n8n — concentre une surface d’attaque particulière : une fois l’API franchie, l’exécution de code fait partie du contrat du produit. Une faille d’authentification y vaut toujours plus cher qu’ailleurs.
Une entrée tardive au KEV, au milieu d’un lot de sept
L’inscription de CVE-2026-49869 au KEV ne vient pas seule. Le 2 septembre 2026, CISA a ajouté sept vulnérabilités au catalogue, toutes sur preuve d’exploitation active. Trois d’entre elles avaient déjà été couvertes par ETTAYEB : CVE-2026-82329 dans JFrog Artifactory, ainsi que les deux failles SonicWall SMA1000 CVE-2026-83548 et CVE-2026-83549 (SSRF et injection de commandes). Les trois autres sont nouvelles dans le catalogue : CVE-2026-9586 (injection SQL dans Sangoma Switchvox), CVE-2026-48710 (contrebande de requêtes HTTP dans Starlette) et CVE-2026-59822 (authentification incorrecte dans BerriAI LiteLLM).
Ce lot dit deux choses. D’abord, le rythme s’accélère : CISA compile désormais des paquets de vulnérabilités exploitées qui touchent en même temps des produits d’infrastructure, des frameworks web et des briques d’IA comme LiteLLM. Ensuite, le décalage entre la divulgation technique et l’inscription au KEV reste un vrai problème : Kestra avait publié son correctif fin juin, et l’échéance fédérale tombe début septembre. Pendant deux mois, des instances exposées sont restées corrigeables mais non signalées comme prioritaires.
Corriger en trois jours, puis enquêter
L’échéance du 5 septembre 2026 laisse peu de marge, et la directive BOD 26-04 ne se limite pas au patch. Elle impose aussi de vérifier si l’actif a été compromis avant la correction. Pour une instance Kestra exposée, cela signifie chercher des workflows inconnus, des exécutions anormales dans l’historique et des connexions sortantes du worker vers des adresses externes.
# Corriger une instance conteneurisée : épingler une version corrigée
docker pull kestra/kestra:1.0.45 # branche 1.0
docker pull kestra/kestra:1.3.21 # branche 1.3La première action reste la plus simple : identifier la version déployée, puis la porter vers 1.0.45 ou 1.3.21. Pour un déploiement non conteneurisé, c’est l’artefact JVM qu’il faut mettre à jour, puis redémarrer les workers. En parallèle, une revue des workflows et des secrets stockés s’impose — un attaquant qui a déjà exécuté du code dans le worker a pu lire les identifiants injectés dans les tâches.
Au-delà du correctif, la question de fond est l’exposition. Un orchestrateur n’a aucune raison d’être joignable depuis Internet. Le placer derrière un VPN ou un maillage interne, et désactiver les plugins d’exécution de scripts là où ils ne servent pas, réduit la valeur d’une prochaine faille d’authentification.
Une classe de cibles qui monte
Le cas Kestra n’est pas isolé. En août, Langflow — une autre plateforme d’orchestration auto-hébergée, orientée flux d’IA — était frappée par CVE-2026-0768, une RCE qui permettait de dérober les clés API ; nous l’avions couverte à l’époque. Le schéma se répète : ces outils s’installent en quelques commandes, s’exposent sur un port, et concentrent des secrets d’infrastructure. Leur valeur pour un attaquant est double — un accès initial, et des identifiants pour pivoter vers le reste du réseau.
La conséquence pour les équipes est structurelle. Un orchestrateur ne se durcit pas une fois pour toutes : il se surveille en continu. Inventaire des instances déployées, exposition minimale, rotation des secrets, et mise à jour dans les heures qui suivent un avis éditeur. Dans le cas présent, le correctif était disponible depuis fin juin — c’est la visibilité, pas la technique, qui a manqué pendant deux mois.
La mécanique du contournement, pas à pas
Pour mesurer la faille, il suffit de dérouler le scénario. L’attaquant vise une instance Kestra exposée, puis appelle un chemin d’API se terminant par « configs » — par exemple une route de gestion de workflow dont le dernier segment a été forgé pour correspondre au suffixe. Le filtre d’authentification, qui ne compare que la fin du chemin, le laisse passer sans identifiant. Une fois à l’intérieur, l’attaquant soumet un workflow qui appelle le plugin shell, et le process worker exécute la commande en root.
Le point d’attention pour un défenseur n’est pas le détail du payload, mais la leçon de conception : une liste blanche par suffixe n’est pas une liste blanche. Toute comparaison de chemin fondée sur endsWith ou startsWith sans normalisation du chemin complet est un contournement en puissance. C’est le genre de défaut que les revues de code et les scans d’API doivent traquer en priorité.
Verdict
Si vous exploitez Kestra, corrigez immédiatement vers 1.0.45 ou 1.3.21 : l’échéance fédérale du 5 septembre 2026 n’est qu’à un jour, et une instance exposée est un shell root offert. Appliquez aussi la partie forensique de BOD 26-04 — vérifiez l’historique des workflows avant de déclarer l’incident clos.
Si vous hébergez un autre orchestrateur, traitez ce cas comme un rappel : la faille d’authentification y vaut plus cher qu’ailleurs, parce que l’exécution de code fait partie du produit. Coupez l’exposition réseau et auditez les plugins d’exécution activés.
Dans tous les cas, ne mesurez pas votre exposition au seul KEV : Kestra a publié son correctif fin juin, et l’inscription de CISA n’est arrivée que deux mois plus tard. Un suivi des avis éditeurs reste plus rapide que le calendrier des agences.