Kestra CVE-2026-49869 - CVSS 10.0 の未認証RCEと、実際に踏まれたマイニング被害

ワークフローオーケストレーターは、定義上「任意のコードを実行するためのサーバー」です。シェルスクリプトも Python も、書いたとおりに走らせるのが仕事です。だからこそ、そこに至る門をひとつ間違えて開けてしまうと、脆弱性の深刻度は一気に天井に張り付きます。

Kestra の CVE-2026-49869 は、まさにその事故でした。CVSS v3.1 は満点の 10.0。原因は認証フィルタのたった1行、パスの判定に完全一致ではなく末尾一致を使っていたことです。結果として、認証情報を一切持たない攻撃者がワークフローを作成し、実行し、その出力を回収できました。しかも公式の docker-compose 構成では、そのワークフローは root 権限かつ Docker ソケットをマウントしたコンテナの中で走ります。

Microsoft は2026年8月26日、AI 基盤を狙った侵害の観測レポートを公開し、そのなかで Kestra 環境への初期アクセスが CVE-2026-49869 の悪用によるものと評価しました。攻撃者はリバースシェルを取り、マウントされた Docker ソケットから他コンテナの環境変数を覗き、最終的に XMRig を仕込んでいます。CISA は2026年9月2日にこの CVE を KEV へ追加し、是正期限を9月5日という異例の短さに設定しました。

この記事では、GitHub Security Advisory、NVD、CISA の KEV フィード、Kestra のソースコードとコミット、Microsoft の観測レポートという一次情報をもとに、何が壊れていたのか、なぜ被害がここまで広がったのか、そして運用側で何をすべきかを整理します。

概要(まず結論)

CVSS ベクタで注目すべきは2か所です。前半の AV:N/AC:L/PR:N/UI:N は「ネットワーク越しに、特別な条件も権限も、利用者の操作すらなく成立する」を意味します。そして S:C(Scope: Changed)。これは脆弱なコンポーネントの権限境界を越えて別のコンポーネントに影響が及ぶことを示す指標です。今回で言えば、Kestra の Worker コンテナの中だけで話が終わらず、マウントされた Docker ソケット経由でホストや他コンテナにまで手が届いてしまう。この S:C があるからこそ、スコアが 9.8 ではなく満点の 10.0 になっています。

CWE が4つも並んでいるのも特徴的です。CWE-287(不適切な認証)が入口で、CWE-184(禁止入力リストの不完全さ)が判定ロジックの欠陥そのもの、CWE-78(OSコマンドインジェクション)が結果、CWE-918(SSRF)が副次的な影響。1つの CVE に脆弱性連鎖がまるごと詰まっている格好です。

Kestra とは何か

Kestra は kestra-io/kestra として公開されている Java 製のオーケストレーターで、リポジトリの説明文は「Event Driven Orchestration & Scheduling Platform for Mission Critical Applications」です。初回作成は2019年8月24日、ライセンスは Apache-2.0。2026年9月9日時点で GitHub のスターは 28,033、フォークは 2,982 でした(GitHub API の stargazers_count で確認)。Airflow や Dagster と並んで名前が挙がる、データパイプライン/ジョブ実行基盤の一角です。

公式のアーキテクチャドキュメントによると、Kestra はステートレスな6つのロールで構成されます。

設計思想としては、コントロールプレーン(Executor / Scheduler など)はユーザーコードを実行せず、データプレーンの Worker だけが実タスクを走らせる分離になっています。バックエンドは既定で JDBC(PostgreSQL / MySQL)、Enterprise 版では Kafka + Elasticsearch なども選べます。

今回問題になったのは、このうちWebserverです。REST API と UI を提供する、外部からいちばん近い場所。ここの認証フィルタが破れると、そのまま Worker にコードを流し込む経路が開通します。

そしてもうひとつ、公式の docker-compose.yml が user: "root" を指定し、かつ /var/run/docker.sock をホストからマウントしている点が効いてきます。ファイル内のコメントには「this setup with a root user is intended for development purpose. Our base image runs without root, but the Docker Compose implementation needs root to access the Docker socket」と明記されており、Kestra 側は開発用途だと言っています。ただ、この docker-compose をそのまま本番に持ち込んだ環境が現実に存在した、というのがこのインシデントの前提条件になります。

