Consulのサービス登録でEnvoy設定の権限チェックを回避できる脆弱性

HashiCorpは2026年10月26日、Consulのサービスメッシュ登録で権限チェックを回避できるCVE-2026-105608を公表した。ACLを有効にし、プロキシと宛先サービスへのservice write権限を利用者へ渡している一方、mesh write権限は渡していない環境が対象になる。該当する運用者は、修正版への更新と、既存のプロキシ登録内容の点検を優先したい。

問題は、通常のサービス登録を任せた利用者が、本来は追加の権限を必要とする生のEnvoy設定をサイドカーへ適用できることだ。開発元は、当該プロキシ内でのコード実行、処理する通信へのアクセスや改変、そのプロキシでのintentionによる制御の回避につながり得るとしている。インターネット上の誰もが認証なしに実行できる脆弱性として扱うものではない。

対象はACLで登録権限を分離している構成

影響と修正方針はHashiCorpのセキュリティ告知HCSEC-2026-47、評価値と公開時刻はCVE Programの公式CVEレコードで確認した。

開発元の告知HCSEC-2026-47が挙げる影響版と修正版は次のとおり。製品名が似ていてもCommunityとEnterpriseの更新先を混同せず、稼働版とサポート系列を照合する必要がある。

製品	告知に記載された影響版	修正版
Consul	2.0.4	2.1.0
Consul Enterprise	2.0.4・1.22.12・1.21.18	2.1.0 または 1.21.19

この表は開発元が明示した版を転記したものだ。記載されていない過去の版を一律に安全と判定したり、Enterpriseの全系列に同じ更新先があると読み替えたりしない。とくに1.22.12を運用している場合、告知は同系列の修正版を挙げていないため、利用可能な更新経路と互換性を確認して移行計画を決めたい。

公式CVEレコードに掲載された本件のCVSS v3.1は8.8（High）で、ベクトルはAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H。攻撃者に低い権限が必要という評価であり、権限分離の有無が優先順位を決める。外部公開の有無だけで対象外にせず、社内の開発者や自動デプロイ用の資格情報にどこまで登録を許しているかを確認する。

設定を認識する処理と権限を調べる処理がずれた

Consulはプロキシサービスの登録でEnvoyの生の設定を受け取り、通常はConsulが生成する設定の一部を置き換えられる。開発元がescape hatchと呼ぶこの仕組みは、サイドカーの通信処理を変更できるため、service writeだけでなくmesh writeも必要とする。サービス登録を担当する主体と、メッシュの通信設定を変える主体を分離するための境界である。

今回の不具合では、権限チェックが認識する設定キーの表記が、後段の設定処理で受け付ける表記より少なかった。意味が等しい別表記のキーを登録すると、権限チェックでは対象として認識されないのに、後段ではEnvoy設定として適用され得た。公式レコードはCWE-178（大文字・小文字の区別の不適切な処理）に分類している。

重要なのは、単に任意のサービス名を登録できるという話ではない点だ。攻撃者が対象プロキシと宛先サービスへのservice writeを持つこと、mesh writeは持たないこと、ACLが有効な配置であることが告知の条件になる。その組み合わせで、本来許していない設定変更が通る。利用者が正規に使える登録経路も、入力を信用できるとは限らない。

影響の説明もプロキシ単位で読む必要がある。開発元は当該サイドカーでの任意設定と、そのプロキシが扱う通信への影響を示している。これだけでメッシュ全体やConsulサーバーの完全侵害が確定するわけではない。一方、認証や機密情報を扱うWebサービスのサイドカーが対象なら、アプリケーション本体を変更せず通信へ作用できる点が重大になる。

まず版と登録主体を同じ一覧にする

以下の棚卸し・確認方法は、本サイトによる運用上の提案である。HashiCorpが公式に示した代替回避策や、本サイトで実測した結果ではない。根本対策は開発元が案内する修正版への更新として扱い、一時的な権限制限だけで解消済みにしない。

最初に、Consulの稼働版、CommunityかEnterpriseか、ACLの有効状態、サービス登録を行う主体を一つの台帳で突き合わせる。アプリ開発者の対話操作だけでなく、CI/CD、起動時の自動登録、構成管理など、実際に登録を書き込む経路を列挙する。リポジトリに残る定義だけでは、現在登録されている状態を説明できないことにも注意したい。

次に、各主体のトークンに結び付くポリシーやロールを調べ、対象プロキシと宛先サービスへのservice writeが許される範囲を確認する。mesh writeを与えていないことを安全の根拠にしていた環境ほど、この脆弱性との関係が深い。トークンの秘密値を一覧や調査メモへコピーせず、管理用の識別情報と権限の対応で確認を進める。

