Windmill 脆弱性 CVE-2026-29059｜認証不要でファイルと秘密情報を読まれる、確認と対策

セルフホスト型のワークフローエンジンとして広く使われる Windmill の脆弱性 CVE-2026-29059 が公表されました。この Windmill 脆弱性 は、認証なしの第三者がサーバー上の任意ファイルを読み取れるもので、実環境での悪用も報じられています。Windmill は Apache Airflow・n8n・Temporal などの代替として広く使われる開発者向けプラットフォーム（GitHub スター 17,000超）で、スクリプトをワークフロー・UI・cron に変えて動かせるのが特徴です。多くが Docker やKubernetes で自前ホストされており、インターネットに公開しているセルフホストのインスタンスが今回の主な対象です。この記事では、CVEの事実関係を一次ソースで裏取りしたうえで、「自分のインスタンスがどこまで危ないのか」を自分で判定するための確認コマンドと、優先度別の対策を整理します。攻撃の再現手順・PoC（実証コード）は扱いません。

なお、今回のように「ソフトウェア自身が持つ取り込み・信頼境界のズレが攻撃面になる」問題を体系的に押さえたい場合は、サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストを合わせて読んでください。本記事はそのうち「セルフホストのWindmillに対して、自分の環境をどう判定するか」に絞った実務編にあたります。

Windmill 脆弱性 CVE-2026-29059 の時系列（Timeline）

日付は一次ソースの公表日に準拠しています。修正版のリリースから公表・悪用報告まで半年が空いている点が、この事案のいちばんの教訓です。

この並びで運用上いちばん重要なのは、修正コミットが入った日（1月11日）と、脆弱性として世に知られた日（3月）の間に約7週間のズレがあることです。責任ある開示のプロセスとしては妥当ですが、防御側の実務では「修正版はとっくに出ていたのに、Advisoryを見るまで気づかず古い版を動かし続けていた」という状態が生まれやすくなります。

さらにその後、悪用が報じられたのは修正から半年後の7月です。つまり「パッチは半年前からあった」のに、公開状態のまま放置されていた未修正インスタンスが一定数残り、それがスキャン・悪用の対象になった、という構図です。速報の見出しだけを見て「新しいゼロデイが出た」と受け取ると状況を読み違えます。恒久対策（更新）はずっと前から用意されていたのがこの事案の性質です。

露出インスタンス数と「悪用」は別の話

報道にある「約170インスタンス／24か国」という数字は、インターネット上に露出している（＝到達可能な）未修正インスタンスをスキャンで数えた露出数であって、そのすべてが侵害されたという意味ではありません。この2つは混同されがちですが、性質がまったく違います。

・露出数：外部から到達できる未修正インスタンスの母数。スキャンで機械的に数えられる
・悪用（exploitation）：実際に攻撃が試行・成功した事例。The Hacker News と VulnCheck が実環境での悪用を報告しているとされる

本記事は、この2つを分けて扱います。自分のインスタンスが「露出しているか」は自分で確認でき（後述）、露出していたなら「読み取られた可能性」を前提に点検する、という順で考えるのが実務的です。なお、公開されたPoC（実証コード）が存在するとされますが、本記事では攻撃手順・PoC値は一切掲載しません。

Windmill 脆弱性 CVE-2026-29059 で何が起きたのか（get_log_fileのパストラバーサル）

この Windmill パストラバーサル脆弱性の技術的な核心は3行です。

1. Windmill のログ取得エンドポイント get_log_file が、ファイル名を無害化せずにファイルパスへ連結する。 該当は /api/w/{workspace}/jobs_u/get_log_file/{filename} で、末尾の jobs_u（”unauthenticated jobs” 系の経路）に属するため認証なしで到達できるのが前提条件です。
2. filename に ../ を含めると、本来のログ保存ディレクトリの外へ抜け出せる（CWE-22 パストラバーサル）。 これにより、Windmill のサーバープロセスが読めるファイルなら任意のファイルを読み取れます。
3. 最も影響が大きい読み取り先が /proc/1/environ。 Linux では PID 1（コンテナ内の初期プロセス）の環境変数がここから読めます。ここに SUPERADMIN_SECRET が入っていれば、それを盗まれます。