影響を受けるバージョンと修正版

GHSA の記載は「1.3.20 以前」です。一方 NVD の CPE 設定はもう少し細かく、「1.0.45 より前」と「1.1.0 以上 1.3.21 より前」の2レンジに分けています。これは Kestra が 1.0 系と 1.3 系を並行して保守しているためで、修正版もそれぞれ 1.0.45 と 1.3.21 の2本立てです。

v1.3.21 のタグは 2026-06-02T18:42:00Z にリリースされています(GitHub Releases API で確認)。GHSA の公開はその翌日、2026年6月3日です。

なお、ほぼ同一内容の別 CVE も存在します。CVE-2026-53576(GHSA-2q47-568g-9h4f)で、CVSS 10.0、CWE-94 と CWE-288、影響バージョンは 1.3.20 以前、修正版は 1.0.45 と 1.3.21。公開時刻は 2026-06-03T07:51:56Z で、CVE-2026-49869 のわずか32秒後です。同じ欠陥に2つの CVE 番号が振られている状態で、KEV に載ったのは 49869 のほうだけでした。資産管理ツールで CVE 番号ベースの照合をしていると、片方だけ潰したつもりになる可能性があります。実体は同じなので、修正版に上げれば両方とも解消します。

タイムライン

GHSA 公開から KEV 入りまで約3か月。その間に Microsoft が実被害を観測しており、「パッチは出ていたが当たっていなかった」環境が刈られたという典型的な経過です。

技術的な中身: endsWith による末尾一致の落とし穴

問題のコード

該当箇所は webserver/src/main/java/io/kestra/webserver/filter/AuthenticationFilter.java の49行目です。

boolean isConfigEndpoint = request.getPath().endsWith("/configs");

この1行が、CVSS 10.0 の正体です。

何をしたかったのか

Kestra の UI は、ログイン画面を描画する前にサーバー側の設定(どの認証方式が有効かなど)を取得する必要があります。そのため GET /api/v1/configs と、テナント付きの GET /api/v1/{tenant}/configs の2つだけは Basic 認証の対象外にしたい、というのが実装の意図でした。

意図そのものは妥当です。問題は判定の方法でした。

何が起きたのか

endsWith("/configs") は、パス全体が /api/v1/configs と等しいかを見ているのではなく、パスの末尾が /configs で終わっているかだけを見ています。つまり、最後のセグメントが configs でありさえすれば、パスの前半に何が書かれていても認証をすり抜けます。

これが CWE-184(Incomplete List of Disallowed Inputs)の教科書どおりの形です。許可リスト方式に見えて、実際には「末尾が /configs」という無限に広い集合を許可していました。

GHSA には、認証を回避できてしまったエンドポイントの例が列挙されています。

Kestra の API は名前空間やフロー ID をパスパラメータとして受け取る設計なので、攻撃者が末尾のセグメントを自由に決められるエンドポイントが大量に存在しました。{namespace} の部分に configs と入れるだけで、そのリクエストは認証フィルタの外に出てしまいます。

最後の行、監査ログの削除が認証なしでできる点は特に厄介です。侵入者が自分の痕跡を消せる、ということですから。

修正の方向性

正しい実装は、完全一致で許可対象を列挙することです。equals("/api/v1/configs") のように、パスそのものを比較する。あるいは、そもそも「パス文字列を見て認証を飛ばす」というアプローチをやめて、ルーティング解決後のコントローラの識別子で判定する。後述のとおり Kestra は最終的に後者の方向へ寄せていきました。

一般化すると、認証・認可の判断に部分一致(startsWith / endsWith / 正規表現の緩い書き方 / contains)を使わないという原則になります。ここは完全一致か、構造化された識別子でしか判断してはいけない場所です。似た構図は Starlette の CVE-2026-48710 でも起きていて、あちらは「同じパスをルーターとミドルウェアが別々に解釈した」という不一致が原因でした。文字列を材料に認可を決める処理は、それだけで危険地帯だと考えたほうがいいです。

なぜ認証バイパスが即RCEになるのか

認証バイパスは、それ自体では「情報が見える」で止まることも多い脆弱性です。ところが Kestra の場合、認証を抜けた瞬間にコード実行が確定します。理由は3つあります。

