JVN（Japan Vulnerability Notes）は、Envoy ProxyのEnvoyにおいて、認可判断に非正規化されたURLパスを使用する脆弱性を公表した。本脆弱性により、アクセス制御を回避される可能性があるため、影響を受ける構成では修正版への更新が推奨される。CVE番号、CVSSスコア、影響を受ける具体的なバージョンおよび修正版の詳細は、参照先のアドバイザリで確認する必要がある。
脆弱性の詳細
Envoyには、認可（アクセス許可）の判定に用いるURLパスの扱いに不備があり、認可処理とルーティングなど後続処理との間で、URLパスの解釈が一致しない場合がある。攻撃者がパスを細工すると、本来は拒否されるべき要求が許可されるなど、アクセス制御が期待どおりに機能しない可能性がある。
本脆弱性は、認可判断に使用されるパスと、実際にリソースへ到達する際に解釈されるパスが異なることに起因する。攻撃者は、URLパスの表記を細工して判定と到達先の差を利用し、保護されたパスへのアクセスを試みる可能性がある。外部公開されたAPIゲートウェイ、リバースプロキシ、サービスメッシュなどでEnvoyを使用している場合は、構成によって影響が大きくなり得る。
攻撃の成立条件や影響は、Envoyの配置、認可方式、ルーティングおよびパス書き換えの設定、前段のロードバランサやWAFの有無などに依存する。特に、URLパスに基づいて許可または拒否を判断している環境では、認可処理とバックエンド側のパス解釈が一致しているかを確認する必要がある。具体的な攻撃ベクタ、前提条件、CVE番号およびCVSSスコアは、参照先アドバイザリの記載を確認すること。
影響を受ける製品・バージョン
- Envoy ProxyのEnvoy（参照先アドバイザリに記載された影響バージョン）
影響を受ける具体的なバージョン範囲および修正版のバージョンは、現時点で参照先アドバイザリの詳細確認が必要である。
推奨される対策
- 最新版への更新：Envoyの提供元が案内する修正版へ更新する。更新前には互換性を検証し、可能な限り速やかに本番環境へ反映する。
- 設定の棚卸し：パスベースの認可ルール、ルーティング、リライト、パスの正規化・デコード処理および認可フィルターの設定を確認する。
- 回避策の適用：修正版を直ちに適用できない場合は、Envoyの提供元または参照先アドバイザリが案内する回避策を適用する。独自に対策する場合は、許可条件を厳格化し、意図しないパス表現を受け付けない構成を検討する。
- 監視とログ確認：更新までの間、URLエンコード、ドットセグメント、スラッシュの表記揺れなど、不自然なパスを含むアクセスを監視する。ただし、ログだけで悪用の有無を断定することはできない。
日本の中小企業が今すぐ取るべき行動
- Envoy利用の有無を確認：API基盤、Kubernetes、サービスメッシュ、リバースプロキシ、クラウドマネージドサービスの構成にEnvoyが含まれるかを確認する。
- バージョンと設定を把握：稼働中のEnvoyのバージョン、認可方式、パスベースのアクセス制御、ルーティング、リライトおよびデコード処理の有無を一覧化する。
- 更新可否の判断と実施計画：影響バージョンに該当する場合は、検証環境で修正版を確認した上で、本番反映の担当者、手順および期限を決める。
- 公開範囲の再確認：インターネットから到達可能なサービス、社外公開API、管理系エンドポイントおよび不要な経路を確認し、必要に応じてアクセス元を制限する。
- 暫定的な監視強化：更新までの間、該当経路のアクセスログと認可ログを集約し、不自然なパス表現や拒否対象への繰り返しアクセスを確認する。
CSRIからの現場アドバイス
本件では、認可を判定する処理と、最終的にリソースへ到達させる処理でURLパスの解釈が一致しているかが重要になる。Envoyの前段、認可フィルター、ルーティング、バックエンドのそれぞれで、パスの正規化やデコードが異なる設定になっていないかを確認したい。
実務上は、同一のリソースを指し得る複数のパス表現を検証し、許可・拒否の判定と実際の到達先が一致するかを確認する。ただし、本番環境で無計画に攻撃用リクエストを送信せず、検証環境または承認済みの診断手順で実施すること。
まずEnvoyの利用有無とバージョンを確認し、影響バージョンに該当する場合は修正版への更新計画を立てる。更新まで時間を要する場合は、公開範囲の縮小、パスベース認可ルールの見直し、ログ監視の強化を行い、修正版の適用後に設定とアクセス制御が意図どおり機能することを再確認する。