Kestra OSS の認証フィルタが末尾一致で判定、末尾が configs のパスすべてで認証を素通りし未認証RCEに至る（1.0.45 / 1.3.21 で修正・KEV 期限 2026-09-05）

Critical（CVSS 10.0）に分類されるKestra Kestra OSS（オープンソースのイベント駆動オーケストレーション基盤）。NVD の適用範囲は 1.0.45 未満、および 1.1.0 以上 1.3.21 未満で、1.0.45 と 1.3.21 で修正されている。の脆弱性です。Kestra OSS の認証フィルタが、パスの判定に**末尾一致**を使っていたために認証が丸ごと回避できる。NVD の記述はこうである。「Kestra はオープンソースのイベント駆動オーケストレーション基盤である。1.0.45 および 1.3.21 より前では、Kestra OSS の AuthenticationFilter が `request.getPath().endsWith("/configs")` を用いて、公開設定エンドポイントを Basic 認証の対象から除外していた。この検査が完全一致ではなく接尾辞の一致であるため、**最後のセグメントが configs である任意の API パスが認証を完全に回避する**。未認証のリモート攻撃者はこれを悪用して、資格情報なしで任意のワークフローを作成・実行できる。Kestra はスクリプト実行プラグイン（plugin-script-shell、plugin-script-python など）を既定で有効にして出荷されているため、これは Kestra ワーカーのコンテナ内での root としての未認証リモートコード実行に直結する。この脆弱性は 1.0.45 および 1.3.21 で修正されている」。 **1行の判定の書き方が、そのまま全開放になっている。**意図は「`/configs` という1本の公開エンドポイントだけを認証の外に置く」ことだった。ところが `endsWith` は文字列の末尾しか見ないので、**攻撃者が自分でパスの末尾を `/configs` に合わせるだけで、任意のエンドポイントが認証の外へ出る**。許可リストの穴ではなく、許可リストの照合方法そのものの誤りである。CWE-184（不完全な危険リストの利用）が付いているのはそのためである。 **なぜ「認証回避」で止まらず「root での RCE」になるのか。**Kestra はワークフロー実行基盤であり、**シェルや Python を実行するプラグインが既定で有効**な状態で出荷される。認証を回避してワークフローを作成・実行できるということは、その中に任意のシェルコマンドを書けるということである。実行主体はワーカーコンテナの root。つまり「API に無認証で触れる」が「コンテナ内で root としてコマンドを実行できる」まで、追加の条件なしに繋がっている。 **CVSS は 10.0 である。**AV:N / AC:L / PR:N / UI:N に加えて **S:C（スコープ変更あり）** で、機密性・完全性・可用性がすべて H。オーケストレーション基盤という位置づけ上、Kestra は各種システムへの接続情報を保持していることが多く、被害は Kestra 単体では終わらない。 **CISA KEV に 2026-09-02 付で収載され、是正期限は 2026-09-05 である。**収載から期限まで3日しかない。これは実際の悪用が確認されている案件に対する短期期限であり、扱いは緊急である。

対応は **Kestra を 1.0.45 または 1.3.21 以上へ更新する**ことである。1.0 系に乗っているなら 1.0.45、1.1 以上 1.3 系なら 1.3.21。**どちらの系統かで上げ先が違う**点に注意する。 **まず、外から触れる状態になっていないかを最優先で確認する。**この欠陥は未認証・ネットワーク経由で成立する。Kestra の UI や API をインターネットへ直接出している構成は、**更新が終わるまでのあいだ、実質的に無認証で root コマンドを実行できる口を公開している**ことになる。更新の段取りに時間がかかるなら、先に経路を閉じる。ロードバランサやセキュリティグループで遮断する、VPN の内側へ入れる、リバースプロキシで `*/configs` にマッチするパスを落とす。最後の手段として、更新まで停止するという判断もありうる重さである。 **リバースプロキシでの緩和には限界があることを理解しておく。**プロキシ側で末尾 `/configs` を落とすのは有効だが、パスの正規化やエンコードの扱いがプロキシと Kestra で食い違えば抜けうる。**これは時間を稼ぐための措置であって、修正の代替ではない。** **更新後は侵害の有無を見る。**確認する順序は3つある。①Kestra のワークフロー一覧に、身に覚えのないフローが作成・実行されていないか（実行履歴も含めて見る）。②アクセスログで、末尾が `/configs` の異常なパス（本来の公開設定エンドポイント以外）への 2xx 応答が無いか。③ワーカーコンテナから外向きに出た通信、および Kestra が保持している各システムの接続情報（DB・クラウド・SaaS の資格情報）の使用状況。**root で任意コードが動きうる欠陥なので、更新は再侵入を防ぐだけであり、既に起きたことは消えない。**疑いがあるなら、Kestra に登録した資格情報は再発行する。 **スクリプト実行プラグインの棚卸しも併せて行う。**既定で有効という設計そのものは変わらない。運用上そのプラグインを使っていないなら、無効化しておけば次に似た欠陥が出たときの被害の上限が下がる。

Kestra Kestra OSS（オープンソースのイベント駆動オーケストレーション基盤）。NVD の適用範囲は 1.0.45 未満、および 1.1.0 以上 1.3.21 未満で、1.0.45 と 1.3.21 で修正されている。 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-49869）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

はい。CISA の既知の悪用された脆弱性カタログ（KEV）に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/09/05 です。早急な対応が推奨されます。