【ITニュース解説】Finding the Workflow Orchestrators: ZoomEye Exposure Data for Kestra After CVE-2026-49869

Kestraというシステムに、CVE-2026-49869という非常に危険なセキュリティ上の弱点が見つかった。この弱点を利用すると、悪意のある第三者が認証なしでシステムに侵入し、遠隔から任意のプログラムを勝手に実行できてしまう。これは「認証バイパス」から「リモートコード実行」へと発展するもので、システムの安全性を測るCVSSスコアでは最高の10.0と評価されている。この脆弱性は非常に危険であると認識され、サイバーセキュリティの脅威情報を提供するCISA（サイバーセキュリティ・インフラセキュリティ庁）の既知の悪用されている脆弱性リストにも追加された。

この脆弱性の原因は、Kestraシステムの認証処理にある。通常、システムにアクセスするにはユーザー名とパスワードが必要だが、Kestraの特定の認証フィルターには、「/configs」という文字列で終わるリクエストパスの場合、Basic認証という最も基本的な認証手順をスキップしてしまう欠陥があった。Kestraでは、設定情報の一部がAPIのパスに含まれることがあり、この脆弱性によって、本来認証が必要なはずの機能に認証なしでアクセスできるようになってしまった。さらにKestraは、シェルスクリプトやPython、Node.jsなどのプログラムを実行するためのプラグインを標準で備えている。そのため、認証なしでワークフロー、つまりシステムが行う一連の自動処理を作成し、それを実行させることが可能になり、結果として、システムの内部で攻撃者が指定したコマンドを勝手に実行できるようになってしまうのだ。

このような重要なシステムが、インターネット上のどこに、どれくらい存在しているのかを調べるため、ZoomEyeという、インターネットに公開されているデバイスを検索する特殊なエンジンが使われた。2026年9月16日の調査では、「app="Kestra"」という条件で検索すると119件のKestraシステムが検出され、「title="Kestra"」という条件では231件が検出された。ここで「app」はZoomEyeがアプリケーションの種類を識別した結果、「title」はそのウェブページのタイトルを識別した結果を意味する。通常、アプリケーションの識別よりもウェブページのタイトル識別の方が広範囲にわたることが多い。一方で、「app="Kestra OSS"」や、今回見つかった脆弱性のIDである「vul.cve="CVE-2026-49869"」で検索しても、該当するシステムは一つも検出されなかった。これは、ZoomEyeがKestraのオープンソース版を特定の指紋情報で正確に識別できていないことや、脆弱性情報が検索エンジンに登録されるまでに時間がかかることが原因であり、該当するシステムが存在しないわけではない点に注意が必要だ。

これらの検索結果の数字は、インターネットからZoomEyeがKestraだと認識できたシステムの数を示しているが、それだけでは多くの重要な情報は分からない。例えば、検出された各システムがどのKestraのバージョンを実行しているのか、スキャンされたポート以外にもアクセス可能な経路があるのか、Kestra自体の認証フィルターより手前で別の認証がかけられていて脆弱性がブロックされるのか、あるいはすでに攻撃を受けているのか、といったことは、これらの数字だけでは判断できない。今回の脆弱性の影響を受けるのは、Kestra OSSのバージョン1.3.20まで、具体的には1.0.45未満のバージョンと、1.1.0以上1.3.21未満のバージョンだ。修正版は1.0.45と1.3.21で提供されている。公開された情報からわかるのは、そこにKestraがあることだけで、実際にどのバージョンが動いているのか、どのような設定がされているのかは、そのシステムの管理者しか知り得ない情報なのである。

Kestraのような「ワークフローオーケストレーター」と呼ばれる種類のシステムは、単なるウェブアプリケーションとは異なり、非常に強力な機能を備えているため、その脆弱性は特に深刻だ。Kestraの主な役割は、複雑なタスクの自動化処理を定義し、実行スケジュールを設定することにある。具体的には、シェルスクリプト、Python、Node.jsなどのプログラムを実行したり、データベース、クラウドサービス、メッセージングシステム、企業内のAPIなど、様々なシステムと連携したりできる。また、これらの自動処理の設定や変数、実行ログなども保存する。つまり、Kestraは企業内の重要なITインフラの「司令塔」として機能するのだ。このようなシステムで認証が不要になってしまうと、単に情報が漏洩するだけでなく、攻撃者はシステムの正規の機能を悪用して、自社の環境内で自由にプログラムを実行し、重要なデータへのアクセスや、さらには他のシステムへの攻撃の足がかりにすることも可能になる。

