Kestraに4件目の脆弱性 CVE-2026-53576、安定版に修正なし

複数の処理を順番に自動で動かす「業務自動化の司令塔」として急成長中のソフト「Kestra（ケストラ）」に、ログインせずに誰でも管理者級の権限を奪い、サーバーを丸ごと乗っ取れる最悪レベルの脆弱性が見つかりました（CVE-2026-53576／CVE-2026-49869）。危険度を示すCVSSは、いずれも満点の10.0（緊急）。さらに管理者パスワードの保管方法が弱い3件目（CVE-2026-55069・8.7）も同時に公表されました。修正版は1.3.24（および旧系統の1.0.45）で提供されています。

Kestraは、データ処理や定型業務、システムの自動運用といった「いくつもの作業を、決めた順番と条件で自動実行する」段取りをまとめて回すための基盤です。Bloomberg、トヨタ、JPモルガン、Appleなど3万を超える組織が使っているとされ、GitHubでの注目度を示すスター数は2万6千を超えます。今回の穴は、その司令塔をインターネットや社内ネットワークに公開しているだけで、認証なしに乗っ取られるという、極めて危険なものです。本記事では、何が起きるのか、誰が危ないのか、いま何をすべきかを順に整理します。

4件目の脆弱性：テンプレート機能のhttp()を悪用するSSRF（CVE未採番・CVSS 8.6）

2026年7月23日、開発元のGitHubに新しいセキュリティ勧告（GHSA-r56g-q4p6-m3p6）が公開されました。狙われるのは、処理の手順書（Flow YAML）の中で使えるテンプレート機能「Pebble」に用意された http() という関数です。ここに書かれたURLは何も検証されないまま URI.create() へ渡されており、宛先の制限も、使える通信方式の制限もかかっていませんでした。深刻度はCVSS 3.1で8.6（高）、種別はSSRF（CWE-918）。CVE番号は勧告の時点で未採番（Not yet assigned）です。

攻撃に認証は要りません。細工した手順書をインポートして実行させるだけで、Kestraのサーバーが攻撃者の代わりに通信を行います。届く先は、社内のプライベートIPアドレス、Kestra自身（localhost）、file:// や gopher:// といった通信方式、そしてクラウドのメタデータエンドポイント（169.254.169.254）です。169.254.169.254は、クラウド上のサーバーが「自分に割り当てられた認証情報」を取り出すために用意された特別なアドレスで、ここへ手が届くということは、そのサーバーが持つクラウドの合鍵をそのまま読み出される恐れがある、という意味になります。

勧告の「2.0.0で修正済み」は、まだ存在しないバージョン

本件で最も重い事実は、修正版の扱いです。勧告は影響範囲を「2.0.0より前のすべて」、修正版を「2.0.0」と記載しています。ところが、その2.0.0が配布されていません。2026年7月29日時点で、公開情報を一つずつ当たった結果が下の表です。

結論は一つです。2026年7月29日の時点で、このSSRFを塞いだ安定版は存在しません。最新のv1.3.30（2026年7月28日）も、LTS 1.0系のv1.0.53（同日）も、v1.2.24（2026年7月7日）も、v0.22.46（2026年7月15日）も、いずれも未修正のままです。「勧告に修正版が書いてあるから更新すれば直る」という、いつもの手順が通じない状態にあります。

【2026年8月5日 再確認】この結論は変わっていません。8月4日に v1.3.31 と v1.0.54 が出ましたが、どちらのリリースノートにもセキュリティ修正の記載はなく、勧告の「修正版」の欄も2.0.0のままです。1週間で安定版が2回出て、なおこの穴だけが置き去りになっている、という状況です。

先に公表された2件との違いは、はっきり分けて把握してください。CVE-2026-53576とCVE-2026-49869は1.3.21（旧系統は1.0.45）で修正済みで、本記事の以降の案内はそのまま有効です。パスワード保管のCVE-2026-55069も1.3.24で塞がっています。穴が開いたままなのは、今回のSSRFだけです。裏を返せば、1.3.24以降への更新は引き続き必須で、そのうえでSSRFにはネットワーク側の手当てを重ねる、という二段構えになります。

修正版がない間に取れる手当て

開発元はセキュリティハードニングの手引きで、まさにこの種の攻撃を前提とした防ぎ方を示しています。現実的に効くのは次の5つです。

悪用については、本記事時点で報告がなく、CISAのKEVにも登録されていません（2026年8月5日に8月4日版の全1,660件を照合し、Kestra関連が1件も入っていないことを再確認しました）。公開情報としては、このSSRFと先の認証バイパスをまとめて調べる検査ツールがGitHubに出ていますが、武器化された攻撃コードではなく「authorized defensive testing only（許可を得た防御目的の検査に限る）」と明記された診断用のものです。自組織の環境が該当するかを確かめる用途には使えますが、探索の後押しになりかねないため本記事ではURLを載せません。

先に公表された3件の脆弱性の概要

まず要点を一覧にします。最も深刻な2件は、認証（ログイン）を一切必要とせず、ネットワーク越しにそのまま悪用できる点が特徴です。「ちょっとした操作が引き金」ですらなく、公開されているKestraに細工したリクエストを送りつけるだけで成立します。

