Go製WebフレームワークEchoのProxyミドルウェアにCVSS 9.1の重大脆弱性。WebSocket切り替え拒否後のHTTP通信がルーターや認証ミドルウェアを迂回する条件、影響バージョン、修正版と対処を一次情報から整理。
30秒でわかる / THE SIGNAL
Echo v4.0.0以上v4.16.1未満、v5.0.0以上v5.4.1未満にCRITICAL（CVSS 9.1）の脆弱性。特定のプロキシ構成では、WebSocketへの切り替えが拒否された後のHTTP要求がEchoの認証・認可ミドルウェアを通らず転送され得る。v4.16.1／v5.4.1以上へ更新したい。
「認証を実装したのに守られない」可能性
2026年10月22日、Go製WebフレームワークEchoの開発元は、Proxyミドルウェアにおける重大なアクセス制御回避の脆弱性GHSA-cxf3-9h37-7rr8を公表した。深刻度はCRITICAL、CVSS 9.1。Echoのルート単位で認証・認可を実施している構成では、特定条件でその保護を通らず上流サーバーへHTTP要求が届く可能性がある。
一次情報：https://github.com/labstack/echo/security/advisories/GHSA-cxf3-9h37-7rr8
何が起きるのか｜WebSocket切り替え拒否後の通信
問題は、EchoのProxyミドルウェアがクライアントからWebSocketへのアップグレード要求を受けた際、上流サーバーが切り替えを承認したか確認する前に、生の通信トンネルを選択していたことにある。上流が通常のHTTP応答で切り替えを拒否し、接続を維持すると、その後のHTTP要求がEchoのルーターやルート別ミドルウェアを経由せず、同じ上流へ直接転送され得る。
成立には、外部から到達できるProxyルート、アップグレードを拒否しても接続を閉じない上流、上流側で独立した認可がない対象リソースなどの条件が必要だ。すべてのEchoアプリで認証が突破されるわけではなく、上流自身の認証を回避するものでもない。任意のホストへ転送できる問題でもない。
影響バージョンと修正版
影響するのはgithub.com/labstack/echo/v4のv4.0.0以上v4.16.1未満、およびgithub.com/labstack/echo/v5のv5.0.0以上v5.4.1未満。最初の修正版はv4.16.1とv5.4.1だ。利用中のメジャー系列でこれら以上の修正版に更新する。修正後は、上流の有効なアップグレード応答を確認してからトンネルへ移行する。
公式v4リリース：https://github.com/labstack/echo/releases/tag/v4.16.1 公式v5リリース：https://github.com/labstack/echo/releases/tag/v5.4.1
今すぐ確認したい対策
まずGoの依存関係からEchoのメジャー系列とバージョンを確認し、影響範囲なら修正版以上へ更新する。Proxyミドルウェアの利用有無、WebSocketアップグレードを受ける経路、上流サーバー側の認証・認可の実装を点検したい。更新までの暫定策として、影響するProxyルートに届く前にWebSocketアップグレード要求を拒否するか、上流の各リソースに独立した認可を設ける方法が案内されている。上流が単にHTTP 101以外を返すだけでは十分な回避策にならない。
現時点で参照した公式勧告に、実際の攻撃で悪用されたという確認情報は示されていない。技術的に悪用可能な条件と、攻撃観測・侵入成功は区別する必要がある。
WORK SIGNALの視点｜認証の境界はどこにあるか
この脆弱性が示すのは、認証機能を『導入済み』であることと、すべての通信経路で認証が『必ず適用される』ことは違うという点だ。リバースプロキシ、フレームワークのミドルウェア、上流アプリケーションのどこでアクセスを制御するかを明確にし、例外的なプロトコル切り替えでも境界が保たれるか検証する必要がある。技術担当者だけでなく、サービス運営者も、依存ライブラリの更新責任と緊急対応の連絡経路を把握しておきたい。