この脆弱性を悪用する攻撃の連鎖は非常に短い。認証なしで「/configs」で終わるパスを利用して、攻撃者はKestra上に悪意のあるワークフローを作成し、それを実行するだけで、Kestraのワーカー（実際の処理を行う部分）内で任意のスクリプトが実行されてしまう。特別なコマンドインジェクションのような別の脆弱性を探す必要はなく、Kestraが本来持っている「プログラムを実行する能力」が、そのまま攻撃者の武器となってしまうのだ。この問題に対する修正策として、Kestraの開発元は、パスの正規化を行い、特定のAPIパス「/api/v1/configs」だけを正規の設定エンドポイントとして認識するように変更し、他の「/configs」で終わるパスでは認証されていないアクセスを拒否するようになっている。

Kestraを運用している組織が、この脅威に対して取るべき具体的な対策はいくつかある。まず、ZoomEyeなどの外部からの検索で検出されたKestraインスタンスの数と、自社で管理しているKestraシステムのリストを照合することが重要だ。ワークフローオーケストレーターは、特定の部署、例えばデータチームやプラットフォームチームによって導入されることが多く、企業の全体的な資産管理台帳に登録されていないケースもあるからだ。次に、インターネットなど、信頼できないネットワークからアクセス可能なKestraインスタンスがどれだけあるかを確認する必要がある。たとえ直接インターネットに公開されていないとしても、すでに企業ネットワークや開発ネットワークに侵入した攻撃者によって悪用される可能性もあるため、内部ネットワークからのアクセス可能性も考慮に入れるべきである。

そして最も重要な対策は、Kestraシステムを修正済みのバージョン、具体的には1.0.45、1.3.21、またはそれ以降のサポートされているリリースに速やかにアップグレードすることだ。アップグレードが完了するまでの間は、KestraのAPIへのネットワークアクセスを、信頼できる管理用の入り口に限定し、アプリケーション自体の認証フィルターに頼るのではなく、上位に設置されたプロキシサーバーなどで認証を強制するなどの緊急対策を講じるべきである。また、単に脆弱性スキャンを行うだけでなく、実際にシステムを調査することも大切である。予期せぬワークフローの実行、身に覚えのないプログラムの実行履歴、設定値の不審な変更、ログの削除、未知のソースからのスクリプトタスクの存在などを徹底的に調べる必要がある。もしKestraのワーカーがクラウドサービスの認証情報やデータベースのパスワード、社内APIなどにアクセスできる環境であれば、万が一の事態に備えて、それらの認証情報を定期的に変更する「認証情報ローテーション」も対策に含めるべきだ。コンテナ環境でKestraを動かしている場合、ワーカーコンテナ内で管理者権限が奪われたとしても、それが直ちにホストサーバー全体の管理者権限につながるわけではないが、コンテナの構成によっては脱出の可能性もあるため、そのリスクも考慮する必要がある。CISAがこの脆弱性が実際に悪用されていることを確認したからといって、インターネットに公開されている全てのKestraインスタンスがすでに侵害されているという意味ではないが、警戒は怠るべきではない。

今回のKestraに対する調査で判明した公開インスタンスの数は、約100〜200件程度と、一般的な消費者向けサービスに比べれば決して多くない。この数字は、Kestraのようなシステムが通常、内部ネットワークや厳重なアクセス制御の背後に配置される傾向があることを示しており、本来あるべき姿であると言える。この外部からの検索による調査の価値は、自社の記録と照らし合わせ、意図せずインターネットに公開されているKestraインスタンスがないか、そして想定しているネットワークアクセス制御が実際に適切に機能しているかを確認することにある。コードを実行し、機密性の高い認証情報にアクセスできるようなプラットフォームの場合、インターネットからの検出数は、システムの構成を改めて確認し、検証するためのきっかけであり、それ自体が完璧なセキュリティ対策の代わりになるわけではないことを理解しておく必要がある。