Consul-k8sに認可回避の脆弱性、修正版あり
Kubernetes上でConsulを動かすconsul-k8sに、名前空間をまたいだ認可の回避により、Consulで高い権限を得られる脆弱性が見つかりました。0.42.0以降を使っている組織が対象で、修正版が出ています。まず自社の版を確認し、早めに更新してください。
急ぎ度: 早めに
CVSS v3は9.9で重大度はcriticalですが、修正版が公開されている一方で実際の悪用を示す情報はなく、至急ではなく早めの更新が妥当です。
関係があるか
KubernetesクラスターにConsulを組み込み、consul-k8sで管理している組織が対象です。名前空間をチームごとに分けて共用しているクラスターは、とくに確認を優先してください。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| consul-k8s | 0.42.0以降で、修正版より前の版。上限は2.0.4未満とする情報もあります | 2.1.0と1.8.18。パッケージ情報では2.0.4とされています |
確かめ方
- 1Helmでconsul-k8sを入れている場合は、
helm list --all-namespacesでConsulのリリースを探し、チャートとアプリの版を確認します。 - 2マニフェストやGitOpsのリポジトリで、consul-k8sのイメージタグまたはチャートの版を検索し、0.42.0以降かどうかを見ます。
- 3ConsulのACLでバインディングルールを使っているかを、管理担当者に確認します。使っていない環境が影響を受けるかは、ベンダーの告知（HCSEC-2026-50）で確認してください。
何が起きたか
Consul-k8sに、別の名前空間に対する認可の確認をすり抜けられ、Consulで本来より高い権限を得られる脆弱性が見つかりました。
問題があるのは、consul-k8sのコンポーネントが使うACLバインディングルールです。分類はCWE-863（認可の不備）で、0.42.0以降の版が対象になります。
HashiCorpが2026年10月26日に、HCSEC-2026-50として公表しました。CVSS v3のベクターはAV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hです。
攻撃の流れ
-
1
低い権限を持つ
クラスターやConsulに対して、一般的な利用者レベルの権限を持つ者が出発点になります。
-
2
認可の確認を回避
ACLバインディングルールの不備により、別の名前空間への認可の確認を越えられます。
-
3
Consulの権限が上がる
本来与えられないはずの高い権限をConsulで得られます。
-
4
影響が広がる
機密性・完全性・可用性のすべてに大きな影響が及び、脆弱なコンポーネントの外にも被害が広がりえます。
どう悪用されるか
ネットワーク経由で悪用でき、複雑な条件は要りません。利用者の操作も不要です。ただし、何らかの低い権限をすでに持っていることが前提になります。
CVSSでは、影響が脆弱なコンポーネントの範囲を越えて及ぶ（スコープの変更）と評価されています。悪用に成功すると、Consulの情報の読み取り、設定や権限の書き換え、サービスの停止のいずれにも至りえます。サービス登録や通信制御をConsulに任せている環境では、その上で動くアプリケーション群にも影響します。
今すぐやること
-
1
使っている版を洗い出す
開発・検証・本番のすべてのクラスターで、consul-k8sの版を確認します。複数のクラスターや名前空間に分散して入れている場合は、漏れが出やすいところです。
helm list --all-namespaces -
2
修正版に更新する
対象の版を使っていれば、修正版に更新します。まず検証環境で動作を確認し、そのあと本番へ順に進めます。どの版に上げるかは、ベンダーの告知で確認してください。
-
3
ACLの設定と権限を見直す
更新と並行して、バインディングルールの設定と、Consulに接続できるアカウントや認証情報を棚卸しします。想定外の権限付与がないかも確認します。
-
4
監査ログで不審な操作を探す
公開日より前から、権限の変更や名前空間をまたぐ操作が記録されていないかを見ます。Consulの監査ログが有効でなければ、ほかのログで代用できるかを確認します。
すぐ更新できないとき
公式の回避策とは別に、被害の幅を狭める一般的な手当てがあります。更新が遅れる間は、Consulに接続できる認証情報を持つ利用者と、Kubernetesの名前空間に対する権限を絞り、不要なものを外してください。
背景
consul-k8sは、Kubernetes上でConsulを動かすための連携ツールです。Consulはサービスの登録と発見、サービス間通信の制御、設定の共有を担います。連携の基盤にあたるため、ここで権限が破られると、その上で動く複数のアプリケーションに影響が及びます。
ConsulのACLは、サービスや名前空間ごとに、どこまで読み書きしてよいかを決める仕組みです。認可の不備が名前空間の境界をまたぐと、チームごとに分けた権限の区切りが意味をなさなくなります。今回の脆弱性は、そのACLのうち、コンポーネントに割り当てる権限の決め方に関わっています。
よくある質問
Q.社内の限られた人しかクラスターに触れない環境でも、対象になりますか。
まだ分かっていないこと
- 修正版が2.1.0と1.8.18なのか、2.0.4なのか、公表情報の間で食い違いがあります。更新先を決める前に、HashiCorpの告知（HCSEC-2026-50）で確認してください。
- 実際の悪用が確認されているか、攻撃コードが出回っているかは、公表されていません。
- どの設定のバインディングルールが影響を受けるのかは、公表されていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| HashiCorp | Tooling |
0.42.0 以上 2.0.4 未満 |
2.0.4 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Consul-k8s versions 0.42.0 and later are vulnerable to a cross-namespace authorization bypass in component ACL binding rules that may allow an attacker to obtain elevated Consul privileges. This vulnerability (CVE-2026-110720) is fixed in consul-k8s 2.1.0 and 1.8.18.
出典: CVE.org (CVE Program・cvelistV5) NVD