1つ目は、Kestra が既定でスクリプト実行プラグインを同梱していること。 Shell、Python、Node、Bash をはじめ80種類以上のプラグインが最初から入っています。つまりフロー定義に io.kestra.plugin.scripts.shell.Commands タイプのタスクを書けば、それはシェルコマンドとして実行されます。これは脆弱性ではなく、Kestra の中核機能です。

2つ目は、フローの作成と実行が API 経由で完結すること。 ワークフローエンジンなので当然ですが、YAML を PUT して POST で走らせるだけで済みます。ファイルをアップロードする必要も、管理画面を操作する必要もありません。

3つ目は、公式 docker-compose 構成では Worker が uid=0(root) で動くこと。 権限降格の工程が要らないので、攻撃者は最初から root として作業できます。

GHSA に記載された攻撃手順は、この3つを素直につないだだけの3ステップです。

1. PUT /api/v1/main/flows/tutorial/configs にシェル実行タスクを含む YAML フローを送る(認証不要)
2. POST /api/v1/main/executions/tutorial/configs でそのフローを実行する(認証不要)
3. GET /api/v1/main/logs/search?executionId=... で実行ログを取得し、コマンドの出力を回収する

3リクエストです。特別なガジェットチェーンもメモリ破壊も不要で、製品の正規機能を認証なしで呼んでいるだけ。だから AC:L(攻撃条件の複雑さ: 低)であり、自動化も容易です。

そして皮肉なのがここからです。Kestra OSS は 0.24.0 以降で Basic 認証が必須になっており、kestra.server.basic-auth.username と .password を設定しないと起動できません(enabled フラグは無視されます)。つまり認証をきちんと有効にしていた運用者ですら、このフィルタ不備の前では素通しでした。「認証を設定してあるから大丈夫」という判断が通用しなかった、という点がこの脆弱性のいちばん怖いところです。

副次的な影響: Pebble テンプレートの SSRF

CWE-918 が付いているのは、Kestra が採用しているテンプレートエンジン Pebble の HttpFunction に URI のフィルタリングが無かったためです。テンプレート内から任意の URL に HTTP リクエストを飛ばせるので、169.254.169.254 のクラウドメタデータエンドポイントや、外から届かない内部サービスに到達できます。こちらは後日 CVE-2026-73247 として別途採番されました(CVSS 8.6)。

未認証でフローを作れる状態と組み合わせると、「認証なしで内部ネットワークをスキャンし、IAM の一時クレデンシャルを引き抜く」という動きが成立します。

実際に何が起きたか - Microsoft の観測

Microsoft は2026年8月26日、When AI infrastructure becomes the target: Securing gateways and control points という記事で、AI 基盤を狙った複数の侵害事例を公開しました。そのうち1件が Kestra です。

初期アクセス

Microsoft は「initial access likely occurred through exploitation of CVE-2026-49869」と評価しています。未認証のリモート攻撃者がログイン機構を回避し、Process runner を使う悪意あるワークフローを定義して、Worker 側でシェルスクリプトを実行させた、という流れです。GHSA が示した攻撃手順そのままです。

リバースシェル

ワークフローを起点とするシェルセッションが2つ、近接した時刻で観測されています。1つ目はシェルの初期化、2つ目が主要な後続動作を担っていました。通信先として 172.232.38.92:32991(Linode の VPS)が IOC として公開されています。

Docker ソケットの悪用

ここが被害を広げた分岐点です。攻撃者は侵害された環境の内部から、マウント済みの Docker ソケットにアクセスしました。行ったのはコンテナメタデータの照会と、コンテナ環境変数配列の検査です。

Docker の API はコンテナの inspect 結果に環境変数をそのまま含めます。多くの環境で、環境変数には DB のパスワード、API キー、クラウドのアクセスキーが入っています。つまり Kestra を1つ落としただけで、同じホストに同居する他コンテナのシークレットがまとめて読める状態になりました。Microsoft のレポートでも、他コンテナの環境変数由来の値が露出したと記載されています。

クリプトマイニング

最終的な収益化はコインマイナーでした。挙動は次のとおりです。

• 公開リリース元からマイナーを取得
• アーカイブを展開
• バイナリをリネーム(名前ベースの検知を回避するため)
• バックグラウンドで実行
• マイニングプールと通信

