トップ/記事一覧/業務自動化基盤Kestraに最悪の脆弱性 CVE-2026-53576、認証なしで乗っ取り
kestra-cve-cover-ja

業務自動化基盤Kestraに最悪の脆弱性 CVE-2026-53576、認証なしで乗っ取り

Bloombergやトヨタなど3万組織が使う業務自動化基盤Kestraに、最悪レベルの脆弱性が見つかりました。インターネットに公開していると、認証なしで誰でも管理者級の権限を奪い、サーバーやデータを丸ごと乗っ取られる恐れがあります。CVE-2026-53576ほか、修正版1.3.24へ即更新を。

ニュース2026年6月27日公開 本日更新
目次
この記事のポイント

Bloombergやトヨタなど3万組織が使う業務自動化基盤Kestraに、最悪レベルの脆弱性が見つかりました。インターネットに公開していると、認証なしで誰でも管理者級の権限を奪い、サーバーやデータを丸ごと乗っ取られる恐れがあります。CVE-2026-53576ほか、修正版1.3.24へ即更新を。

複数の処理を順番に自動で動かす「業務自動化の司令塔」として急成長中のソフト「Kestra(ケストラ)」に、ログインせずに誰でも管理者級の権限を奪い、サーバーを丸ごと乗っ取れる最悪レベルの脆弱性が見つかりました(CVE-2026-53576CVE-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千を超えます。今回の穴は、その司令塔をインターネットや社内ネットワークに公開しているだけで、認証なしに乗っ取られるという、極めて危険なものです。本記事では、何が起きるのか、誰が危ないのか、いま何をすべきかを順に整理します。

3件の脆弱性の概要

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

項目CVE-2026-53576CVE-2026-49869CVE-2026-55069
何が起きるか認証なしで
ホストごと乗っ取り
認証なしで
root権限コード実行
管理者パスワードの
解読
認証の要否不要不要要(DBの
読み取り権限)
欠陥の種類認証バイパス+
コード注入
認証バイパス+
コマンド注入/SSRF
弱いパスワード
保管(CWE-916)
深刻度CVSS 10.0(緊急)CVSS 10.0(緊急)CVSS 8.7(高)
対象バージョン1.3.20以前1.3.20以前1.3.24より前
修正版1.3.21 / 1.0.451.3.21 / 1.0.451.3.24
悪用状況報告なし
(KEV未登録)
報告なし
(KEV未登録)
報告なし
(KEV未登録)

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 で確認できます。

状況リスク優先度いま取るべき行動
1.3.20以前を
ネットに公開している
認証なしで
即・乗っ取り
最優先
(今すぐ)
公開を遮断し
1.3.24以降へ更新
1.3.20以前を
社内網のみで運用
内部からの
乗っ取りの恐れ
早急に1.3.24
以降へ更新
1.3.21〜1.3.23
を利用
パスワード解読の
リスクが残る
1.3.24以降へ更新
すでに1.3.24以降
を利用
3件とも
影響なし
通常公開範囲を点検

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

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

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

✓ 確認済みの事実

  • 認証の関所が末尾一致の判定で、/configsを装ったURLで素通りできる(NVD・CVE-2026-53576CVE-2026-49869
  • 認証なしのコマンド実行はroot権限で走り、Dockerソケット経由でホストOSまで奪われ得る(Kestra セキュリティ勧告
  • 修正版は1.3.21・1.0.45(10.0の2件)と1.3.24(パスワード問題)。報告者は@Vasco0x4氏とturingpointのJan Kahlen氏

? 現時点で未確認のこと

  • ?実際に悪用された事例 ― 本記事時点でCISAの悪用が確認された脆弱性リスト(KEV)に未登録。ただし認証不要の遠隔攻撃は機械的なスキャンの標的になりやすい
  • ?国内で被害に遭った組織の有無 ― 公表された情報はなく、影響範囲は各組織の公開設定による

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

最優先は、Kestraを1.3.24以降(旧系統を使っている場合は1.0.45以降)へ更新することです。1.3.24まで上げれば、満点級の2件とパスワードの問題をまとめてふさげます。更新が今すぐ難しい場合は、応急処置として社外からのアクセスを遮断し、信頼できるネットワークの内側だけに公開を限定してください。あわせて、/var/run/docker.sock をコンテナに渡していないか、データベースへのアクセス権が広すぎないかも点検しましょう。

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

よくある質問

Q. Kestraを使っていますが、すぐに乗っ取られますか?

A. 最も危険なのは、1.3.20以前のKestraをインターネットから直接アクセスできる状態にしている場合です。この構成だと、認証なしで遠隔から乗っ取られる恐れがあり、今すぐ公開の遮断と更新が必要です。社内ネットワークだけで使っている場合でも、内部からの攻撃に備えて早急な更新をおすすめします。

Q. どのバージョンに更新すればよいですか?

A. 1.3.24以降にしてください。満点級のCVE-2026-53576とCVE-2026-49869は1.3.21(旧系統は1.0.45)で、パスワード保管のCVE-2026-55069は1.3.24で修正されています。3件すべてをまとめてふさぐには1.3.24以降が確実です。

Q. すぐに更新できない場合の応急処置はありますか?

A. 社外からのアクセスを遮断し、VPNやファイアウォールの内側だけに公開を限定してください。これだけで、認証なしの遠隔攻撃の大半を防げます。また、コンテナにDockerの操作窓口(/var/run/docker.sock)を渡している構成は、被害がサーバー本体まで広がるため優先して見直しましょう。

Q. KestraはAirflowやPrefectと何が違うのですか?

A. いずれも複数の処理を自動で順番に動かす「司令塔」ですが、AirflowやPrefectがプログラム(Python)の知識を前提とするのに対し、KestraはYAMLという読み書きしやすい書式で流れを定義できる手軽さが特徴です。社内の多くのシステムへの接続情報を預かる点は共通で、いずれも認証の守りが重要になります。

まとめ

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

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go