SUPERADMIN_SECRET は Windmill の環境変数で、設定されていると Bearer トークンとして superadmin（最上位管理者）認証に使えてしまう性質があります。superadmin を奪えば、Windmill は「スクリプトを実行するためのプラットフォーム」ですから、ジョブの実行・プレビュー系のAPIを通じて任意コード実行（RCE）につなげられます。これが「ファイル読み取り」から「RCE」への発展経路です。

ここで公式Advisory（GHSA-24fr-44f8-fqwg）が明記している重要な但し書きがあります。SUPERADMIN_SECRET は既定では設定されていないことが多く、主に埋め込み（embedded）用途で使われるというものです。Advisory は、この秘密鍵が常に存在する体系的な例外として Nextcloud Flow（Windmill を組み込んだ構成）を挙げています。裏を返せば、多くの通常のセルフホスト構成では SUPERADMIN_SECRET は設定されておらず、被害は「任意ファイル読み取り」に留まる公算が高いということです。ただし「留まる」からといって軽視はできません——設定ファイルや環境変数、ソースコードが読まれること自体が十分に深刻だからです。

この図の分岐（ひし形）が、本記事でいちばん強調したい点です。同じ脆弱性でも、SUPERADMIN_SECRET を設定しているかどうかで到達点（情報漏洩どまり／RCEまで）が変わります。 だからこそ、後述の確認手順では「バージョン」と「SUPERADMIN_SECRET の有無」の2つを必ず確認します。

影響を受けるバージョンと深刻度（CVSS 7.5の実像）

まずバージョンの影響範囲です。ここは一次ソース（NVD／公式Advisory）で一致しています。

次に深刻度です。NVD のエントリには2つのCVSSスコアが併記されており、しかも数字が異なります。

先に誤解を解いておきます。これは「評価機関同士が対立している」わけではありません。 同じNVDエントリの中で、CVSS の採点方式が v3.1 と v4.0 で異なるために数字が変わっているだけです。v3.1 が 7.5 HIGH、v4.0 が 6.9 MEDIUM で、v4.0 のほうが単一の情報漏洩プリミティブの直接影響を低く見積もる傾向があります。

そして、この記事でいちばん理解してほしいのが「7.5 が何を採点しているか」です。v3.1 のベクトル C:H/I:N/A:N は、次の意味です。

・C:H（機密性 High）＝機密情報が読み取られる
・I:N（完全性 None）＝データの改ざんは想定していない
・A:N（可用性 None）＝サービス停止は想定していない

つまり 7.5 という数字は「任意ファイルの読み取り（情報漏洩）」を採点したものであって、RCE を採点した数字ではありません。もしこのスコアが RCE を含んでいたら、完全性・可用性にも影響が及ぶため C:H/I:H/A:H となり、9.8 CRITICAL 級になります。「CVSS 7.5 の重大なRCE」といった要約は、本来は別物である『読み取りの基本スコア』と『条件付きのRCE発展』を混同しています。

正しい理解はこうです。基本スコアが表しているのは「認証不要の任意ファイル読み取り」。RCE はその先の、SUPERADMIN_SECRET が設定されている場合に限って成立する条件付きのエスカレーションです。だから優先度は「自分が RCE 経路（SUPERADMIN_SECRET 設定あり）に該当するか」で二段階に分けて考えるのが実務的です。該当するなら最優先、しなくても情報漏洩として十分に危険なので更新は必須、という判断になります。

影響範囲マトリクス

自分がどの行に当てはまるかを確認してください。「SUPERADMIN_SECRET を設定しているか」と「公開しているか」の2軸で危険度が変わります。

