Illustration sombre et orange d’un badge d’accès traversant une porte-forteresse de circuits

CVE-2026-75156 : Apache Airflow laissait entrer des attaquants avec un simple jeton Azure

Une faille critique (CVSS 9,1) dans Apache Airflow permettait de se connecter avec un simple jeton Azure forgé. Le correctif 3.8.1 et les actions à mener.

Mardi 8 septembre, le projet Apache a publié un avis de sécurité qui mérite votre attention si vous exploitez ses outils : pendant des semaines, il était possible de se connecter à une interface Apache Airflow sans avoir de compte, avec un badge numérique fabriqué par l’attaquant lui-même. La faille, référencée CVE-2026-75156, vient d’être corrigée en urgence.

Apache Airflow est un outil open source très répandu : il orchestre des tâches automatisées, ces petits programmes qui tournent en arrière-plan pour synchroniser des données, préparer des rapports ou alimenter des tableaux de bord. Après la faille KVM du noyau Linux dont on parlait récemment, c’est un autre socle open source très utilisé qui passe par la case sécurité.

Ce que révèle l’annonce Apache

Le problème se cache dans le module qui gère la connexion d’Airflow via Azure AD, le service de comptes de Microsoft. Quand vous vous connectez à une application avec votre compte Microsoft, le service fabrique un « id_token », un badge numérique signé qui dit qui vous êtes et pour quelle application vous demandez l’entrée.

Le défaut tient en une phrase : le module vérifiait la signature du badge, mais pas son émetteur ni son destinataire. Microsoft publie en effet un annuaire de clés de signature partagé par tous ses clients (les « tenants », ces espaces d’organisation) : un badge signé par n’importe quel tenant passait donc le contrôle. Pire, le nom d’utilisateur et le rôle étaient lus dans ce badge, que l’attaquant rédigeait lui-même.

L’annonce officielle du projet Apache, publiée sur la liste users@airflow le 8 septembre 2026.

Capture : Apache Software Foundation, liste users@airflow

Concrètement, n’importe qui capable de créer un tenant Azure, ce qui est gratuit, pouvait se fabriquer un badge valide et entrer dans l’interface d’administration d’Airflow. Sans mot de passe à deviner, sans compte à créer sur la cible. Le scénario d’attaque tient en un après-midi de travail.

Qui est concerné

Sont touchées les versions 3.7.3 à 3.8.0 du paquet apache-airflow-providers-fab, le module d’authentification en question. Une condition importante : l’instance doit utiliser le « FAB auth manager » avec Azure AD comme fournisseur de connexion. Si vous vous connectez avec des comptes locaux ou un autre système, vous n’êtes pas concerné.

Détail piquant : la version 3.7.3 était censée corriger une faille précédente, CVE-2026-59243, qui permettait de présenter des badges carrément non signés. Le premier correctif vérifiait la signature, mais oubliait de contrôler l’émetteur. Résultat, prévient Apache : ceux qui avaient appliqué cette correction restent vulnérables et doivent refaire une mise à jour.

Le correctif et les actions à mener

La version 3.8.1 du paquet apache-airflow-providers-fab referme la porte : le badge doit désormais être émis par votre tenant et destiné à votre application. Le correctif a été intégré dans le projet dès le 18 août, comme le montre la pull request #71735, et l’annonce publique a suivi le 8 septembre.

✉️ Un moment, avant de continuer la lecture…

La newsletter condense l'actu tech chaque dimanche : les 4-5 infos qui comptent + un outil open source à installer, en français. Inscription gratuite, désinscription en un clic.

La pull request #71735 d’Apache Airflow, fusionnée le 18 août 2026, ajoute la vérification de l’émetteur et de l’audience des jetons Azure AD.

Capture : GitHub, apache/airflow

Si vous administrez une instance Airflow branchée sur Azure AD, vérifiez votre version avec la commande pip show apache-airflow-providers-fab (pip est l’outil d’installation des paquets Python), puis mettez à jour avec pip install --upgrade apache-airflow-providers-fab. Il faut au minimum la 3.8.1, suivie d’un redémarrage d’Airflow.

Deux vérifications complémentaires valent le détour : passez vos journaux de connexion en revue à la recherche d’identifiants inconnus, et notez qu’une configuration pointant vers les accès « multi-tenant » de Microsoft (les adresses common ou organizations) refuse maintenant de démarrer sans déclaration explicite du tenant, un changement voulu par les développeurs.

Les leçons à retenir

La signature d’un badge prouve qu’il n’a pas été modifié, pas qu’il vient de la bonne source. C’est la différence entre un sceau intact et une lettre expédiée par n’importe qui avec votre nom dessus. Ici, la confiance accordée à l’annuaire de clés mutualisé de Microsoft a fait le reste.

C’est aussi la deuxième correction en quelques mois sur le même flux de connexion, après CVE-2026-59243. Si vous exploitez Airflow avec Azure AD, traitez la mise à jour comme urgente : la faille ne demande aucune interaction de la victime, et son exploitation ne demande qu’un compte Microsoft gratuit.

Autant dire qu’on la ferme ce soir, cette porte. Et qu’on garde un œil sur les prochains avis d’Apache : la qualité d’un outil open source se joue aussi là.

Sources

L’annonce officielle du projet Apache sur la liste users@airflow, avec les versions touchées et le crédit aux chercheurs.

La pull request #71735 sur le dépôt GitHub d’Apache Airflow, qui détaille le correctif et le raisonnement technique.

La fiche CVE-2026-75156 du NVD, base américaine des vulnérabilités, qui confirme la note CVSS 9,1.



Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.

No comments yet