Apache Airflowに脆弱性、CVE-2026-58076でRCE

【更新 2026-08-19】本記事を見直し、修正しました。主な修正点：CVE-2026-58076の影響バージョンの出典を訂正（「3.0.0以上 3.3.1未満」は開発元ASFのアドバイザリの記載で、NVDのCPE情報とJVN iPediaはいずれも「3.3.0以上 3.3.1未満」）、「マスク漏れ4件」を実際にマスク漏れに当たる3件に訂正（CVE-2026-59242はマスク漏れではなくデシリアライゼーションの脆弱性）、CVSS値の採点主体（CISA-ADP評価）を該当行に明示。

Apache Software Foundationは2026年8月12日、ワークフロー管理ツール Apache Airflow 3.3.1 を公開し、多数の脆弱性を修正しました。JVN iPediaにも8月17日付で関連する脆弱性が相次いで登録されています。

最も深刻なのは CVE-2026-58076（CVSS v3 基本値 8.8）で、DAG（処理の定義ファイル）を書ける利用者が、本来コードが動いてはいけないスケジューラとAPIサーバ上で任意のコードを実行できます。あわせて、パスワードやAPIキーが画面・ログ・監査ログに平文で表示される「マスク漏れ」も複数修正されました。対応は 3.3.1以降へのアップグレードです。

この記事でわかること

Apache Airflowとは何をするもので、自社に「知らないうちに」存在していないか
今回修正された脆弱性の一覧と、深刻度・影響バージョン
なぜ「DAG作成者が実行できる」ことが脆弱性として扱われるのか（Airflowの信頼境界）
情シスが今日確認すべきこと

Apache Airflowとは何者か──「うちは使っていない」は要確認
何が起きたのか
なぜ「DAG作成者が実行できる」ことが脆弱性なのか
想定されるリスク──Airflowは「認証情報の集積地」である
現場目線の課題──台帳に載っていないものは守れない
情シスはどうすべきか
中長期の視点
まとめ
出典

Apache Airflowとは何者か──「うちは使っていない」は要確認

Apache Airflowとは、一連の処理（ワークフロー）をPythonで定義し、スケジュール実行・監視するためのオープンソースのワークフロー管理ツールです。

主な用途はデータ基盤です。基幹システムからデータウェアハウスへのETL/ELT、夜間バッチの集計、機械学習の学習パイプラインなどを「DAG」と呼ばれるPythonファイルで定義し、依存関係どおりに順番に流します。導入するのは多くの場合データ分析チームや開発チームで、情シスの資産管理台帳に載っていないことが珍しくありません。

そして最も重要な点です。Airflowを自分でインストールした覚えがなくても、クラウドのマネージドサービスとして動いている場合があります。

Amazon MWAA（Managed Workflows for Apache Airflow）── AWS公式ドキュメントに「Apache Airflowのマネージドサービス」と明記されており、インターネット上で公開されているものと同じApache AirflowのUIとオープンソースコードを使ってセットアップされます。
Google Cloud Composer（現 Managed Service for Apache Airflow）── Google公式ドキュメントに「Apache Airflowオープンソースプロジェクトの上に構築されている」と記載があります。

つまり、AWSやGoogle Cloudのコンソールで「MWAA環境」「Composer環境」が1つでも動いていれば、その中身はApache Airflowです。該当判定は次の手順が早いです。

クラウド： AWSコンソールの MWAA 環境一覧、Google Cloud の Composer 環境一覧を確認する。
自前構築：稼働サーバで airflow version または pip show apache-airflow を実行する。Web UIは既定でTCP 8080番を使うため、社内のポートスキャン結果に8080が並んでいたら中身を確認する。

なお、マネージドサービス側が提供するAirflowのバージョンは各クラウドの更新スケジュールに依存します。3.3.1が選べるかどうかは各サービスのサポートバージョン一覧で確認してください。

何が起きたのか

Airflow 3.3.1（2026年8月12日リリース）で修正された主な脆弱性は次のとおりです。深刻度・影響バージョンはNVD、JVN iPediaおよび開発元ASF（Apache Software Foundation）のアドバイザリの記載に基づきます。CVSS値に「※CISA-ADP評価」と付した行は、NVD自身が採点した値ではなくCISA-ADPが付与したスコアです（2026年8月19日時点で、NVDが自ら採点しているのは CVE-2026-58076 と CVE-2026-59244 の2件のみ）。