RandomX / XMRig に典型的な CPU チューニング挙動が観測され、バージョンは XMRig v6.26.0。マイニングプールは auto.c3pool.org:443 です。Monero のプールで、443番ポートを使うため通常の HTTPS 通信に紛れます。

防御回避のテクニック

2つ、実務上おさえておきたい手口があります。

1つ目は curl の出力をそのままシェルにパイプするパターン。 リモートのスクリプト内容を独立したファイルとして書き出さず、シェルが直接取得して実行します。ディスク上にスクリプトのアーティファクトが残らないため、ファイルベースの検知やフォレンジックがすり抜けます。

2つ目は、収集結果を Kestra 自身の key-value インタフェース経由で保存したこと。 エンコードして KV ストアに置くことで、これも独立したファイルアーティファクトへの依存を減らしています。侵害された製品の正規機能を、そのままデータ保管庫として使うわけです。EDR から見ると「Kestra が KV ストアに書いている」という正常な動作にしか見えません。

MITRE ATT&CK でのマッピング

公開されている IOC

Microsoft のブログに記載されている指標は次の4つです。

• 172.232.38.92:32991 - リバースシェルの C2(Linode VPS)
• auto.c3pool.org:443 - Monero マイニングプール
• 2001:41d0:701:1100::adfd
• 47.86.197.116

なお Microsoft は特定の脅威アクター名への帰属を行っていません。ブログ本文に名称の記載はありません。

同じレポートに載っている LiteLLM の事例

このレポートは Kestra 単体の記事ではなく、AI 基盤3件の侵害をまとめたものです。LiteLLM 側では CVE-2026-42271 と CVE-2026-48710 を連鎖させて XMRig を配送し、PostgreSQL の LiteLLM_ProxyModelTable と LiteLLM_VerificationToken からモデル設定と API 資格情報を窃取、~/.ssh/authorized_keys を改変して永続化する、という別チェーンが記載されています。

Kestra も LiteLLM も、「認証境界を1つ破れば、その先に他システムの資格情報が集積している」という共通の構造を持っています。Microsoft が推奨として「AI ゲートウェイを Tier-0 のシークレットストアとして扱え」と書いているのは、まさにこの点です。

Docker ソケットという増幅装置

CVE-2026-49869 が CVSS 10.0 になった理由、S:C の実体を掘り下げておきます。

/var/run/docker.sock は Docker デーモンの UNIX ソケットです。これをコンテナ内にマウントするということは、そのコンテナにホストの Docker デーモンを操作する全権限を渡すことと同義です。認証機構はありません。ソケットに書ける = 管理者です。

ソケットが取れると、次のことができます。

• 全コンテナの一覧と inspect(環境変数、マウント情報、ネットワーク設定がすべて見える)
• 任意のイメージから新しいコンテナを起動する
• 新しいコンテナに --privileged を付ける、あるいはホストの / をマウントする
• 結果として、ホストのファイルシステムを読み書きできる

つまり Docker ソケットのマウントは、コンテナによる分離をほぼ無効化します。コンテナの分離が namespace と cgroups という Linux カーネルの機能で成り立っていることは コンテナの分離を支える namespace と cgroups にまとめていますが、その分離の外側にある「デーモンへの通信経路」を渡してしまえば、カーネルの機能は何も守ってくれません。

Kestra が Docker ソケットを必要とするのは、Docker タスクランナーでタスクをコンテナとして起動するためです。機能としては理解できます。ただ、公式の docker-compose.yml がコメントで「開発用途」と明示しているとおり、本番環境でこの構成を使うことは想定されていません。Microsoft が観測した被害は、この開発用構成が本番に持ち込まれた結果として広がりました。

パッチは1回で終わっていない

ここが本記事でいちばん伝えたい点です。1.3.21 で endsWith の問題は直りましたが、同じ認証フィルタに対するバイパスはその後2回、追加で修正されています。

2026年8月28日: d20ae5a7d5

コミットメッセージは "fix(webserver): gate open-urls prefix matching on the resolved route's identity"。認証を回避するエンドポイントの許可リスト(open-urls)の照合を、パスのプレフィックス一致ではなく解決済みルートの識別子に基づいて行うよう変更したものです。文字列照合から構造的な判定へ、という正しい方向の修正です。