補足を2点。1つ目、内部ネットワーク限定でも「無関係」ではありません。 認証を通す前段の jobs_u 経路のため、社内からアクセスできる立場の人間や、他の侵害経路で内部に入り込んだ攻撃者からは到達しえます。優先度は公開構成より下げてよいですが、更新は行ってください。2つ目、Windmill Cloud（マネージド版）はベンダが管理する範囲です。自前でパッチを当てる必要はありませんが、対応状況はベンダの告知で確認してください。本記事の確認・対策手順は、あくまでセルフホストを対象としています。

自分のWindmillインスタンスが影響を受けるかの確認方法

ここからは、環境を問わず踏む確認手順です。すべて読み取り専用で、攻撃を含みません。自分が管理するインスタンスに対してのみ実行してください。以下のコマンド出力はあくまで書式の例で、実測値ではありません。自分の環境で実行して現在の状態を確認してください。

手順1：稼働バージョンを確定する

最短は API のバージョンエンドポイントです。多くの構成で、稼働中のバージョン文字列を返します。

# 自分が管理するWindmillに対してのみ
curl -s https://your-windmill.example.com/api/version

v1.603.3 のような文字列が返れば、その値が稼働バージョンです。1.603.3 未満なら影響範囲です。返らない・エンドポイントが違う場合は、Windmill の画面右下（フッター）や管理画面のバージョン表示でも確認できます。

Docker で運用している場合は、稼働中のコンテナが使っているイメージのタグも確認しておきます。

# Windmill コンテナのイメージ名・タグを確認
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i windmill

イメージのタグに 1.603.3 以降が含まれていれば修正版です。ただし :latest を使っている場合はタグ文字列からは版が読めないため、上の /api/version で実測してください。「latest だから最新のはず」は、ローカルにキャッシュされた古いイメージがそのまま動いていることがあるので当てになりません。

手順2：SUPERADMIN_SECRET が設定されているかを確認する

これがRCEへ発展するかどうかの分岐です。設定ファイルや起動時の環境変数を確認します。

# docker-compose.yml と .env を確認（該当ディレクトリで）
grep -i "SUPERADMIN_SECRET" docker-compose.yml .env 2>/dev/null

Docker で既に起動しているコンテナの実効的な環境変数を見る場合は、次のようにします。

# 稼働中コンテナの環境変数を確認（<container> は手順1で得た名前）
docker inspect <container> --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -i SUPERADMIN

何も出力されなければ、SUPERADMIN_SECRET は未設定です。この場合、被害は「任意ファイル読み取り（情報漏洩）」に留まる公算が高く、RCE への直接の発展は起きにくいと判断できます（ただし更新は必須）。値が設定されて表示された場合は、/proc/1/environ から窃取されると superadmin 乗っ取り→RCE に発展しうるため、最優先で更新し、後述のシークレットローテーションまで実施してください。埋め込み用途や Nextcloud Flow 構成では、この値が設定されていることが多い点に注意します。

手順3：公開範囲（外部から認証なしで到達できるか）を確認する

jobs_u 経路は認証の前段にあるため、Windmill をインターネットに公開しているかどうかが実際のリスクを大きく左右します。

・リバースプロキシ（Caddy／nginx 等）やロードバランサで、Windmill を外部公開していないか
・公開IP・グローバルに開いた 80/443 で到達できる状態になっていないか
・VPN／IP許可リスト／認証プロキシ（Basic認証や SSO ゲートウェイ）で前段を絞っているか

公開している場合は「露出インスタンス」に該当します。手順1〜3の結果を突き合わせ、「1.603.3 未満 × 公開 × SUPERADMIN_SECRET 設定あり」なら最優先、というように優先度を決めてください。

CVE-2026-29059 への対策（優先度別）

優先度順に整理します。恒久対策は更新のみで、緩和策は時間を稼ぐための応急処置です。

緊急（今すぐ）：1.603.3 以降へ更新する

これが唯一の恒久対策です。 Docker Compose の場合、イメージタグを 1.603.3 以降（または最新の安定版）に固定し、引き直して再起動します。

# docker-compose.yml の image タグを 1.603.3 以降に更新したうえで
docker compose pull
docker compose up -d

更新後は、必ず実測でバージョンを確認します。

curl -s https://your-windmill.example.com/api/version

WordPress の件（Docker公式イメージに修正版タグが無かった）とは異なり、Windmill の修正版 1.603.3 は 2026年1月11日にリリース済みなので、公式イメージのタグを上げれば修正されます。バージョンを跨いで大きく上げる必要はなく、まずは 1.603.3 以降へ確実に上げるのが定石です。

緊急（すぐ更新できない場合の緩和）

更新までのつなぎとして、攻撃の入口である jobs_u／get_log_file 経路への外部到達を絞ります。 ただし jobs_u は公開アプリのジョブ結果取得などにも使われる正規機能を含むため、遮断すると副作用が出る可能性があります。恒久対策はあくまで更新である点を忘れないでください。

・公開を止める／前段で認証を挟む：Windmill を VPN・内部ネットワーク限定にする、リバースプロキシで IP 許可リストや認証（Basic認証・SSO ゲートウェイ）を前段に追加する
・該当パスの遮断：リバースプロキシで get_log_file を含むパスへの外部アクセスを遮断する（正規機能への影響を確認したうえで）
・SUPERADMIN_SECRET の見直し：埋め込み用途で使っていないなら環境変数から削除し、RCE への増幅経路そのものを断つ。使っている場合は、露出していた可能性を前提に値をローテーションする

推奨（更新後に実施）

・シークレットのローテーション：露出の可能性があるなら、Windmill が保持するデータベース接続情報・APIトークン・各種リソースのシークレットを再発行する。読み取り系の脆弱性で最も怖いのは「読まれたシークレットが後日悪用される」ことなので、更新後の無効化までを一続きで行う
・監査ログ・アクセスログの確認：後述の「侵害を受けていないかの確認」を実施する
・superadmin ユーザーの棚卸し：想定外の管理者・superadmin が作られていないか確認する

長期（再発防止）

・Windmill を不必要にインターネットへ公開しない。管理系プラットフォームは内部ネットワーク／VPN 限定が原則
・稼働中の全インスタンスのバージョンを定期的に把握する仕組みを持つ（/api/version の巡回など）
・Windmill セキュリティ情報を含む依存OSSのAdvisory（GitHub の Watch → Security alerts）を購読し、「Advisory を見てから気づく」ではなく「リリースの時点で追える」体制にする。今回のように、修正がAdvisoryより数週間早く出る場合がある

侵害を受けていないかの確認

先に前提を明確にします。 現時点で、公的機関やベンダーから CVE-2026-29059 固有の詳細なIoC（侵害指標）は広く整備されていません。したがって以下はこの脆弱性専用の検知手順ではなく、パストラバーサルによる読み取りやセルフホストサービスの乗っ取りが起きた場合に一般的に確認する標準的な調査手法です。この区別は重要なので、そのまま書いておきます。

それでもこの章を置く理由は、悪用が報じられており、しかも修正から公表まで半年が空いているからです。公開状態で放置していた期間があるなら、更新前に読み取られていた可能性を前提に点検するのが安全です。

1. アクセスログで get_log_file への異常アクセスを探す

Windmill の前段に置いたリバースプロキシ（Caddy／nginx 等）のアクセスログを確認します。

# get_log_file への、パストラバーサル片を含むアクセスを抽出（nginx の例）
grep -iE "get_log_file/.*(\.\.|%2e|/proc/|/etc/)" /var/log/nginx/access.log*

get_log_file へのリクエストに ..（親ディレクトリ参照）や URLエンコードされた %2e、/proc/・/etc/ といった機微なパスの断片が含まれていれば、精査対象です。ただしこれは手がかりであって、1件見つかっただけで侵害を断定するものではありません（スキャナによる試行の可能性もある）。ステータスコードが 200 番台で返っているものは、読み取りが成立した可能性があるため特に注意して見ます。