CVE	CVSS v3	影響バージョン	内容
CVE-2026-58076	8.8（重要）	3.0.0以上 3.3.1未満（ASFアドバイザリ） 3.3.0以上 3.3.1未満（NVD・JVN iPedia）	シリアライズ層が例外ノードを再構築する際、保存されたクラス名を無制限に `import_string()` していた。オペレータの `executor_config` がこの経路に届くため、スケジューラ／APIサーバ上で任意コード実行が可能
CVE-2026-67587	8.8（重要）※CISA-ADP評価	3.3.0	Task SDKがコールバックを再構築する際、保存されたコールバックパスからモジュールをインポート。`next_kwargs` 経由でスケジューラのタイムアウト処理時に任意モジュールを読み込ませられる
CVE-2026-67260	7.3（重要）※CISA-ADP評価	3.3.0	Human-in-the-loop（人手承認）タスクの `awaiting_input` 処理で、タスクインスタンスの `next_kwargs` を許可リストなしでデシリアライズ
CVE-2026-59244	6.5（警告）	3.3.1未満	シークレットマスカーが `var.json` 変数の辞書型の値をマスクせず、Rendered Templates画面に平文表示
CVE-2026-68970	6.5（警告）※CISA-ADP評価	3.3.1未満	リスト型のVariable値がマスクされず、タスクログとRendered Templatesに平文表示（59244の変種）
CVE-2026-68969	6.5（警告）※CISA-ADP評価	3.3.1未満	バルクAPI（`PATCH /api/v2/variables`、`PATCH /api/v2/connections`）経由のVariable値とConnectionの `extra` が、監査ログに平文で書き込まれる
CVE-2026-59242	5.4（警告）※CISA-ADP評価	3.3.1未満	XComの `?deserialize=true` エンドポイントにガードがなく、認証済みAPIユーザーがAPIサーバ上で任意の `airflow.*` クラスをインスタンス化できる（CWE-502）

なお CVE-2026-58076 の影響範囲は、情報源によって記載が分かれています。開発元ASFのアドバイザリ（oss-security）とCVEレコードは「3.0.0以上 3.3.1未満」、NVDのCPE情報とJVN iPediaはいずれも「3.3.0以上 3.3.1未満」です。3.x系を使っているなら、幅の広いほうを前提に3.3.1以降へ上げるのが確実です。

また、Apache Airflow公式のリリースノートには3.3.1の項目にCVE番号が列挙されていません。「リリースノートにCVEが書かれていないから軽微」と判断しないでください。

なぜ「DAG作成者が実行できる」ことが脆弱性なのか

ここが今回いちばん誤解されやすい点です。Airflowのセキュリティモデルでは、DAG作成者は「信頼される役割」として定義されています。DAGはPythonファイルそのものなので、DAG作成者がワーカーやDAGファイルプロセッサ、トリガー上で任意コードを実行できるのは設計上の前提であり、脆弱性ではありません。公式ドキュメントも「DAG作成者は自分が書いたコードに責任を負う」と明記しています。

ではなぜ今回はCVEになったのか。答えは「実行される場所」です。Airflowは「DAG作成者のコードはスケジューラとAPIサーバの中では絶対に動いてはならない」という信頼境界を引いています。今回の3件（58076／67587／67260）は、いずれもこの境界を越えてスケジューラ／APIサーバのプロセス内でコードを走らせるものでした。

この差が効くのは、両プロセスが持っている資産のせいです。スケジューラとAPIサーバはメタデータDBの接続情報とJWTの署名鍵を保持しています。ここを取られると、DAG1本分の権限が、Airflowデプロイ全体の権限に化けます。

想定されるリスク──Airflowは「認証情報の集積地」である

Airflowの怖さは、Airflow自体が壊れることではありません。Airflowが各所の認証情報を1か所に集めていることです。

Airflowの Connections には、データウェアハウス、基幹DB、S3やGCSなどのストレージ、SaaSのAPIキー、SFTPの認証情報が保存されます。Variables にもトークンやパスワードが入りがちです。だからこそ、今回のマスク漏れ3件（59244／68970／68969）は、単なる「画面表示の不具合」では済みません（59242はマスク漏れではなく、APIサーバ上で任意の airflow.* クラスをインスタンス化できるデシリアライゼーションの脆弱性です）。

権限の低い利用者が秘密情報に到達できる：CVE-2026-68969では、VariablesやConnectionsの読み取り権限が一切なくても、監査ログの読み取り権限さえあれば平文の値を読めました。「監査ログは見せても安全」という前提が崩れます。
横展開の起点になる：Airflowの1アカウントから、接続先のDWHやクラウドストレージへ正規の認証情報でアクセスされます。攻撃者から見れば「侵入」ではなく「ログイン」なので、検知が遅れます。
ログに残った秘密は取り消しが効かない：平文で書き出された値は、ログ基盤・バックアップ・SIEMにコピーされて広がります。修正版に上げても、すでに漏れた認証情報のローテーションは別作業です。

現場目線の課題──台帳に載っていないものは守れない

正直に言えば、Airflowは情シスにとって扱いづらい部類のソフトウェアです。

