Echo Proxyでルート認可を回避される脆弱性、修正版あり
Go製のWebフレームワークEchoのProxy middlewareに、ルートごとの認証・認可をすり抜けられる脆弱性が見つかりました。Echoをリバースプロキシや社内ゲートウェイとして使い、認可をEchoのルートだけに頼っている組織は影響を受けます。4.16.1または5.4.1へ更新し、バックエンド側にも独立した認可があるかを確認してください。
急ぎ度: 早めに
CVSS v4は9.1で重要度はcriticalですが、成立に複数の前提が要り、実際に攻撃で悪用されたという情報はなく、4.16.1と5.4.1の修正版が出ているため、計画的な更新より一段早い対応をお勧めします。
関係があるか
EchoのProxy middlewareでバックエンドへ中継し、認証や認可をEchoのルートやミドルウェアだけで実施しているアプリケーションが対象です。社内APIのゲートウェイや、管理画面の前段にEchoを置いている構成が当てはまりやすいでしょう。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| Echo（labstack/echo）4系 | 4.0.0以上、4.16.1より前 | 4.16.1 |
| Echo（labstack/echo）5系 | 5.4.1より前 | 5.4.1 |
確かめ方
- 1Goのプロジェクトでgo.modを開き、labstack/echoの版を確認します。依存関係ごと見るなら
go list -m all | grep labstack/echoが使えます。 - 2ソースコードで
middleware.ProxyやProxyWithConfigを検索し、Proxy middlewareを使うルートがあるかを調べます。使っていなければ、この脆弱性の対象となる経路はありません。 - 3Proxy middlewareを使うルートがある場合は、中継先のバックエンドが、Echoを通らない直接のリクエストに対しても認証・認可を行うかを確認します。
- 4コンテナイメージや配布済みのバイナリは、ビルド時点の版が残ります。本番で動いているものが修正版でビルドされたかも見てください。
何が起きたか
EchoのProxy middlewareに、ルートごとの認証・認可を迂回できる脆弱性があります。Echoの前段で利用者を絞っているつもりでも、条件がそろうと、制御を通らずにバックエンドへ直接リクエストが届きます。
Proxy middlewareは、クライアントからWebSocketのアップグレード要求を受けると、中継先がそれを受け入れたかを確かめる前に、通信をそのまま中継する経路（生のトンネル）を選んでしまいます。中継先がアップグレードを拒否し、接続を維持したまま通常の応答を返すと、同じ接続上の以後のHTTPリクエストは、Echoのルーターやルート固有のミドルウェアを経由せずに、そのまま中継先へ渡ります。
分類はCWE-444（HTTPリクエストの解釈の不整合）とCWE-863（不適切な認可）です。修正版は、修正が入った4.16.1と5.4.1です。
攻撃の流れ
-
1
アップグレード要求
クライアントがProxy middlewareを通るルートにWebSocketのアップグレード要求を送ります。
-
2
トンネルを先に選択
Echoは中継先の受け入れを確認する前に、生のトンネルでの中継を選びます。
-
3
中継先が拒否
中継先がアップグレードを拒否し、接続を維持したまま通常の応答を返します。
-
4
同じ接続で後続要求
同じ接続上のHTTPリクエストが、Echoのルーターとミドルウェアを通らずに中継先へ届きます。
-
5
認可の迂回
Echoのルートだけで行っていた認証・認可が働かなくなります。
どう悪用されるか
ネットワーク越しに実行でき、攻撃者に認証や権限は要らず、利用者に操作させる必要もありません。ただし成立には前提があり、攻撃者から到達できるProxy middlewareのルートがあることが必要です。さらに、アップグレードを拒否しつつ接続を維持する応答を、中継先が返す必要があります。そして、中継先がEchoとは別に独立した認可を持たないことも条件です。CVSS v4の評価でも、攻撃要件ありとして扱われています。
条件が満たされると、Echoのルートだけで守っていた認証・認可が働かず、保護されているはずのバックエンドの機能やデータにアクセスされます。評価で高く見積もられているのは、機密性と完全性への影響で、情報の閲覧と、操作による書き換えの両方が想定されます。可用性への影響は、評価では想定されていません。
今すぐやること
-
1
対象の版と使い方を洗い出す
Echoを使うサービスを一覧にして、版とProxy middlewareの利用有無を確認します。コンテナイメージに同梱されたものも漏らさず見てください。
go list -m all | grep labstack/echo -
2
修正版へ更新して再ビルドする
4系なら4.16.1、5系なら5.4.1以降へ更新します。Goはビルド時に依存が固まるため、更新後に再ビルドして本番へデプロイし直すまで修正は反映されません。
-
3
バックエンド側の認可を確認する
Echoの背後にあるサービスが、ゲートウェイを通らないリクエストにも認証・認可を求めるかを確認します。独立した認可があれば、今回のような迂回が起きても被害を抑えられます。
-
4
不審なアクセスの痕跡を見る
更新前の期間について、バックエンドのアクセスログに、Echoの認可を経ていないはずの要求がないかを確認します。ゲートウェイ側のログと突き合わせると見つけやすくなります。
すぐ更新できないとき
すぐに更新できない場合は、中継先のバックエンドに、Echoとは独立した認証・認可を加えてください。あわせて、Proxy middlewareを使うルートのうち、外部から到達できる必要のないものは公開範囲を絞るか、外してください。これらは被害を抑える暫定策で、修正版への更新の代わりにはなりません。
背景
EchoはGoの軽量なWebフレームワークで、APIサーバーのほか、Proxy middlewareを使って複数のバックエンドを束ねるゲートウェイとしても使われます。この構成では、認証や認可をEchoのルートに集め、背後のサービスは社内ネットワークに置いて、ゲートウェイを通ってきた要求だけを受ける設計が少なくありません。今回の脆弱性は、まさにその前提を崩す形になっています。
CWE-444に分類されるHTTPのリクエスト解釈のずれは、前段と後段が同じ接続上の通信を別々に解釈することで起きる種類の問題です。今回は、WebSocketのアップグレードが成立したかを確認する前に通信の扱いを決めたことが、ずれの原因です。拒否された場合でも、以後の通信が検査されないまま中継先に渡っていました。
よくある質問
Q.アプリがWebSocketを使っていなければ、影響はありませんか。
まだ分かっていないこと
- 実際の攻撃で悪用されたという情報は公表されていません。状況はEchoのセキュリティアドバイザリ（GHSA-cxf3-9h37-7rr8）で確認してください。
- 5系で影響を受ける最も古い版は、公表されている情報からは判断できません。5系を使っている場合は、アドバイザリとリリースノートで確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| labstack | echo | — | — |
| go | github.com/labstack/echo/v4 |
4.0.0 以上 4.16.1 未満 |
4.16.1 |
| go | github.com/labstack/echo/v5 |
5.0.0 以上 5.4.1 未満 |
5.4.1 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Impact
Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware.
This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication.
Affected versions and patch
The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also shows the missing upgrade-response validation in v4.0.0.
Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.
Fix commits: v4, [v5](https:/…
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory