Go製フレームワークEchoのProxyミドルウェアに脆弱性、WebSocketの切り替えを断られた接続でルートの認証を回避されるおそれ。govulncheckで出ない間の確かめ方

EchoのProxyミドルウェアは、利用者がWebSocketへの切り替え（アップグレード）を求めると、上流のサーバーが受け入れたかを確かめる前に、接続をそのまま中継する方式（生のトンネル）に切り替えていました。上流が通常のHTTP応答を返して接続を保ったままにすると、その接続で続けて送られるHTTPリクエストは、Echoのルーターやルートごとのミドルウェアを通らずに、同じ上流へ直接届きます。[1]

このため、Echoのルートだけで行っている認証・認可を回避されるおそれがあります。Echoは、任意のホストへ中継できるわけではなく、上流自身の認証を回避するものでもないと説明しています。修正版では、アップグレードをGoの標準のリバースプロキシで扱い、上流が正しく受け入れたときだけ中継に切り替えます。断られたアップグレードは通常のHTTPリクエストのままです。[1]

Echoのアドバイザリは、悪用には次の3つがそろう必要があるとしています。Proxyミドルウェアを使っていないアプリは、この脆弱性の対象になりません。[1]

• 外部から届くルートに、Proxyミドルウェア（middleware.Proxy・middleware.ProxyWithConfig）を置いている
• 上流のサーバーが、アップグレードを断っても接続を閉じない
• 狙われる上流のリソースが独自の認可を持たず、Echoのルートでの確認に頼っている

影響を受ける版について、Echoはv4・v5の全系列で生のトンネルの実装があったとし、v4.15.0・v4.16.0・v5.0.0・v5.4.0で再現を確かめ、v4.0.0のソースにも同じ確認の抜けがあると書いています。[1]

11月1日に確かめた時点で、米CISAの悪用が確認された脆弱性の一覧（KEV、10月30日版）には載っていません。CVEの記録に米CISAが付けた評価（SSVC、10月30日）も、悪用は「なし」です。[3][4]

Echoのアドバイザリには再現を確かめた版の記載がありますが、攻撃のコード（PoC）は載っておらず、公開されたPoCも確認できませんでした。今後30日に悪用される見込みの推定（EPSS）は0.43%です（10月31日時点）。深刻度は、EchoとCVEの採番機関のGitHubの評価でCVSS 4.0の9.1（緊急）です。NVDは11月1日時点で分析中で、独自の値を付けていません。[1][5][6]

今回の脆弱性は4.16.1と5.4.1で直ります（どちらも10月23日公開）。ただ、4.16.1の時点ではv4に、クライアントが送ったIPのヘッダーを信頼してしまう2件（CVE-2026-118651、CVE-2026-118653）が残っていました。この2件はEchoのv4.16.3のリリースノートで修正済みとされています（GitHub Advisory Databaseの修正版の欄は、11月1日時点で空欄です）。v5は5.4.3で別の問題（GHSA-v97q-3xf5-rj74）が直り、5.4.4でProxyのX-Real-IPの扱いがさらに直されています。[2][7][8][9]

推奨する版は、Echoのアドバイザリ・リリースノートと、Goのモジュールのプロキシ（proxy.golang.org）で公開済みの版から出しました（11月1日確認）。更新の前に、Echoのリリースノートで変更点を確かめてください。[2][7][10]

1. 間接的な依存も含めて、v4・v5のどちらが何の版で入っているかを確認します。

   ターミナル

   go list -m all | grep labstack/echo

2. Proxyミドルウェアを使っている箇所を探します。見つからなければ、この脆弱性の対象ではありません（他の修正のために上げることは勧めます）。

   ターミナル

   grep -rn 'middleware.Proxy' --include='*.go' .

3. v4を4.16.3に上げる場合は、Goの版が1.26以上かを確かめます。プロキシの裏で動かしているなら、先にIPExtractorを設定します。

   ターミナル

   go version
   grep -rn 'IPExtractor' --include='*.go' .

4. 推奨する版へ上げ、go.mod・go.sumを整えます（使っている系列の行を実行します）。

   ターミナル

   go get github.com/labstack/echo/v4@v4.16.3
   go get github.com/labstack/echo/v5@v5.4.4
   go mod tidy

5. テストを通したあと、組み上がったバイナリに記録された版を確かめます。コンテナイメージの中のバイナリでも同じ確認をします。

   ターミナル

   go list -m github.com/labstack/echo/v4 github.com/labstack/echo/v5
   go version -m ./app | grep labstack/echo

Echoのアドバイザリが挙げる回避策は次の2つです。[1]

• 影響するProxyのルートに届く前に、WebSocketのアップグレード要求を拒否する
• 上流の各リソースで、Echoとは別に認可を行う

上流から101以外の応答を返すようにするだけでは、問題の中継は防げないと書かれています。WebSocketを使っていないProxyのルートなら、前段のロードバランサーやEchoの手前のミドルウェアでUpgradeヘッダー付きの要求を断る形が、1つめの回避策に当たります。[1]

4.16.3では、Echo#IPExtractorを設定していない場合、Context.RealIP()がX-Forwarded-For・X-Real-IPを使わず、接続元のアドレスを返すように変わりました。Proxyミドルウェアが上流へ送るX-Real-IPも、この値で置き換えます。[7][10]

ロードバランサーなどの裏で動かしているアプリは、設定しないまま上げると、利用者全員がプロキシのアドレスに見えます。回数制限、IPによるアクセス制限、ログに影響するため、Echoは上げる前に、自社のプロキシだけを信頼するIPExtractor（ExtractIPFromXFFHeaderかExtractIPFromRealIPHeaderにTrustIPRangeを指定）を設定するよう求めています。プロキシを置かない場合はExtractIPDirect()を使います。v5は5.4.4でもこの移行は要りません。[7][9][10]

Goの脆弱性データベース（vuln.go.dev）には、11月1日時点でEchoのv4が3件（GO-2021-0051・GO-2022-1031・GO-2026-6293）、v5が2件（GO-2026-4502・GO-2026-6293）しか載っておらず、今回のCVE-2026-118264や同じ時期のEchoのアドバイザリは収録されていません。govulncheckやそれを使うCIの検査で何も出なくても、対象外とは判断できません。[11]

当面は、go list -mや、組み上がったバイナリに記録されたモジュールの版で、v4・v5の版を直接確かめます。Echo v4は、最新版に対して不具合の修正を2026年12月31日まで、セキュリティの修正を2027年12月31日まで行うとしています。新しく作るものにはv5を勧めています。[10]

脆弱性の公表・更新一覧で、Goの関連情報を調べることもできます。