2026年9月7日: 108472ae45

コミットメッセージは "fix(iam): unauthenticated RCE via encoded-separator filter evasion"。タイトルにはっきり「未認証RCE」と書かれています。内容は次のとおりです。

AuthenticationFilter は /api/v1 配下を対象とする Ant パターンに登録されていました。ところが Micronaut は、パターンマッチングを生の(percent-encoded の)リクエストターゲットに対して行います。そのため /api/v1%2Fsecrets のようなターゲットは2セグメントとしてトークン化され、Ant パターンに一致しません。結果、認証フィルタが一切実行されない状態になります。

一方で TenantAliasingRooter は同じターゲットをデコードし、テナントスコープのパスへ書き換えたうえで、そのままコントローラへディスパッチしていました。つまり「フィルタから見えないが、コントローラには届く」パスが存在したわけです。

修正では、フィルタの登録を Filter.MATCH_ALL_PATTERN に変更してすべてのリクエストに適用し、生パスとデコード/正規化後のパスの両方でゲートするようにしました。

この構図、既視感があります。Starlette の CVE-2026-48710 も「ルーターとミドルウェアが同じリクエストを別々に解釈した」ことが原因でした。同じ入力を複数のレイヤーが別々にパースすると、その差分が認可の穴になるという、繰り返し現れるパターンです。

このコミットが参照しているアドバイザリ GHSA-rjhm-qm6w-m7x9 は、2026年9月9日時点でまだ非公開(URL は404)で、対応する CVE 番号も確認できていません。詳細が出るまでは、とにかく最新版に上げる以外の判断材料がありません。

2026年の Kestra 関連アドバイザリ一覧

単発の CVE の話ではない、ということを示すために、2026年に公開された Kestra 関連のアドバイザリを並べます(いずれも GitHub Advisory 由来)。

CVE-2026-55069 は、BasicAuth のパスワードが SHA-512 で保存されていてオフライン総当たりが現実的だった、という問題です。2026年6月15日のコミット 881321d8fb で bcrypt に置き換えられました。SHA-512 は高速なハッシュなので、パスワード保存には向きません。

こうして並べると、個別のバグというより認証境界の設計そのものが十分に固まっていなかったことがわかります。半年で認証まわりのアドバイザリが7本というのは、そういう水準です。

同日KEV追加の7件が示すもの

CISA は2026年9月2日、7件をまとめて KEV に追加しました(アラート)。Kestra はそのうちの1件です。

構図を読み取ると、次の2点が見えます。

1点目、7件中5件が「認証の回避 / 未認証到達」です。 Kestra、LiteLLM、JFrog Artifactory、Starlette、Switchvox。メモリ破壊でも複雑な連鎖でもなく、「入れてはいけない人が入れる」という一番単純な失敗が5件を占めています。実際に悪用されるのは、難しい脆弱性ではなく自動化しやすい脆弱性です。

2点目、うち Kestra・LiteLLM・Starlette の3件はデータ/AI 基盤の OSS コンポーネントです。 ネットワーク機器のように資産台帳に載っているものではなく、依存ツリーの奥やコンテナイメージの中に紛れています。SBOM が無いと、そもそも「自社に入っているか」を答えられません。Starlette に至っては、KEV の notes で「他製品に組み込まれる第三者ライブラリ」として明示的に注記されています。

Kestra、JFrog Artifactory、SonicWall SMA1000 の3グループが是正期限9月5日、Starlette と LiteLLM が9月16日という差も示唆的です。前者は「直接インターネットに面していて、単発リクエストで制御を奪える」もの。詳細はそれぞれ JFrog Artifactory CVE-2026-82329 と SonicWall SMA1000 の連鎖ゼロデイ にまとめています。

CISA の requiredAction は「ベンダー指示に従って緩和し、BOD 26-04(Prioritizing Security Updates Based on Risk)および Forensics Triage Requirements に準拠すること。緩和策がなければ製品の使用を中止すること」です。KEV レコード上の vendorProject は Kestra、product は Kestra OSS、vulnerabilityName は "Kestra OSS OS Command Injection Vulnerability"、knownRansomwareCampaignUse は Unknown となっています。

6年前のAirflowとの相似

この事故、まったく同じ構造の前例があります。Apache Airflow です。