CVSSが満点の10.0に達したのは、攻撃が認証なし・遠隔・利用者の操作不要で成立し、しかも被害がKestraのコンテナを超えてサーバー本体にまで及ぶためです。2件の重大な穴は、開発元のGitHubでセキュリティ勧告（GHSA）として公開され、報告したのはそれぞれセキュリティ研究者の@Vasco0x4氏と、セキュリティ企業turingpointのJan Kahlen氏です。3件目を含め、いずれもすでに修正版が出ています。

誰が、何のために狙うのか

この2件が際立って危ないのは、攻撃に正規の利用者をだます手間すらいらない点です。標的の側が何かを開く・クリックする必要はなく、攻撃が成立する条件は「そのKestraに通信が届くこと」だけ。狙うのは、インターネット上に露出した管理画面を機械的に探し回る攻撃者、身代金目的でサーバーを暗号化するランサムウェア集団、奪った侵入経路を企業に売る初期アクセス業者です。彼らにとって自動化基盤は、社内の様々なシステムやデータベース、クラウドへの「接続情報の集積地」であり、一度握れば被害を一気に広げられる格好の的だからです。

手口はこうです。攻撃者は末尾を細工しただけのURLを送って認証の関所を素通りし、シェルのコマンドを仕込んだ自動処理を勝手に作って実行させ、サーバー上で管理者（root）の権限を手にします。そこから先は連鎖します。Kestraのコンテナが土台のサーバーとつながっていれば、ホストOSごと乗っ取られます。別の経路では、社内ネットワークやクラウドの設定情報（認証キーが置かれた領域）を読み出され、本番環境への合鍵まで奪われます。

被害を背負うのは、Kestraを運用する情報システム部門やデータ基盤チーム、そして経営です。司令塔を握られれば、そこが扱う全データの流出、業務の停止、本番システムへの侵入、取引先への波及まで一直線です。さらに3件目の脆弱性は、データベースを読める立場の者が管理者パスワードをオフラインで解読できてしまうもので、内部からの権限昇格を許します。被害の入口を断つ最短の手は、公開範囲を絞り、ツールを最新版へ上げることに尽きます。

そもそもKestraとは何か

Kestraは、フランス発のオープンソースの「ワークフロー・オーケストレーション基盤」です。聞き慣れない言葉ですが、要はたくさんの処理を、決めた順番・条件・時刻で自動的に動かす段取りをまとめて管理する司令塔です。たとえば「毎晩データを集めて加工し、集計してレポートを配る」「コードを受け取って検査し、問題なければ公開する」といった一連の流れを、人手をかけずに回します。

同じ役割のソフトとしては、古くから使われるPrefectやApache Airflowが有名です。Kestraはそれらが多くプログラム（Python）の知識を前提とするのに対し、YAMLという読み書きしやすい書式で処理の流れを定義できる手軽さで急速に広がりました。2026年3月には25億円規模の資金調達も発表し、2025年だけで実行されたワークフローは20億件にのぼるとされています。

こうした基盤は性質上、社内の多くのシステム・データベース・クラウドへの接続情報を預かります。だからこそ、認証で守られていることが大前提であり、その関所が破られると被害が一点に集中して大きくなります。今回の2件は、まさにその関所そのものに穴が空いていたという話です。

先に公表された3件を個別に見る

CVE-2026-53576／CVE-2026-49869：URLの末尾を偽装するだけで関所を素通り（CVSS 10.0）

2件の満点級の穴は、根っこが同じです。Kestraは、ログインなしでアクセスしてよい一部のURL（設定情報を返す末尾/configsのページ）だけを通すために、認証の関所で「そのURLが /configs で終わっているか」を判定していました。問題は、この判定が単純な「末尾一致（endsWith("/configs")）」だったことです。公開された勧告によれば、攻撃者は /api/v1/main/flows/tutorial/configs のように末尾だけ /configs に見せかけたURLを作れば、本来は認証が要るはずの操作を素通りで実行できてしまいます。

関所を抜けた攻撃者は、シェルのコマンドを仕込んだワークフローを認証なしで作成し、そのまま実行できます。実行はKestraの作業用コンテナの中でroot（最高権限）として走るため、被害は深刻です。CVE-2026-53576では、コンテナに /var/run/docker.sock（Dockerを操作する窓口）が見えている構成だと、そこを足がかりに土台のサーバーOSごと奪われると報告されています。CVE-2026-49869では、テンプレート機能の通信処理にURLの制限がなく、社内サービスやクラウドの設定情報（認証キーの置き場）を読み出すSSRFという攻撃にもつながると指摘されています。どちらも対象は1.3.20以前で、1.3.21（旧系統は1.0.45）で修正されました。

CVE-2026-55069：管理者パスワードがオフラインで解読される（CVSS 8.7）

3件目は、ログイン用パスワードの保管方法の弱さです。Kestraの簡易認証では、管理者パスワードがSHA-512という「計算が速い」方式で保存されていました。パスワードの保管には本来、わざと計算に時間のかかる方式を使い、総当たりの解読を難しくします。ところが計算が速いと、データベースを読める立場の者が保存値を持ち出し、手元で高速に総当たりして元のパスワードを割り出せてしまいます。