2. Windmill の監査ログで不審な操作を確認する

Windmill は操作の監査ログ（audit logs）を持ちます。管理画面から、次のような不審な記録がないかを確認します。

・身に覚えのない superadmin 権限での操作（ユーザー管理、ワークスペース設定の変更など）
・想定外のジョブ実行・スクリプトのプレビュー実行。特に、システムコマンドを呼ぶような内容や、外部への通信を伴うもの
・深夜帯や普段使わない時間帯の、単一アカウント／単一IPからの連続操作

3. 想定外の管理者・superadmin アカウントがないか

永続化のために管理者アカウントが追加されることがあります。ユーザー一覧で、心当たりのないアカウントや、作成日時が不自然なものがないかを確認します。superadmin は特に厳重に確認してください。

4. 流出したシークレットの悪用がないか

このCVEの本質は「読み取り」です。したがって最終的な被害は、読まれたシークレットが後から悪用される形で現れることがあります。Windmill に登録していた外部サービスの資格情報（DB、クラウドAPI、Webhook 等）について、連携先での不審なアクセスがないかを確認し、心当たりがなくても露出の可能性があるなら再発行してください。

よくある誤解と、正しい理解

確認・対応でつまずきやすい点を整理します。

まとめ

CVE-2026-29059 は、Windmill のログ取得エンドポイント get_log_file に認証不要のパストラバーサルがあり、サーバー上の任意ファイルを読み取られるという脆弱性です。最悪の場合 /proc/1/environ から SUPERADMIN_SECRET を盗まれ、superadmin 乗っ取り→RCE に発展しえますが、それは SUPERADMIN_SECRET が設定されている場合に限る条件付きの経路です。多くの通常構成では被害は情報漏洩に留まる公算が高い一方、その情報漏洩自体が十分に深刻です。

実務上の要点を3つに絞ります。

1. バージョンを実測する。 Windmill 1.603.3 未満が影響範囲、修正版は 1.603.3（2026年1月11日リリース）。/api/version かフッターで確認する
2. 危険度は自分の設定で決まる。 「SUPERADMIN_SECRET の有無」と「公開しているか」で、情報漏洩どまりか RCE 経路ありかが分かれる。CVSS 7.5 はあくまで読み取りの採点で、即RCEを意味しない
3. 更新して終わりにしない。 修正から公表まで半年空いており、悪用も報じられている。公開して放置していたなら、更新前に読まれた前提でシークレットをローテーションし、ログを確認する

今回のように「自分が影響範囲かを判定する」手順を重視した事例としては、nginx 2026年6月のCVE 3件解説｜Critical 2件は条件付き、自分が対象か判定する手順が同じ構成です。認証・信頼境界の前段が攻撃面になる事例としては、Anthropic MCP の stdio 経由 RCE 脆弱性解説が近い性質を扱っています。また、今回のようにシークレット（APIキー等）の露出が被害の中核になるケースへの備えとしては、Gemini APIキーの不正利用を防ぐ｜漏洩の検知と対策も参考になります。

本記事の事実関係は 2026年7月23日時点の一次ソース（NVD／Windmill公式Advisory／GitHub Releases）で裏取りしています。Windmill やホスティングの状況は時間とともに変わるため、掲載したコマンドをその場で実行し、現在の稼働バージョンと設定を自分で確認してください。 それがこの記事のいちばんの使い方です。

参照ソース

・GHSA-24fr-44f8-fqwg（Windmill公式 GitHub Security Advisory・一次ソース）
・NVD — CVE-2026-29059（CWE-22 Path Traversal・CVSS v3.1 7.5／v4.0 6.9）
・Windmill v1.603.3 Release（GitHub Releases・2026年1月11日／修正版）
・Hackers Exploit Windmill Flaw to Read Files（The Hacker News）
・windmill-labs/windmill（公式リポジトリ）