CISA は2022年1月18日、Airflow の2件を同時に KEV へ追加しました。

前者はAirflow に同梱されるサンプル DAG にコマンドインジェクションがあったという話。後者はExperimental API の既定設定が認証なしだったという話です。この2つを組み合わせると、Airflow 1.10.10 では未認証でのリモートコード実行が成立しました。修正は 1.10.11 へのアップグレード、load_examples=False によるサンプル DAG の無効化、そして [api] auth_backend = airflow.api.auth.backend.deny_all の設定です。

Kestra との相似は明白です。

「既定で同梱される実行可能な仕組み」と「認証の既定値または実装のミス」が掛け算になると未認証RCEになる。この方程式が6年経ってそのまま再演されています。違いは、Airflow の場合は設定値の問題だったのに対し、Kestra は認証を有効にしていても効かなかった点です。その意味では Kestra のほうが悪質です。

ワークフローエンジンという製品カテゴリは、本質的に「任意コード実行サービス」です。だから認証境界は他の製品より厳しく設計されなければならないし、運用側も「インターネットに直接出す種類のものではない」と最初から扱うべきものです。

対応手順

1. アップグレードする

1.0.45 または 1.3.21 以降へ上げます。ただし前述のとおり、2026年8月28日と2026年9月7日にも追加のバイパス修正が入っているため、可能な限り最新版にしてください。1.3.21 は「CVE-2026-49869 に対する修正版」であって「認証フィルタが安全になったバージョン」ではありません。

稼働中のバージョンは UI のフッター、/api/v1/version、あるいはコンテナイメージのタグで確認できます。

2. open-urls の設定を見直す

kestra.server.basic-auth.open-urls は、認証をバイパスするエンドポイントを明示的に列挙する設定です(設定ドキュメント)。ここに広いパターンを書いていると、それ自体が穴になります。運用の都合で追加した項目がないか、棚卸ししてください。

3. Docker ソケットをマウントしない、root で動かさない

被害を増幅した最大の要因です。

• /var/run/docker.sock を Worker コンテナにマウントしない
• user: "root" をやめる。Kestra のベースイメージは非 root で動くと公式ドキュメントに明記されています
• 公式 docker-compose.yml をそのまま本番に流用しない(コメントに「開発用途」と書かれています)

Docker タスクランナーがどうしても必要な場合は、rootless Docker や、専用の隔離ホストを使う設計に切り替える判断が要ります。

4. Webserver をインターネットに直接晒さない

既定の8080番ポートを外部に開放しない。VPN や社内ネットワーク、あるいは認証付きのリバースプロキシの内側に置きます。

暫定的な緩和としては、リバースプロキシで末尾が /configs のパスを外部から到達不能にするという手もあります。ただしこれは CVE-2026-49869 にしか効かず、2026年9月7日に修正されたエンコード済み区切り文字のバイパスには無力です。あくまでアップグレードまでの時間稼ぎです。

5. 管理/actuator ポートも閉じる

CVE-2026-73245 のとおり、ポート8081の管理エンドポイント(/env、/loggers など)は API の basic-auth をバイパスします。8080だけ塞いで安心しないでください。CVE-2026-73246 では未認証の /worker エンドポイントが実行中タスクの設定と平文の資格情報を露出していました。

6. SSRF 対策としてメタデータへの経路を塞ぐ

CVE-2026-73247(Pebble の SSRF)に対しては、クラウド側の設定で対処します。

• AWS なら IMDSv2 を強制する(IMDSv1 を無効化する)
• 169.254.169.254 への egress を遮断する
• 出口通信は原則 deny-by-default にし、必要な宛先だけ許可する

Microsoft の推奨事項にも「アウトバウンドを deny-by-default にする」が挙がっています。マイニングプールへの接続も、リバースシェルの C2 への接続も、出口が閉じていれば成立しません。

7. 侵害確認

パッチを当てるだけでは、すでに入られていた場合の対応になりません。以下を確認します。

