How severe is GHSA-h7wr-284f-5qvc?

No CVSS score has been assigned to GHSA-h7wr-284f-5qvc yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-h7wr-284f-5qvc?

GHSA-h7wr-284f-5qvc affects the following packages: github.com/labstack/echo/v4 (Go). Ecosystems affected: Go.

How do I fix GHSA-h7wr-284f-5qvc?

Update github.com/labstack/echo/v4 to 4.16.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h7wr-284f-5qvc is resolved across your whole dependency graph.

How do I detect GHSA-h7wr-284f-5qvc in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/labstack/echo/v4, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-h7wr-284f-5qvc if there is no patch (or I can't update yet)?

Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Is GHSA-h7wr-284f-5qvc actively exploited in the wild?

No public exploit code has been indexed for GHSA-h7wr-284f-5qvc yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-h7wr-284f-5qvc published, and has it been updated?

GHSA-h7wr-284f-5qvc was published on October 23, 2026 and was last updated on October 23, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

Echo: Decompress permits unbounded gzip expansion in v4GHSA-h7wr-284f-5qvc

Fix: labstack/echo#3136

GHSA-h7wr-284f-5qvc is a security vulnerability in github.com/labstack/echo/v4. A fix is available for github.com/labstack/echo/v4 — see the affected versions and patch details below.

Published

Oct 23, 2026

Updated

Oct 23, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 23, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

🐹github.com/labstack/echo/v4

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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 @Shubham-Padkonde's work in #3136.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/labstack/echo/v4`	≥ 4.0.0&&< 4.16.1	4.16.1`go get github.com/labstack/echo/v4@v4.16.1`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/labstack/echo/v4, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/labstack/echo/v4 to 4.16.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h7wr-284f-5qvc is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

## 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 patc

O3 Security · Impact-Aware SCA

Is GHSA-h7wr-284f-5qvc in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works