検索NeSC を見る
脆弱性・CVE速報深刻度: 緊急

Go の Web フレームワーク Echo のプロキシで、WebSocket の接続要求を拒否された後の通信が経路ごとの認可を素通りする不具合（CVE-2026-118264）: v4 は 4.16.1 未満、v5 は 5.4.1 未満が対象

World Security 編集部
目次（5）

CVE-2026-118264

Go 言語の Web フレームワーク Echo のプロキシ機能（Proxy ミドルウェア）に、認証・認可の確認をすり抜けられる不具合（CVE-2026-118264、GHSA-cxf3-9h37-7rr8）が公開されました。GitHub の深刻度は Critical、GitHub 提供の CVSS v4.0 は 9.1 です。修正版は v4 系が 4.16.1、v5 系が 5.4.1 です。ただし、悪用には条件がそろう必要があります（下の「影響を受ける条件」を参照）。

何が起きるか

  • 利用者が WebSocket への切り替え（アップグレード）を求めると、Echo のプロキシは、転送先が受け入れたかを確かめる前に「生のトンネル」を選んでしまいます（勧告の説明）。
  • 転送先がその要求を普通の HTTP 応答で断り、接続を切らずに保った場合、同じ接続で続けて送られた HTTP 要求は、Echo のルーターや経路ごとのミドルウェアを通らず、そのまま同じ転送先に届きます。
  • そのため、認証や認可を Echo の経路側だけで行っている場合、それを回避されるおそれがあります。
  • 勧告によると、任意のホストへの中継ができるようになるわけではなく、転送先自身の認証も回避できません。
  • CISA の整理（SSVC）は、悪用 none（確認なし）、自動化 yes、技術的影響 total です（NVD 経由で確認）。CISA の KEV には載っていません（10/31 時点）。

影響を受ける条件

項目内容
対象github.com/labstack/echo/v4 の 4.0.0 以上 4.16.1 未満、echo/v5 の 5.0.0 以上 5.4.1 未満
修正版v4.16.1、v5.4.1（どちらも 10/22 UTC に公開。勧告は 10/23 UTC）
弱点CWE-444（HTTP 要求の解釈の不一致）、CWE-863（不適切な認可）
評価GitHub 提供の CVSS v4.0 は 9.1（ネットワーク・低複雑度・権限不要・ユーザー操作不要。攻撃の前提条件あり）。CVSS v3 の値はなし
CVECVE-2026-118264
NVDUndergoing Analysis（NVD 自身の評価はまだ。上の数値は第三者の提供）
EPSS0.43%（10/31 時点、パーセンタイル 37.2%）
KEV掲載なし（10/31 時点）

悪用に必要な条件（勧告の記載）は、次の 3 つです。

  1. 外から届くプロキシの経路があること。
  2. 転送先が、アップグレード要求を接続を切らずに断ること。
  3. 転送先の対象リソースに、転送先自身の認可がないこと。

転送先の側で認可を行っていれば、この不具合で守りが破られることはありません。

修正の中身

勧告によると、修正版は WebSocket のアップグレードも Go 標準のリバースプロキシ経由にし、転送先から正しいアップグレード応答が返ってから初めてトンネルに入ります。断られた要求は、普通の HTTP 要求のままです。

修正コミットは v4 が 3fb0ba7、v5 が 1855061 です（どちらも 10/22 UTC）。v4 のコミットでは、middleware/proxy.go から生のトンネルを扱う処理（proxyRaw）が取り除かれ、WebSocket の要求も通常のプロキシ処理に回るようになっています。また、Forwarded ヘッダーを転送先に渡さない変更も含まれます。v4 のコミットには、同じ時期に修正された別の勧告（本体ダンプの制限、解凍サイズの上限など）の変更もまとめて入っています。この記事では CVE-2026-118264 に関する部分だけを扱います。両方のコミットが、それぞれのタグ（v4.16.1、v5.4.1）に含まれることは、タグとの比較で確認しました（コミットはタグより前で、タグの側が 1 コミット先）。

対応

  1. Echo を、v4 系は 4.16.1 以上、v5 系は 5.4.1 以上に更新します（2026-10-31 時点の最新タグは v4 系が v4.16.3、v5 系が v5.4.4）。
  2. すぐ更新できない場合は、影響を受けるプロキシの経路に届く前に、WebSocket のアップグレード要求を拒否します。または、転送先の各リソースで独立して認可を行います（勧告の回避策）。
  3. 転送先が非 101 の応答を返すだけでは、この問題は防げません（勧告の記載）。
  4. Echo のプロキシを使っているかどうかは、middleware.Proxy や ProxyWithConfig の利用箇所で確認できます（本記事の推定）。

未確認の点

  • 悪用の報告は確認できていません。KEV にも載っていません。
  • NVD は自身の評価をしていません。CVSS v4.0 の 9.1 は第三者の提供で、CVSS v3 の値はありません。
  • 勧告は v4.0.0 から影響ありとしています。実際の動作確認は v4.15.0、v4.16.0、v5.0.0、v5.4.0 で行われたと書かれており、それ以外の版は、ソースの履歴に基づく記載です。
  • 日付は、タグ・リリースは Git と GitHub の記録、勧告の公開日は GitHub の記載に基づきます。
  • 実際の環境での再現は行っていません。記載は勧告、修正コミット、NVD に基づきます。

この記事について

出典

この記事を共有

この記事の Markdown 版（LLM向け） ↗

関連記事