Kuberoに認証バイパスの脆弱性、JWT鍵未設定の環境が危険
Kubero 3.0.0から3.1.1に、JWT_SECRETを設定していない環境でログインなしに管理者権限を奪われる脆弱性があります。社内にKuberoがあるか、版とJWT_SECRETの設定状況を確認してください。
急ぎ度: 至急
CVSS v3は9.8、v4は9.3で、認証なしにネットワークから管理者権限を奪える脆弱性が2026年11月9日に公表されたばかりです。
関係があるか
Kubernetes上でKuberoを自前運用している組織が対象です。JWT_SECRETを設定していない環境で、Kuberoの画面やAPIにネットワークから届くなら、優先して調べてください。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Kubero(kubero-dev) | 3.0.0から3.1.1まで | 修正版の版番号は、確認できた資料に記載がありません。ベンダーの告知で確認してください。 |
確かめ方
- 1Kuberoを入れたクラスターで、kubero-uiのイメージタグから版を調べます。3.0.0から3.1.1なら対象の版です。
- 2kubero-uiのDeploymentの環境変数や参照しているSecretに、JWT_SECRETがあるかを確認します。値そのものはログやチャットに出さないでください。
- 3JWT_SECRETが未設定なら、この脆弱性の条件に当てはまります。
- 4開発部門や検証用に、情報システム部門が把握していないKuberoが立っていないかも、クラスターごとに探します。
何が起きたか
Kubero 3.0.0から3.1.1に、ログインしていない第三者が管理者として振る舞えてしまう認証バイパスの脆弱性があります。2026年11月9日に公表されました。
Kuberoは、ログイン後の利用者を示すトークン（JWT）を署名の鍵で守っています。ところがJWT_SECRETが未設定だと、ソースコードに書き込まれた既定の鍵に切り替わります。ソースは公開されているため、この鍵は誰でも知り得ます。種類としてはCWE-321（ハードコードされた暗号鍵の使用）です。
さらに、サーバー側はトークンに書かれた役割や権限をデータベースで照合せずに信用します。偽のトークンが署名の検証を通ると、そのまま管理者として扱われます。
悪用されると、パイプライン、アプリケーション、ユーザー、APIトークンを乗っ取られます。
攻撃の流れ
-
1
画面やAPIに到達
Kuberoの画面やAPIにネットワーク経由で届く位置から始まります。
-
2
既定の鍵を利用
JWT_SECRETが未設定の環境では、ソースに書かれた既定の鍵で署名したトークンが有効になります。
-
3
偽の管理者トークン
役割や権限を自由に書いたトークンを作られます。
-
4
照合なしで受理
サーバーはデータベースで確認せず、トークンの記述を信用します。
-
5
管理操作を奪取
パイプライン、アプリ、ユーザー、APIトークンを操作されます。
どう悪用されるか
ログインは要りません。ネットワークから画面やAPIに届けば試せて、利用者の操作も複雑な条件も要りません。CVSSの攻撃条件も、ネットワーク経由、認証不要、操作不要です。前提になるのは、対象の版で、JWT_SECRETが未設定のままになっている環境です。
成功すると、管理者として振る舞えます。パイプラインやアプリケーションの設定を書き換えられ、ユーザーの追加や変更、APIトークンの操作もできます。Kuberoは、アプリの配備先であるクラスターの運用を担っています。管理者権限を奪われると、そこで動く業務アプリにも影響が及ぶと考えるのが安全です。
今すぐやること
-
1
Kuberoの稼働状況を洗い出す
社内のクラスターでKuberoを動かしている場所を特定し、インターネットや広い社内ネットワークから画面とAPIに届くかを確認します。
kubectl get deploy -A -o wide | grep -i kubero -
2
版とJWT_SECRETの設定を確認する
版が3.0.0から3.1.1で、JWT_SECRETが未設定のインスタンスを最優先にします。設定済みの場合も、版は対象のままなので次の手順に進みます。
-
3
JWT_SECRETを設定する
未設定のインスタンスには、推測されにくい長いランダムな値を設定して再起動します。既定の鍵で署名されたトークンは、再起動後は使えなくなる見込みです。
-
4
修正版の公開を確認して更新する
Kuberoの公式リポジトリのリリースとIssue #786で、修正版の版番号を確認します。公開されていれば、検証してから更新します。
-
5
侵害の跡を調べる
対象環境が外から届く状態だったなら、心当たりのないユーザー、パイプライン、アプリ、APIトークンの変更や追加を調べます。見つかったら、APIトークンを再発行し、関係する認証情報も入れ替えます。
修正版がないあいだのつなぎ
修正版を当てられないうちは、JWT_SECRETに推測されにくい長いランダムな値を設定します。あわせて、KuberoのUIとAPIへの経路を、VPNや許可したIPアドレスに限ります。インターネットに公開しているなら、その公開を止めるのがもっとも確実です。
背景
Kuberoは、Kubernetes上で動くセルフホスト型のPaaSです。Herokuのように、開発者がKubernetesに詳しくなくてもアプリを配備できることをうたっています。パイプラインを作り、ステージングや本番にアプリを載せ、アドオンやWebコンソール、スケジュール実行まで、画面から管理します。データは追加のデータベースを使わず、Kubernetesのetcdに保存されます。
そのため、Kuberoの管理者権限は、配備の仕組み全体を握る権限に近いものです。今回の脆弱性は、署名の鍵をコードに埋め込んだことが原因です。署名付きトークンは、鍵が秘密だからこそ信用できます。既定の鍵が公開ソースにあるなら、未設定の環境は鍵が公開されているのと同じです。しかも、受け取ったトークンの内容をデータベースで照合しないため、署名を通れば権限まで信用されます。
よくある質問
Q.Kubernetesを使っているだけでも対象になりますか。
Q.JWT_SECRETの値はどう決めればよいですか。
まだ分かっていないこと
- VulnCheckの勧告には、修正版の版番号が載っていません。
- 実際の攻撃で悪用されたかどうかは、勧告に触れられていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| kubero-devkubero |
3.0.0 〜 3.1.1→ 記載なし |
記載なし |
この記録には修正版の版が載っていません。修正版の有無と版は、本文か参照URLのベンダーの勧告で確かめてください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Kubero 3.0.0 through 3.1.1 contains an authentication bypass vulnerability that allows unauthenticated remote attackers to forge administrative JWTs by using a hardcoded fallback signing secret when JWT_SECRET is unset. Attackers can sign tokens with arbitrary role, userGroups and permissions claims, which JwtStrategy.validate() trusts without a database lookup, to take control of pipelines, applications, users and API tokens.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory vulncheck.com
- advisory nvd.nist.gov
- advisory github.com
- package github.com
- report github.com
- web github.com
- web github.com