Apache AirflowのCeleryExecutorに認証欠如の欠陥が見つかりました。Celeryブローカーへの書き込み権限を持つ者であれば誰でも、すべてのワーカー上で任意のPython呼び出し可能オブジェクトを実行できます。
この脆弱性は「CVE-2026-68982」として追跡されており、CWE-306（重要な機能に対する認証の欠如）に分類されています。
根本的な原因はexecute_workloadタスクにあります。このタスクは、ブローカーに届いたJSONボディをそのまま型付きオブジェクトにデシリアライズします。
その際、メッセージを正規のスケジューラーと結び付ける署名やHMAC、ブローカー側のACLは一切ありません。Airflowは、Execution APIを通じてExecuteTaskメッセージの署名付きトークンを検証しています。
Deadline Alertのコールバックに対応するExecuteCallbackメッセージタイプも同じトークンフィールドを持っています。しかし、コールバックの実行前にこのトークンを検証するコードパスは存在しません。
ワーカーは、コールバックデータから攻撃者が制御できるpathとkwargsの値を読み取ります。続いてimport_moduleとgetattrを呼び出して実行対象を解決し、ただちに実行します。
ワーカー環境でインポート可能な呼び出し可能オブジェクトであれば、os.system、subprocess、プロバイダーのNotifierクラスなども含め、すべて到達可能です。単なるタスクの再実行にとどまらず、任意コード実行に至ります。
バージョン3.3.0では、このロジックがフォークされたCallbackSubprocessに移されました。この処理はトークンを保持するhttpx.Clientを構築しますが、実行前の検証は行いません。
この手法は、Redisインスタンスの露出よりも危険です。Airflowのセキュリティモデルでは、ワーカー上でのコード実行は信頼されたDAG作成者にのみ認められています。今回の欠陥により、Airflowの認証情報を持たない攻撃者にも同じ結果がもたらされます。
Apacheは2020年にも、同様のCeleryブローカーのコマンド実行の脆弱性をCVE-2020-11981として修正しています。アドバイザリーでも関連する脆弱性として挙げられています。ただし、今回の欠陥は別のコードパスに存在します。
攻撃にDAG、DagRun、スケジューラー、Webサーバーへのアクセスは必要ありません。Saharの概念実証（PoC）では、空のトークンを持つExecuteCallbackワークロードを偽造し、app.send_task("execute_workload")経由でRedisブローカーに送信しました。
ワーカーはos.systemを実行してマーカーファイルを書き込みました。その間も/api/v2/dagsはtotal_entries: 0を返していました。記録されたデモではさらに踏み込み、Fernetキーを含むワーカーの環境変数を抜き出しています。
TaskInstanceが作成されないため、防御側はAirflowのUIやAPIで監査証跡を得られません。検知はブローカーのトラフィック検査と、Celeryワーカーのプロセスログに頼ることになります。
Reflectizが2026年7月に実施したShodanの調査では、AirflowとCeleryのクラスターで到達可能なRedisブローカー211台のうち、198台が認証なしで応答していました。
過去の報道では、設定ミスのあるAirflowインスタンスから認証情報が漏えいし、SlackやAWS、PayPalのものが含まれていたことが示されています。ワーカーが侵害されれば、重要な機密情報が流出するおそれがあります。
Redisのパスワードを設定せずに出荷されるDocker Composeのクイックスタート設定は、テストに使われたラボ環境と同じ構成です。また、Redis自体にも、RediShellのようなuse-after-freeを悪用する攻撃経路があり、ブローカーの露出が危険である理由を物語っています。
Apacheはこの問題の重要度を「Important」と評価しており、公式のCVSSスコアは公表していません。一方、Reflectizはベクター文字列AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hで、9.8（Critical）と評価しました。
CeleryExecutorを使用する3.4.0より前のすべてのリリースが影響を受けます。2026年11月6日にリリースされたバージョン3.4.0では、プルリクエスト71192でこの欠陥が修正されました。
修正後のワーカーは、コールバックを実行する前に、Execution APIで1回限りのトークンを引き換えます。管理者はExecution APIサーバーとすべてのCeleryExecutorワーカーの両方をアップグレードする必要があります。片方だけでは修正は有効になりません。
管理者はこのほか、RedisのAUTHまたはRabbitMQの認証情報を必須にし、ポート6379と5672へのインターネットからのアクセスを遮断してください。偽造されたexecute_workloadメッセージがないか、ブローカーへの書き込みも監査する必要があります。
16,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を削減しています。チームで試してみる
翻訳元: https://cyberpress.org/critical-apache-airflow-flaw/