勧告によれば、Kubernetes（コンテナをまとめて運用する仕組み）上で動かしている場合、解読した管理者権限を足がかりにサービスアカウントのトークンや保管された機密情報すべてへ手が届き、さらに大きな権限へと広がる恐れがあります。攻撃の前提としてデータベースの読み取りが必要なため危険度は10.0までは届きませんが、上の2件と組み合わさると被害が拡大します。修正は1.3.24で、3件すべてをまとめてふさぐには、この1.3.24以降への更新が確実です。

自分が影響を受けるかの早見表

Kestraを使っているか、どこに公開しているか、どのバージョンかでリスクが大きく変わります。下の表で自分の状況を確認してください。バージョンは管理画面や kestra --version で確認できます。

とくに危ないのは、Kestraの管理画面やAPIをインターネットから直接たどれる状態にしている場合です。更新が済むまでの応急処置として、社外からのアクセスを遮断する（ファイアウォールやVPNの内側に置く）ことも強く推奨されます。/var/run/docker.sock をコンテナに渡している構成は、被害がホストまで広がるため特に優先して見直してください。

この表は上の3件についてのものです。4件目のSSRF（CVE未採番）は、最新のv1.3.30を含む安定版すべてが該当します。1.3.24以降に上げても塞がらないため、そちらはネットワーク側の緩和策で対処してください。

悪用は確認されているのか

現時点で分かっていることと、まだ確認できていないことを分けて整理します。

運用者がいま確認すべきこと

最優先は、Kestraを1.3.24以降（旧系統を使っている場合は1.0.45以降）へ更新することです。1.3.24まで上げれば、満点級の2件とパスワードの問題をまとめてふさげます。更新が今すぐ難しい場合は、応急処置として社外からのアクセスを遮断し、信頼できるネットワークの内側だけに公開を限定してください。あわせて、/var/run/docker.sock をコンテナに渡していないか、データベースへのアクセス権が広すぎないかも点検しましょう。そのうえで、更新だけでは塞がらない4件目のSSRFに備えて、169.254.169.254/32 宛ての通信をネットワークACLで遮断し、手順書（Flow YAML）をインポート・実行できる利用者を絞ってください。

すでに古いバージョンを外部に公開していた環境では、侵入の痕跡（身に覚えのないワークフローや実行履歴）が残っていないかを確認し、必要ならKestraが預かる接続情報（クラウドの認証キーやデータベースの資格情報）の作り替えも検討してください。同じく自動化・データ基盤を狙う攻撃としては、Prefectの乗っ取りの穴も記憶に新しいところです。基盤が取り込む外部のプラグインや部品の安全性は、無料のOSS脆弱性スキャナーでも手早く点検できます。国内企業に関わる重大な脆弱性の動きは、2026年の重大脆弱性まとめもあわせて確認してください。

よくある質問

まとめ

業務自動化の司令塔Kestraで見つかったCVE-2026-53576とCVE-2026-49869は、認証の関所が「URLの末尾が/configsか」だけを雑に判定していたために、末尾を偽装するだけで素通りでき、認証なしにroot権限でコマンドを実行され、サーバー本体まで奪われる最悪級の欠陥です。CVSSはいずれも満点の10.0。3件目のCVE-2026-55069は、管理者パスワードが解読されやすい形で保管されていた問題です。対策はシンプルで、Kestraを1.3.24以降へ更新し、社外からのアクセスを絞ること。とりわけ、管理画面をインターネットに直接さらしている環境は、今この瞬間が危険だと考えて対応すべきでございます。

そして2026年7月23日、4件目としてテンプレート機能の http() を悪用するSSRF（GHSA-r56g-q4p6-m3p6・CVSS 8.6・CVE未採番）が公表されました。勧告は「2.0.0で修正」としていますが、その2.0.0は正式リリースされておらず、GitHubにはリリース候補しかありません。最新のv1.3.30を含む安定版すべてが未修正という、更新では解決できない状態です。前の3件は上げれば塞がる、4件目は上げても塞がらない――この二つを分けたうえで、169.254.169.254/32 への遮断と手順書のインポート制限を先に手当てしてください。

参照元

• ▸NVD - CVE-2026-53576
• ▸NVD - CVE-2026-49869
• ▸NVD - CVE-2026-55069
• ▸kestra-io/kestra - Security Advisories（GHSA一覧）
• ▸GHSA-r56g-q4p6-m3p6 - Pebbleのhttp()経由のSSRF（CVSS 8.6・CVE未採番）
• ▸kestra-io/kestra - Releases（修正版 1.3.21 / 1.3.24 / 1.0.45、最新 v1.3.30）
• ▸Kestra Docs - Releases（最新はLTS 1.3、2.0の記載なし）
• ▸Kestra Docs - Security Hardening（169.254.169.254/32の遮断ほか）
• ▸Kestra 公式サイト
• ▸PR Newswire - Kestra raises $25M Series A（普及規模・利用組織）