第一に、導入の主体が情シスではないことが多い。データ分析チームが「分析基盤の一部」としてクラウド上に立て、バージョン管理も更新もそのチームが担っています。情シスが月例パッチを回している資産一覧には最初から載っていません。今回のようにクラウドのマネージドサービス経由で動いている場合、サーバの棚卸しをしても物理的な「サーバ」が出てこないため、なおさら見落とします。この「見えない依存をどう棚卸すか」という悩みは、ImageMagickの脆弱性見えない依存をどう棚卸すかで扱った構図とまったく同じです。

第二に、「DAGを書ける人」の数を情シスが把握していない。今回の深刻な3件は、いずれも攻撃の起点がDAG作成者です。開発者がGitでDAGを追加できる運用になっていれば、そのリポジトリへの書き込み権限を持つ全員が対象になります。業務委託先や退職手続き中のアカウントが混ざっていないか、ここは情シスが確認できる領域です。

第三に、Airflowの「DAG作成者は信頼される」という前提を知らないまま権限設計してしまうこと。「参照だけの権限を配ったから安全」と思っていても、DAGを書ける権限は実質的に管理者権限に近い、という認識が共有されていないケースを見かけます。これは脆弱性ではなく設計思想なので、パッチでは直りません。運用ルールで縛るしかない部分です。

CI/CDサーバやビルド基盤も同じ性質を持っています。侵害された場合の確認手順は TeamCity脆弱性が悪用中、侵害痕跡の確認手順の考え方が流用できます。

情シスはどうすべきか

まず対応の優先順位を3段階で整理します。

存在確認（今日）：AWS MWAA／Google Cloud Composerの環境一覧、社内で apache-airflow が入っているサーバ・コンテナを洗い出す。運用主体（誰の持ち物か）を明確にする。
更新（数日）：3.3.1以降へ。自前構築なら pip install -U apache-airflow 相当の更新、マネージドならサービス側のバージョン選択を確認する。
認証情報のローテーション（更新後）：マスク漏れ3件が該当する期間にAirflowのUI・タスクログ・監査ログへアクセスできた利用者を洗い出し、Connections／Variablesに保存している認証情報を入れ替える。更新しただけでは、すでに露出した値は無効になりません。

対策の全体設計については、自前でチェックリストを組むより公的機関の指針に沿うほうが確実です。組織的な体制づくりは IPA「中小企業の情報セキュリティ対策ガイドライン」が実務的で、資産の把握と管理責任の明確化から順に整理できます。侵害が疑われる場合に備えた対応手順の訓練には IPA「セキュリティインシデント対応机上演習教材」が使えます。データ分析チームを巻き込む題材としても向いています。

あわせて、地道な啓発も効きます。「Connectionsに本番DBのパスワードを入れている」という自覚がないまま運用しているケースは実際にあります。技術的な制御より先に、「Airflowは認証情報の金庫である」という認識を運用チームと共有するほうが、結果的に早く効きます。

中長期の視点

今回の件が示しているのは、「情シスの管理外で動いているOSSツールが、社内の認証情報を集約している」という構造そのものです。データ基盤、CI/CD、MLOps基盤はどれも同じ性質を持ちます。

個別のCVEを追いかけるより、次の2つを仕組みにするほうが費用対効果が高いはずです。ひとつは、「どのチームがどのOSSを、どのバージョンで運用しているか」を定期的に申告してもらう仕組み。棚卸しの網から漏れやすいクラウド上のマネージドサービスも対象に含めます。もうひとつは、外部から見えている資産の継続的な把握で、この考え方は EASMとは？外部攻撃対象領域管理の仕組みを解説で整理しています。Airflowの管理画面が意図せずインターネットから到達可能になっていないかは、外側からの視点でしか気づけません。

OSSコンポーネントが自社の外側から入り込んでくる構図全体についてはサプライチェーン攻撃とは？仕組みと種類をわかりやすく解説もあわせてご覧ください。

まとめ

Apache Airflow 3.3.1で複数の脆弱性が修正されました。最も深刻なCVE-2026-58076（CVSS 8.8）は、DAGを書ける利用者がスケジューラ／APIサーバ上で任意コードを実行できるもので、影響範囲は開発元ASFのアドバイザリで3.0.0以上3.3.1未満（NVD・JVN iPediaではいずれも3.3.0以上3.3.1未満と記載）です。
「うちはAirflowを使っていない」は要確認です。Amazon MWAAとGoogle Cloud Composerは、いずれも公式にApache Airflowベースであると明記されたマネージドサービスです。クラウドコンソールの環境一覧をまず見てください。
更新だけでは終わりません。マスク漏れ3件により認証情報が画面・タスクログ・監査ログに平文で露出していた可能性があるため、3.3.1以降へ上げたあとに Connections／Variables の認証情報をローテーションしてください。