Echo の静的配信の脆弱性 CVE-2026-118650｜%2F で認可を抜ける仕組みと 5.4.0 への更新

Go の Web フレームワーク Echo に、グローバルに設定した middleware.Static が認可を抜けてファイルを配信する脆弱性 CVE-2026-118650 が公表されました。/admin%2Fsecret.txt のように %2F（符号化したスラッシュ） を含むパスが、/admin/* を守るミドルウェアを素通りして、保護対象のファイルを返しうる、というものです。深刻度は CVSS v3.1 で 7.5（High）、影響は情報開示でコード実行ではありません。修正は 5.4.0 と 4.16.0 です。この記事は、なぜ guard を抜けるのか・自分の構成が対象か・どう直すかを、CVE 公式記録と Echo 公式の勧告・CHANGELOG で裏を取って整理します。依存ライブラリの欠陥がアプリの守りを崩す全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説に、認可の確認が抜ける類型はIDOR とは｜認可チェックの抜けを塞ぐ設計、パスの取り違えで本来触れない場所に届く問題はパストラバーサルの仕組みと防ぎ方にまとめています。

まず対象かを確かめます。自分のプロジェクトで使っている echo の版を見ます。

go list -m all | grep labstack/echo

echo/v5 が 5.4.0 未満、または echo/v4 が 4.16.0 未満なら対象の版です。これは侵害の判定ではなく、修正の入った版かの確認です。

いつ、何が起きたのか

発端は、Echo のルータと静的ファイル配信が、同じ要求パスを別の形で解釈していたことです。2026年9月27日の Echo v5.4.0（Security リリース）で修正され、前メジャー向けに 4.16.0 がバックポートされました。CVE は GitHub が採番し、CVSS v3.1 で 7.5（High）、CWE は 177（URL 符号化の不適切な処理） と 863（不正な認可） です。

同じリリースでは、関連する2件も直っています。.. や空のセグメントを含むパス（/assets/../admin/secret.txt など）を復号後も配信しないようにした修正（GHSA-3pmx-cf9f-34xr）と、リダイレクト先のパスの制御文字を符号化する修正（GHSA-v753-g4cw-jm48）です。いずれも「パスの見え方の違いで本来届かない場所に届く」類型で、まとめて塞がれました。

なぜ guard を抜けるのか

Echo のルータは、既定で %2F を含むパスを符号化のまま照合します。そのため /admin%2Fsecret.txt は、文字列として /admin/* のパターンに一致せず、そのルートに付けた認可ミドルウェア（guard）は呼ばれません。要求はどのルートにも一致しないまま、最後にグローバルな middleware.Static へ届きます。ここで静的ハンドラは URL.Path を復号して admin/secret.txt を root 配下から探すため、guard を通らずにファイルが配信されえます。CVE の説明は、グローバル mount の構成で guard が対象パスを守っているかについて勧告の記述に内部的な不整合がある、とも注記していますが、要点はルータと静的配信でパスの形がずれていたことです。

修正版は、この食い違いを解消します。既定設定では、ルータが照合したのと同じ形でファイルを解決するため、/admin%2Fsecret.txt や /%61dmin/secret.txt（a を符号化）が guard 下のファイルに届かなくなります。ここでは攻撃に使える具体的な手順（PoC）は示しません。

この類型は Echo だけの話ではなく、パスの正規化を複数の層で別々に行うと起きがちなものです。ルート照合・認可・ファイル解決が、それぞれ「符号化したまま」「復号してから」とばらばらにパスを見ると、どこかの層で守ったつもりが別の層で抜けます。守りの判断（認可）と、実際にファイルを取り出す処理が、同じ正規化を通した同じ文字列を見ているか——これが、フレームワークを問わず効く確認の勘所です。今回の修正は、まさにその一致を既定で保証する方向の変更です。

何を、どの版へ上げるか

対応は版を上げることが中心です。go.mod のモジュールパス（echo/v5 か echo/v4）に合わせて上げます。上げ方は、echo/v5 なら go get github.com/labstack/echo/[email protected]、echo/v4 なら go get github.com/labstack/echo/[email protected] のように版を指定して取得し、go mod tidy で依存を整え、ビルドして配布し直します。CI では版を固定し、go.sum の差分をレビューに含めると、意図した版へ上がったかを確認できます。複数サービスで echo を使っているなら、同じ経路の構成が他にないかもあわせて見ます。

自分の構成を確認する

対象の版だったら、次にグローバルな静的配信を使っているかを見ます。アプリ全体に middleware.Static を付けている箇所を探します。

grep -rn "middleware.Static" .

e.Use(middleware.Static(...)) のようにグローバルに付けていて、その root の下に、ルート単位の認可で守っているパスが含まれているなら、対象の構成です。実際に自分の環境が配信してしまうかは、保護しているはずのパスを符号化して、ステージング環境で確かめます（悪用用のデータではなく、挙動の確認です）。

curl -i "https://<your-staging-host>/admin%2Fsecret.txt"

修正前は guard を通らずファイルが返り、修正後は 404 などで届かなくなります。確認できるのは「修正・設定が効いているか」で、侵害の有無ではありません。

影響範囲

影響を受けるのは、グローバルに mount した middleware.Static の配信 root の下に、ルート単位のミドルウェアで守っているパスが同居しているアプリです。逆に、Echo.Static / Group.Static を guard の内側で使っている構成や、保護対象を root の外に置いている構成は、この経路の直接の対象ではありません。結果は情報開示（本来読めないファイルが読まれる）で、コード実行や改ざんではありません。

深刻度は CVSS v3.1 で 7.5（High）で、ネットワーク越しに認証なしで成立しうる一方、影響は機密性に限られます。優先度は、配信 root に何が同居しているかで決まります。秘密鍵・設定ファイル・個人情報などが root 配下にあるなら高く見積もり、静的アセットしか置いていないなら相対的に下がります。

よくある危ない同居の例としては、public/ を丸ごとルート直下から配信していて（e.Static("/", "public")）、その中に管理画面向けのファイルや、ビルドの成果物に紛れた .env・設定テンプレート・バックアップが残っている、といった構成があります。こうした「静的配信の root に、本来は認可の内側に置くべきものが混ざっている」状態ほど、今回の経路の影響が大きくなります。棚卸しとして、配信 root の下に guard 対象や秘密が無いかを一度見ておくと、版を上げたあとも安全側に倒せます。

いずれにせよ修正は版を上げるだけで軽いので、待つ理由はありません。保護したいファイルは、恒久的に配信 root の外へ出しておくのが安全で、これは版を上げたあとの運用ルールとしても有効です。

参照ソース

• CVE-2026-118650（CVE 公式記録・GitHub 採番・CVSS v3.1 7.5・CWE-177／CWE-863）
• GHSA-375p-5qhx-8wq4（Echo 公式セキュリティ勧告）
• labstack/echo CHANGELOG v5.4.0（Security と Behavior changes）
• labstack/echo v4.16.0（前メジャーへのバックポート）
• 修正コミット（echo 本体・ルータが照合した形でファイルを解決）