• 身に覚えのないフロー・実行の有無。名前空間やフロー ID に configs が含まれるものは特に疑わしいです
• KVストアへの不審な書き込み。エンコードされた値が置かれていないか
• ログ削除の痕跡。監査ログが認証なしで削除できたため、「ログに何もない」ことは安全の証明になりません
• Microsoft 公開 IOC との通信。172.232.38.92、auto.c3pool.org、2001:41d0:701:1100::adfd、47.86.197.116
• ホストの CPU 使用率異常。マイナーは分かりやすく CPU を食います。ただしリネームされているため、プロセス名での検索は当てになりません
• 同居コンテナのシークレット。Docker ソケットをマウントしていたなら、同じホスト上の全コンテナの環境変数が読まれた前提でローテーションします
• BasicAuth のパスワード。CVE-2026-55069 の対象期間(SHA-512 保存時代)に設定したものなら、bcrypt 化後に再設定します

侵害が疑われる場合、いちばん確実なのはコンテナを破棄して作り直すことです。ファイルとして痕跡を残さない手口が使われているため、「怪しいファイルが見つからなかった」は根拠になりません。

恒久対策として考えたいこと

1つ目は、認証・認可の判断に部分一致を使わないこと。 endsWith も startsWith も contains も、認証をスキップする条件の判定に使ってはいけません。許可対象は完全一致で列挙するか、ルーティング解決後のハンドラ識別子で判断する。Kestra が2026年8月28日のコミットで向かったのが、まさにこの方向です。

2つ目は、同じ入力を複数のレイヤーで別々にパースしないこと。 フィルタは生パス、ルーターはデコード済みパス。この差分が2026年9月7日のバイパスを生みました。Starlette の CVE-2026-48710 も同じ構造です。正規化は入口で1回だけ行い、以降は正規化済みの値だけを回す設計にします。

3つ目は、実行基盤を「任意コード実行サービス」として扱うこと。 Kestra、Airflow、Jenkins、Langflow、n8n。これらは全部、認証を抜かれた瞬間に RCE になる製品です。同じ性質のものとして Langflow の未認証RCE CVE-2026-9198 も KEV 入りしています。この種のサーバーはインターネットに直接出さない、というのを最初のルールにするだけで、KEV の何割かは自分に関係のない話になります。

4つ目は、シークレットを環境変数に置かない設計を検討すること。 Docker ソケットからの環境変数窃取が成立したのは、シークレットが環境変数にあったからです。Secrets Manager や Vault から実行時に取得する、あるいはファイルマウントにして権限を絞る、といった選択肢があります。少なくとも「1つのコンテナが落ちたら全部のシークレットが漏れる」構成は避けたいところです。

5つ目は、SBOM と資産棚卸し。 今回の KEV 7件のうち3件は OSS のライブラリ/コンポーネントでした。「自社に Kestra はあるか」「Starlette のバージョンは何か」に即答できない状態だと、KEV が出ても動けません。国内でも同じ課題は繰り返し表面化しており、2026年 日本のセキュリティインシデントまとめ で追っています。

一次情報で確認できなかった事項

以下は本稿執筆時点で一次情報にあたっても確認できませんでした。断定を避け、未確認として記載します。

• 悪用が始まった時期。「2026年6月末(late June 2026)」という記述は The Hacker News の報道由来で、Microsoft のブログ本文からは日付を確認できていません。Microsoft は時期を明示していないため、本稿では「6月末」を事実として扱っていません。
• 2026年9月7日の追加修正に対応するアドバイザリの詳細。GHSA-rjhm-qm6w-m7x9 は2026年9月9日時点で非公開(URL は404)であり、対応する CVE 番号・影響バージョン・修正版は確認できていません。
• 被害組織数と具体的な被害事例。Microsoft のレポートには組織名も件数も記載がありません。
• 攻撃者の帰属。Microsoft は特定の脅威アクター名を挙げていません。
• インターネットに露出している Kestra インスタンスの数。信頼できる一次計測値は確認できませんでした。
• kestra.io ドメイン上の独立したセキュリティ告知ページ。発見できませんでした。公表窓口としては GitHub Security Advisories が実質的な一次情報になっています。

まとめ

