consul-k8sに認可回避―別の名前空間からConsul権限を取得するおそれ
システムACL管理を有効にした構成が対象。CVE-2026-110720は1.8.18・2.1.0で修正されました。
HashiCorpの公式公表日:2026-10-26 / 公開: / 更新: / 最終確認:
Codingholic 編集部 · 約2分
HashiCorpは2026年10月26日、Kubernetes上でConsulを運用するためのconsul-k8sに、名前空間をまたぐ認可回避CVE-2026-110720があると公表しました。修正版は1.8.18と2.1.0です。対象はシステムACL管理を有効にした構成で、同機能が無効ならこの問題の影響は受けません。
原因は、Consulの権限を割り当てる規則が、認証するServiceAccountをConsulの配置先の名前空間へ十分に限定していなかったことです。別の名前空間でも、Consulコンポーネントとして認証され、その権限を取得できる可能性があります。
攻撃には、別の名前空間でServiceAccountを作成してトークンを取得できるKubernetes権限と、Consul APIへのネットワーク接続が必要です。インターネットから誰でも無条件に管理者になれるという説明ではありません。公式告知には実悪用の確認は記載されていません。
管理者はglobal.acls.manageSystemACLsの値、consul-k8sの導入版、利用者に与えたServiceAccount作成権限を確認してください。影響する旧版は対応する修正版へ更新します。ただし公式リリースノートによると、過去に有効化してから無効化したコンポーネントの古い認証規則は、更新時に書き換わりません。該当する場合は公式手順に沿った古い規則の削除、またはコンポーネントを再度有効にして更新する対応も必要です。
出典と編集について
HashiCorp:HCSEC-2026-50:Consul-k8s cross-namespace authorization bypass ↗consul-k8s 2.1.0:更新時に残る古い認証規則の注意事項 ↗
consul-k8s 1.8.18:同じ更新時の注意事項 ↗
本記事は公表資料に基づく速報です。判明した範囲を記載しており、続報で内容が変わる場合があります。