HashiCorpは、consul-k8sに存在するネームスペース間の認可回避の脆弱性を公表しました。Kubernetes上で限定的な権限しか持たない攻撃者が、Consulの上位権限を取得できる可能性があります。
この脆弱性は「CVE-2026-110720」として追跡されています。システムACLの自動管理が有効な場合に、アクセス制御リスト（ACL）のバインディングルールというコンポーネントに影響します。HashiCorpは2026年10月26日にセキュリティアドバイザリ「HCSEC-2026-50」を公開し、consul-k8sのバージョン1.8.18と2.1.0で修正しました。
HashiCorp Consulの脆弱性
影響を受けるのはconsul-k8sの0.42.0から2.0.4までのバージョンで、1.8.18は修正済みリリースとして明記されています。影響の有無は設定に左右されます。`global.acls.manageSystemACLs=true`としているデプロイメントは影響を受けますが、システムACLの管理を無効にしている場合は脆弱ではありません。
脆弱性アセスメントツール
システムACLの管理が有効な場合、consul-k8sはKubernetes認証とConsulのACLバインディングルールを構成します。このルールにより、ConsulのコンポーネントはまずKubernetesのServiceAccountで認証を行い、割り当てられたロールに紐づくConsulトークンを取得します。これは、各コンポーネントのKubernetes上のIDを、Consul上の対応する権限に結びつける仕組みです。
脆弱性が生じる原因は、コンポーネント用のバインディングルールが、認証できるServiceAccountをConsulのデプロイ先と同じKubernetesネームスペースのものに一貫して限定していなかったことにあります。そのため、別のネームスペースで作成されたServiceAccountが、コンポーネントの認証ルールを満たし、本来そのコンポーネントに与えられるはずの権限を取得できる可能性があります。
これは、認証が無制限に回避される問題ではなく、ネームスペースをまたいだ認可の不備です。攻撃者はまず、別のネームスペースでServiceAccountを作成し、そのトークンを取得できるKubernetes権限を持っている必要があります。
加えて、ConsulのAPIにネットワーク経由でアクセスできることも条件となります。これらを満たす攻撃者は、Consulのコンポーネントとして認証され、関連する権限を得る恐れがあります。
想定される影響は、誤って認可されたコンポーネントIDを通じて、Consul内で上位のアクセス権を得られることです。ただしアドバイザリは、対象となる具体的なコンポーネントのロールや、悪用で取得できる権限の一覧を示していません。影響を受けるすべてのデプロイメントで管理者権限を完全に奪取できるとも確認していません。記載されている結果は、なりすましたコンポーネントに紐づく権限へのアクセスにとどまります。
この違いは、リスクを見積もるうえで重要です。別のネームスペースでのKubernetes権限は攻撃の前提条件の一部にすぎず、攻撃者がすでにConsulのネームスペースを掌握していることを意味するわけではありません。一方、脆弱なバインディングルールが攻撃者の管理するIDを受け入れてしまうと、この欠陥によってネームスペースの境界が越えられてしまいます。
HashiCorpは、利用者に対して自社の影響範囲を評価したうえで、consul-k8sを2.1.0または1.8.18へアップグレードするよう呼びかけています。影響を受ける環境を調べる管理者は、システムACLの自動管理が有効かどうか、またアドバイザリに記載されたServiceAccountとConsul APIへのアクセスという前提条件が満たされているかどうかを確認する必要があります。これらはアドバイザリが示す条件に直接関わる確認事項です。
HashiCorpは、この脆弱性を報告したセキュリティ研究者としてElias Hasas氏（GitHubではzer0d4y5として知られる）の名前を挙げています。アドバイザリにはCVSSスコアも、悪用状況に関するテレメトリも、実際の悪用を確認した記載もありません。そのため、これらの点は現時点で明らかになっていません。
SOCにアラートの文脈を提供し、インシデントを迅速に止めましょう。16,000のSOCの脅威インテリジェンスを統合。
翻訳元: https://gbhackers.com/hashicorp-consul-vulnerability/