• CVE-2026-49869 は Kestra の認証フィルタが request.getPath().endsWith("/configs") という末尾一致でバイパス判定していたことに起因する未認証RCE。CVSS v3.1 は満点の 10.0
• 最後のセグメントが configs でありさえすれば認証を素通しできたため、フローの作成・実行・KV書き込み・監査ログの削除まで認証なしで可能だった
• Kestra は既定でスクリプト実行プラグインを同梱しているため、認証バイパスがそのままコード実行になる。攻撃は3リクエストで完結する
• 皮肉なことに、Kestra OSS は 0.24.0 以降で Basic 認証が必須。認証を有効にしていた運用者でもこのフィルタ不備の前では無防備だった
• S:C(Scope: Changed)が付いた実体は Docker ソケット。公式 docker-compose は user: "root" かつ /var/run/docker.sock をマウントしており、コメントで開発用途と明記されている
• Microsoft は Kestra 環境の初期アクセスを本 CVE の悪用と評価。リバースシェル取得、Docker ソケット経由での他コンテナの環境変数の窃取、XMRig v6.26.0 によるマイニングが観測された
• 防御回避として、curl の出力を直接シェルにパイプする手法と、収集結果を Kestra 自身の KV ストアにエンコードして保存する手法が使われた。ファイルの痕跡が残らない
• 修正版は 1.0.45 / 1.3.21 だが、2026年8月28日と2026年9月7日にも認証フィルタのバイパス修正が入っている。9月7日のものはコミットメッセージに「unauthenticated RCE」と明記されており、対応するアドバイザリは執筆時点で非公開
• 2026年だけで Kestra には認証まわりのアドバイザリが7本。単発のバグではなく認証境界の設計の問題として捉えるべき
• 2026年9月2日の KEV 追加7件のうち5件が認証の回避/未認証到達。うち3件はデータ/AI 基盤の OSS で、SBOM が無いと資産棚卸しすらできない
• 6年前の Apache Airflow(CVE-2020-11978 と CVE-2020-13927)とほぼ同じ構造。「既定で同梱される実行可能な仕組み」と「認証の不備」の掛け算

やることは3つです。最新版へ上げる。Docker ソケットのマウントと root 実行をやめる。Webserver と管理ポートをインターネットから外す。そのうえで、身に覚えのないフローと実行履歴を一度確認してください。ログが消されている可能性があるので、「何も無かった」で終わらせないことが大切です。

参考リンク

• Kestra 公式サイト
• GitHub: kestra-io/kestra
• Kestra Docs: Architecture
• Kestra Docs: Security and Secrets(open-urls 設定)
• Kestra Docs: v0.24.0 移行ガイド(Basic 認証の必須化)
• Kestra 公式 docker-compose.yml
• GitHub Security Advisory: GHSA-5vc5-wxxq-3fjx(CVE-2026-49869)
• GitHub Security Advisory: GHSA-2q47-568g-9h4f(CVE-2026-53576)
• GitHub Security Advisory: GHSA-r56g-q4p6-m3p6(CVE-2026-73247 SSRF)
• GitHub Security Advisory: GHSA-m65f-q5gj-hg46(CVE-2026-73246)
• GitHub Security Advisory: GHSA-hpj9-grjp-7vc7(CVE-2026-73245)
• GitHub Security Advisory: GHSA-m727-pcjm-j28h(CVE-2026-55069)
• GitHub Security Advisory: GHSA-365w-2m69-mp9x(CVE-2026-34612)
• GitHub: 2026-09-07 の修正コミット 108472ae45
• NVD: CVE-2026-49869
• CVE.org: CVE-2026-49869
• CISA: CISA Adds Seven Known Exploited Vulnerabilities to Catalog(2026-09-02)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: KEV JSONフィード
• CISA: BOD 26-04 Prioritizing Security Updates Based on Risk
• Microsoft Security Blog: When AI infrastructure becomes the target
• The Hacker News: CISA Adds Seven Exploited Flaws
• CWE-78: OS Command Injection
• CWE-184: Incomplete List of Disallowed Inputs
• CWE-287: Improper Authentication
• CWE-918: Server-Side Request Forgery
• JFrog Artifactory CVE-2026-82329 の認証バイパス（当ブログ）
• Starlette CVE-2026-48710 の Host ヘッダ問題（当ブログ）
• SonicWall SMA1000 の連鎖ゼロデイ（当ブログ）
• コンテナの分離を支える namespace と cgroups（当ブログ）
• Langflow の未認証リモートコード実行 CVE-2026-9198（当ブログ）
• 2026年 日本のセキュリティインシデントまとめ（当ブログ）