HashiCorpは、同社のConsul Kubernetes連携にセキュリティ脆弱性があると公表しました。この脆弱性を悪用されると、攻撃者が名前空間（namespace）の境界を越え、Consulの昇格した権限を取得する可能性があります。
この脆弱性は「CVE-2026-110720」として追跡されています。システムのACL管理を有効にしたconsul-k8sのデプロイ環境で、コンポーネントのアクセス制御リスト（ACL）バインディングルールに影響します。HashiCorpは2026年10月26日にセキュリティアドバイザリ「HCSEC-2026-50」を公開し、影響を受ける顧客向けに修正版を案内しています。
アドバイザリによると、影響を受けるのはconsul-k8sの0.42.0から2.0.4までのバージョンです。修正はバージョン1.8.18と2.1.0で提供されています。権限昇格のリスクがあるものの、アドバイザリにはCVSSスコアの記載がなく、重大度が「Critical」であるとも明示されていません。
問題の原因は、Kubernetesのアイデンティティ（ID）とConsulの権限を結び付けるルールにあります。システムのACL管理を有効にすると、consul-k8sはKubernetes認証とConsulのACLバインディングルールを構成します。
これらのルールにより、インフラ構成要素はKubernetes ServiceAccountで認証し、割り当てられたロールに対応するConsulトークンを取得できます。
本来この関連付けは、コンポーネントの権限を適切なIDだけに限定するためのものです。しかしHashiCorpの調査で、コンポーネントのバインディングルールが、ConsulをホストするKubernetes名前空間内のServiceAccountだけに認証を限定していない場合があると判明しました。
この名前空間の制限が欠けているため、本来は分離されているはずのKubernetes名前空間の間で、認可の境界が機能しなくなります。
別の名前空間でServiceAccountを作成し、そのトークンを取得できる攻撃者は、インフラ構成要素になりすましてConsulに認証できる可能性があります。
悪用を成功させるには、Consul APIへのネットワークアクセスも必要です。認証に成功すれば、攻撃者はなりすましたコンポーネントに紐づく権限を得られます。
公表された影響は、Consulの権限が昇格することにとどまります。Kubernetesクラスター全体の乗っ取りが可能になるとは、明確には記載されていません。また、HashiCorpは、対象となるコンポーネントのロールや、そこから得られるポリシー上の権限、悪用で到達し得る最大権限を具体的に示していません。
そのため、実際の影響の大きさは、攻撃者がどのコンポーネントのIDになりすませるか、そのIDにどのような権限が付与されているかによって変わります。
この問題は、特にglobal.acls.manageSystemACLs=trueで構成した環境に影響します。HashiCorpによると、システムACL管理を無効にしたデプロイ環境は、この脆弱性の影響を受けません。
被害を受けるかどうかを判断するうえで、この設定の違いは重要です。対象バージョンのconsul-k8sを使っているだけでは、脆弱な認証設定が有効になっているとは限りません。
HashiCorpは、利用者にリスクを評価したうえで、consul-k8s 2.1.0または1.8.18へのアップグレードを検討するよう勧めています。
対応の緊急度を判断する管理者は、アドバイザリに記載された前提条件を考慮する必要があります。特に、Consulのデプロイ先の名前空間外にいるユーザーが、ServiceAccountを作成してトークンを取得し、Consul APIに到達できるかどうかが焦点になります。
アドバイザリは、この脆弱性の報告者として、セキュリティ研究者のElias Hasas氏（GitHubでの名前はzer0d4y5）の名を挙げています。エクスプロイトコードや侵害の痕跡（IoC）は含まれておらず、実際の攻撃で悪用されたことを確認する記載もありません。
防御側がまず取り組むべきは、影響を受ける構成を特定し、修正版を適用することです。名前空間を分離しているだけで、Kubernetesのアイデンティティが意図しないConsulのロールを取得できなくなると考えるのは禁物です。
16,000以上のSOCチームがANY.RUNを導入し、脅威調査の効率化と手作業の削減を実現しています。チームで試してみる
翻訳元: https://cyberpress.org/critical-hashicorp-consul-kubernetes-flaw/