優先度が高いのは、複数チームへ登録権限を分散し、通信設定の管理を別チームへ集中させている環境や、機密性の高いサービスをそのサイドカー経由で提供している環境だ。共通のデプロイ資格情報が広範囲のサービスを書ける場合も影響範囲を広く見る。信頼済み管理者だけが登録する環境では条件の現実性が変わるが、更新不要という意味にはならない。

更新までの暫定措置と更新後の確認を分ける

更新までの間は、不要なservice writeを減らし、登録APIへ到達できる主体や、未レビューのプロキシ登録変更を絞ることを検討する。ただし、これは露出を減らす提案であり、告知にない完全な回避策として保証できない。通常のデプロイやサービス再起動が登録を必要とする場合、制限が可用性へ与える影響も事前に確認する。

登録エラーを解消するためにmesh writeを全利用者へ追加すると、守りたい権限の境界そのものを広げてしまう。ACLを無効にする対応も避けるべきだ。必要な利用者へ必要な範囲を許す方針を維持し、権限チェックの不具合をソフトウェア更新で修正する。登録用資格情報の配布先も、更新作業と合わせて整理したい。

更新は、告知の修正版を取得するだけで完了とせず、実際に利用する構成で稼働版を読み戻して確認する。更新対象や順序、Enterpriseの系列移行に伴う互換性は、自社構成とサポート条件に沿って決める。本件の告知だけから独自のローリング更新手順を作り、本番での無停止を保証することはできない。

検証環境では、通常の登録を担当する主体と、Envoyの上書き設定を管理する主体を分けて確認する。前者の通常登録は成功し、mesh writeを持たない主体の上書き設定は拒否され、意図して管理権限を持つ主体の操作だけが認められることを確かめる。成功する管理者操作だけでは権限境界の回復を確認したことにならない。

実際に使用する登録経路や設定の表記を試験対象に含めることも大切だ。公式の機能仕様に基づく無害な検証用設定を使い、本番の通信や機密データを試験へ持ち込まない。期待する拒否と、通信経路やアプリの疎通が維持されることを別々に記録する。特定の試験が通っただけで、すべての設定表記を網羅できたとは判断しない。

登録済みの設定と通信への影響も点検する

更新によって今後の不正な登録が拒否されても、それ以前に登録された設定が自動的に正常化されるとは、告知には書かれていない。更新後は、現在のプロキシ登録にある生のEnvoy設定を承認済みの定義と照合し、意図しない上書きや、変更理由を説明できない項目がないか確認する。単なる差分の存在と侵害の証拠は区別する。

不審な変更がある場合は、修正前に登録内容、関連するデプロイ履歴、利用可能な操作記録を保全する。誰がいつ登録したか、どのサービスの通信を扱っていたかを追い、影響し得る期間と範囲を絞る。開発元告知には固有の侵害指標や検知クエリは提示されていないため、特定文字列が見つからないことを悪用されていない証拠にはしない。

当該プロキシ内でのコード実行や通信改変が疑われるなら、パッケージ更新だけで調査を閉じない。状況に応じてプロキシの再作成、登録内容の復元、到達できた秘密情報の評価や資格情報の変更を検討する。これらは侵害の兆候と影響範囲に応じた対応であり、すべての導入環境でコード実行が起きたとするものではない。

対応の完了条件は、修正版の稼働、登録権限の再確認、権限がない操作の拒否、既存登録の妥当性、サービス疎通を確認できた状態に置くとよい。更新済みという一点だけで終了すると、権限の配布範囲や以前の設定変更が取り残される。運用者とアプリ担当者で、誰がどの確認を引き受けたかまで記録しておきたい。

また、サービス登録を外部の自動化へ委任している場合は、委任先の管理者と確認結果を共有する。自社で設定ファイルを変更していなくても、別の登録経路が上書きしていれば状態が戻る可能性がある。正しい定義を一度投入して終えるのではなく、その定義を維持する主体と変更承認の流れまで確認することが、更新後の再点検を有効にする。

公表日と悪用状況の読み方

開発元の初回公表日は2026年10月26日。公式CVEレコードの公開時刻は同日17時52分UTCで、日本時間では10月27日2時52分に当たる。レコードの更新時刻は初回公表とは別の情報として扱う。本記事で確認した開発元告知には実環境での悪用確認は記載されておらず、悪用の有無は不明としている。

既存の権限を持つ主体が通信設定へ踏み込める問題なので、脆弱性の点数だけでなく、自社がどの主体へ登録を委ねているかを判断材料にしたい。Webアプリの更新担当者にとっても、サイドカーの制御がアプリの安全性を支えている構成では直接関係する。サービスの登録権限と通信ポリシーの管理権限を分けた設計を、修正版と実際の登録状態の両方で守ることが今回の対応になる。