Kestra et Starlette au CISA KEV : CVE-2026-49869 et CVE-2026-48710

Le 2 septembre 2026, la CISA a ajouté à son catalogue KEV deux vulnérabilités qui touchent l'outillage des équipes de développement et de données plutôt que l'infrastructure classique :

NVD n'a publié ni score, ni vecteur, ni versions pour l'une ou l'autre au moment de la rédaction. Je m'appuie sur les descriptions CISA et je ne vais pas inventer de numéro de version corrigée.

Ces deux produits partagent un trait : ils sont rarement dans l'inventaire de la DSI. Kestra est installé par une équipe data pour orchestrer ses traitements ; Starlette n'est même pas une application, c'est une bibliothèque qui arrive en dépendance.

CVE-2026-49869 — Kestra : des workflows sans identifiants

Kestra OSS contains an OS command injection vulnerability that could allow an unauthenticated remote attacker to create and execute arbitrary workflows without credentials.

Pour comprendre la gravité, il faut rappeler ce qu'est Kestra : un orchestrateur de workflows. Un workflow Kestra est de l'exécution de code — il lance des scripts, des commandes shell, des conteneurs, des requêtes vers des bases et des services cloud. C'est sa fonction.

Pouvoir créer et exécuter un workflow sans authentification, c'est donc obtenir une exécution de code arbitraire par la fonctionnalité normale du produit. Aucune technique d'exploitation sophistiquée n'est nécessaire au-delà du contournement initial.

Ce qu'un orchestrateur détient

C'est ce qui rend la cible intéressante :

• Les identifiants de tout ce qu'il orchestre : bases de données, entrepôts de données, comptes de stockage cloud, API tierces — stockés en secrets ou en variables
• Un accès réseau large : l'orchestrateur doit joindre toutes les sources et destinations de données
• Des planifications légitimes : un workflow malveillant planifié toutes les heures ressemble exactement à un workflow normal

Un attaquant qui contrôle Kestra n'a pas besoin de se déplacer latéralement : l'outil a été configuré pour atteindre tout ce qui compte.

CVE-2026-48710 — Starlette : quand le chemin reconstruit ment

Kludex Starlette contains a HTTP request/response smuggling vulnerability that could allow attackers to inject paths into the host part, prepending the actual path, leading to issues such as authentication bypass when the authentication depends on the reconstructed URL's path. This vulnerability could be chained with CVE-2026-42271.

Pourquoi Starlette concerne beaucoup plus de monde qu'on ne croit

Starlette est la boîte à outils ASGI sur laquelle repose FastAPI, l'un des frameworks web Python les plus utilisés. Une application FastAPI embarque Starlette en dépendance, que l'équipe le sache ou non. L'exposition réelle se mesure donc en applications FastAPI, pas en installations « Starlette ».

La condition qui compte

La description est précise sur le périmètre : le contournement fonctionne lorsque l'authentification dépend du chemin de l'URL reconstruite.

Concrètement, le code vulnérable est celui qui prend ses décisions d'accès à partir de l'URL telle que Starlette la reconstitue — typiquement un middleware qui fait quelque chose comme « si request.url.path commence par /public, laisser passer ». En injectant du contenu dans la partie hôte, l'attaquant fait en sorte que l'URL reconstruite ne corresponde plus au chemin réellement routé.

Si tes contrôles d'accès reposent sur des dépendances par route (le mécanisme natif de FastAPI) plutôt que sur l'inspection du chemin dans un middleware, tu es probablement hors du scénario décrit. Mais vérifie-le plutôt que de le supposer.

Le chaînage avec CVE-2026-42271

La CISA indique que la faille peut être chaînée avec CVE-2026-42271, sans donner de détail sur cette dernière dans la fiche. Je n'ai pas d'information fiable sur ce qu'elle apporte et je ne vais pas la décrire. Retiens simplement que l'agence considère la combinaison comme pertinente, ce qui justifie de traiter Starlette même si ton cas d'usage semble marginal.

Identifier ton exposition

Kestra

# Version d'une instance
curl -s http://kestra.example.local:8080/api/v1/configs | jq '.version'

# Déploiement Docker
docker ps --format '{{.Image}}' | grep -i kestra

Starlette — c'est une dépendance, cherche-la comme telle

# Dans chaque environnement Python
pip show starlette | grep -i version

# Dans un dépôt : trouver toutes les applications qui en dépendent
grep -rIl --include="requirements*.txt" --include="pyproject.toml" --include="poetry.lock" -iE "starlette|fastapi" .

# Dans les images de conteneur déployées
docker run --rm --entrypoint pip <image> show starlette 2>/dev/null | grep Version

La troisième commande est la plus importante : la version qui compte est celle figée dans l'image en production, pas celle du poste du développeur.

Détection

Kestra

• Workflows créés ou modifiés que personne dans l'équipe ne reconnaît — le signal le plus direct
• Exécutions hors des planifications habituelles
• Tâches de type script ou shell dans des workflows qui n'en contenaient pas
• Accès aux secrets depuis des workflows récents
• Trafic sortant de l'instance vers des destinations sans rapport avec les pipelines déclarés

Starlette / FastAPI

• Requêtes dont l'en-tête Host contient des caractères de chemin (/, %2F) — un Host légitime n'en contient jamais
• Réponses 200 sur des routes protégées sans jeton valide dans la même requête

Mitigation

1. Kestra : mettre à jour et ne jamais exposer

Applique la version corrigée indiquée par l'éditeur. Et surtout : un orchestrateur n'a aucune raison d'être joignable depuis Internet. Place-le derrière un VPN, active l'authentification, restreins l'accès réseau aux équipes qui l'utilisent.

2. Starlette : mettre à jour la dépendance et reconstruire

pip install --upgrade starlette
# puis figer la version dans requirements / lockfile, reconstruire et redéployer les images

Mettre à jour le poste de développement ne corrige rien en production. Le correctif n'existe qu'une fois l'image reconstruite et redéployée.

3. Durcir les contrôles d'accès

Indépendamment du correctif : ne prends pas de décision d'autorisation sur un chemin reconstruit à partir d'en-têtes contrôlés par le client. Préfère les dépendances d'authentification par route, et valide l'en-tête Host au niveau du reverse proxy contre une liste d'hôtes attendus.

4. Si tu conclus à une compromission de Kestra

1. Isoler l'instance
2. Faire tourner tous les secrets qu'elle détient — c'est le vrai périmètre de l'incident
3. Auditer les workflows et leur historique d'exécution sur une fenêtre large
4. Vérifier les systèmes cibles des workflows : bases, entrepôts, stockages cloud

Pourquoi surveiller en continu l'outillage des équipes techniques

Orchestrateurs de données, frameworks web, bibliothèques Python : ces composants échappent aux inventaires classiques parce qu'ils sont installés par les équipes qui les utilisent, et parce qu'une bibliothèque comme Starlette n'apparaît même pas comme un logiciel à part entière. Pourtant, deux d'entre eux viennent d'entrer au catalogue des vulnérabilités activement exploitées.

Avec cveo.tech, inventorie tes outils de données et tes frameworks applicatifs avec leur version exacte, et reçois une alerte automatique dès qu'une CVE critique les concerne.