高 8.2

Echo v4のDecompressに巨大展開で大量のメモリやCPUを消費される脆弱性

CVE-2026-118261 SecPulse初出 3:58

概要

Echo v4のオプション機能であるDecompressミドルウェアには、gzip圧縮されたリクエストの展開後のサイズに上限がない脆弱性があります。小さなリクエストでも大量のメモリやCPUを消費され、サービス拒否(DoS)が起きるおそれがあります。v4.16.0までが対象で、修正版のv4.16.1へ更新してください。

AI要約

外部の AI が作成した要約です。誤りを含むことがあります。重要な判断の前に、下の原文と参照URLを確認してください。

影響パッケージ

種類	パッケージ	影響を受ける版	直った版
labstack	echo	—	—
go	github.com/labstack/echo/v4	4.0.0 以上 4.16.1 未満	4.16.1

原文の説明取得元が公開している説明をそのまま載せています (多くは英語)。

Impact

Echo v4's opt-in Decompress middleware exposed a gzip-decoded request stream without limiting its expanded size. A small compressed request could therefore produce a very large decoded body. Handlers that read or bind that body could consume excessive memory or CPU, and repeated or concurrent requests could cause denial of service.

The middleware is not enabled by default. A limit on the compressed request size alone does not bound the decompressed size. Applications that already apply an effective body limit after decompression have reduced exposure.

Affected versions and patch

Echo v4 versions through v4.16.0 are affected. Upgrade to v4.16.1.

The patch adds DecompressConfig.MaxDecompressedSize, defaulting to 100 MiB when zero. A value of -1 explicitly disables the limit. Reading beyond the cap returns ErrStatusRequestEntityTooLarge (HTTP 413), including through JSON and XML binding. Bodies exactly at the configured limit remain valid. Streaming enforcement requires callers to handle body-read errors.

Fix commit.

Workarounds

Disable gzip request decompression on exposed routes, or place BodyLimit after Decompress so the application limit applies to decoded bytes. Apply suitable request deadlines and concurrency limits as well.

Credits

Reported by @q490107865. The exact-limit behavior incorporates @Shub…

出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory