fix(deps): update module github.com/labstack/echo/v4 to v4.16.1 [security] by renovate[bot] · Pull Request #270 · metal-toolbox/auditevent

renovate · 2026-08-25T16:37:47Z

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/labstack/echo/v4	`v4.13.3` → `v4.16.1`

Echo: Encoded slash (%2F) bypasses route-level protection and exposes static files

CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq

More information

Details

Summary

Echo's router and static file handler disagree on URL path decoding. The router matches routes using the raw encoded path (preserving %2F as-is), while StaticDirectoryHandler unescapes %2F to / before resolving filesystem paths. This allows an attacker to bypass route-level access controls and read static files without authorization.

Details

Root cause 1 — router.go lines 798-802:
The router uses req.URL.RawPath for route matching when useEscapedPathForRouting is false (the default). This means /admin%2Fsecret.txt is treated as a single path segment and does NOT match the /admin/* route pattern.

if !r.useEscapedPathForRouting && req.URL.RawPath != "" {
    path = req.URL.RawPath
}

Root cause 2 — echo.go lines 559-568:
StaticDirectoryHandler calls url.PathUnescape() on the path parameter before opening files. This converts %2F back to /, resolving admin/secret.txt on disk.

if !disablePathUnescaping {
    tmpPath, err := url.PathUnescape(p)
    p = tmpPath
}
name := filepath.ToSlash(filepath.Clean(strings.TrimPrefix(p, "/")))

PoC (Screenshot)

Sample:

403:

Bypass with encoded slash:

Impact

Unauthorized static file disclosure. Applications that protect route prefixes with authentication middleware while also serving static files from a broader root are vulnerable. An attacker only needs to encode the slash (/ → %2F) in the URL to bypass all route-level protection.

Common affected pattern:

adminGroup := e.Group("/admin", authMiddleware)
e.StaticFS("/", os.DirFS("public"))

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Echo: BodyDump captures request and response bodies without size limits in v4

CVE-2026-118260 / GHSA-f48p-c9v4-h7xv

More information

Details

Impact

Echo v4's opt-in BodyDump middleware read complete request bodies into memory and retained complete response bodies without a capture limit. A client able to submit large requests to a route using BodyDump could cause large allocations before the application handler ran. Large responses, including responses whose size can be influenced by a client, also caused an additional unbounded capture allocation.

Repeated or concurrent requests can exhaust process memory and cause denial of service. BodyDump is not enabled by default. Deployments with effective request limits may reduce the request-side exposure; response capture requires separate consideration.

Affected versions and patch

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

The patch adds BodyDumpConfig.MaxRequestBytes and MaxResponseBytes, each defaulting to 5 MiB when zero. A value of -1 explicitly restores unlimited capture. The complete request remains readable by the handler and the complete response is delivered to the client; only the callback's captured data is bounded. Request close behavior and read errors are preserved.

Fix commit.

Workarounds

Disable BodyDump on exposed routes, particularly large uploads and downloads. Alternatively, enforce body-size limits before BodyDump and independently bound the responses that the application generates.

Credits

Reported by @q490107865. The patch also incorporates request-body preservation work from @jakezwang in #3105.

Severity

CVSS Score: 8.2 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Echo: Decompress permits unbounded gzip expansion in v4

CVE-2026-118261 / GHSA-h7wr-284f-5qvc

More information

Details

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.

Severity

CVSS Score: 8.2 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Echo: Rejected WebSocket upgrades can bypass Echo route-level access controls

CVE-2026-118264 / GHSA-cxf3-9h37-7rr8

More information

Details

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.

Workarounds

Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.

Credits

Reported by @Duodum.

Severity

CVSS Score: 9.1 / 10 (Critical)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

labstack/echo (github.com/labstack/echo/v4)

`v4.16.1`

Compare Source

Security fixes

Upgrade with go get github.com/labstack/echo/v4@v4.16.1.

Go 1.26 or later is now required to use patched golang.org/x/ dependencies. Build deployments with a supported, patched Go toolchain.

Validate upstream WebSocket upgrade responses through Go's HTTP reverse proxy. Rejected upgrades no longer leave a raw tunnel that bypasses Echo routing and route middleware. GHSA-cxf3-9h37-7rr8
Close both WebSocket connections when either side disconnects, including when an upstream ignores client EOF. GHSA-9969-6676-49h5
Bound BodyDump request and response captures to 5 MiB each by default while preserving complete payload delivery and request read errors. GHSA-f48p-c9v4-h7xv
Bound decompressed request bodies to 100 MiB by default. Overflow returns HTTP 413, including through JSON and XML binding; exactly-at-limit bodies remain valid. GHSA-h7wr-284f-5qvc
Upgrade golang.org/x/net to v0.60.0 and related dependencies, addressing GO-2026-6617, GO-2026-6612, GO-2026-6611, GO-2026-6610 and GO-2026-6603.
Include the BodyLimit overflow-check correction and static-path hardening already merged since v4.16.0.

Behavior to review when upgrading

BodyDumpConfig.MaxRequestBytes and MaxResponseBytes control capture limits. Zero selects the 5 MiB default; -1 disables a limit. These limits affect captured logging data only: handlers and clients still receive complete bodies.

DecompressConfig.MaxDecompressedSize controls the decompressed-body limit. Zero selects the 100 MiB default; -1 disables it. Apply any smaller application body limit after decompression, and handle request-body read errors.

The proxy removes incoming Forwarded headers as defensive hardening. Backends relying on that header should use forwarding headers generated from the configured trusted IP extractor and scheme. WebSocket requests now honor the configured proxy transport, response modifier, target path and query in the same way as HTTP requests; ws and wss targets remain supported.

Other changes

This release includes router fixes for escaped colons, inline verbs and parameter storage, binding support for OpenAPI date formats, and documentation updates. Benchmark comparisons now run only for pull requests with shorter samples.

Thanks to @Duodum, @irisitymichaelgrundberg, @q490107865, @Hama1cco, @jakezwang and @Shubham-Padkonde for reports and contributions, and to the contributors credited in the individual commits.

Validation: upstream lint checks and race tests passed on Linux, macOS and Windows with Go 1.26 and 1.27. Local tests on patched toolchains, vet, staticcheck and govulncheck also passed; govulncheck reported no reachable vulnerabilities. The module graph still contains an advisory for the unused, unmaintained golang.org/x/crypto/openpgp package (GO-2026-5932), which Echo does not import and for which no fixed dependency version is available.

Full changelog: labstack/echo@v4.16.0...v4.16.1

`v4.16.0`

Compare Source

Security

This release fixes several security issues. Upgrading is recommended. Some fixes change behavior; read "Behavior changes to check before upgrading" below.

Request scheme: Context.Scheme() now uses the X-Forwarded-Proto, X-Forwarded-Protocol, X-Forwarded-Ssl and X-Url-Scheme headers only when the request comes directly from a loopback, link-local or private network address or a unix socket. Before this, any client could send X-Forwarded-Proto: https over plain HTTP and skip HTTPSRedirect. When X-Forwarded-Proto is present, only it is used (its last value), and the scheme is returned in lowercase. the new Echo#SchemeExtractor field selects the strategy: ExtractSchemeFromHeaders(...TrustOption) (default), ExtractSchemeDirect() or LegacySchemeExtractor(). The Secure middleware now sets HSTS based on Context.Scheme(). The Proxy middleware always sets X-Forwarded-Proto from Context.Scheme() and removes X-Forwarded-Ssl, X-Forwarded-Protocol and X-Url-Scheme before forwarding. GHSA-2ffq-g2xg-c22p
JSONP: Context.JSONP and Context.JSONPBlob accept only a callback that is empty, a JavaScript identifier or a dot-separated path of identifiers (ASCII letters, digits, _ and $). Any other callback returns a 400 Bad Request error that wraps the new ErrInvalidJSONPCallback, and nothing is written. JSONP responses now carry X-Content-Type-Options: nosniff. JSONP lets any website read the response with the user's cookies, so do not use it for data that needs authentication. GHSA-h9g5-28mm-hx3g
MethodOverride: a POST can no longer be overridden to GET, HEAD, OPTIONS, TRACE or CONNECT. Before this, with the MethodFromForm or MethodFromQuery getter and MethodOverride registered with Use before the CSRF middleware, _method=GET skipped the CSRF check. Register MethodOverride with Echo#Pre. GHSA-r7w9-592q-9vg4
Redirects: the trailing slash middlewares and the static directory redirect percent-encode control characters in the redirect path. Before this, /%09/evil.example/ redirected browsers to evil.example. GHSA-v753-g4cw-jm48
Static files: with the default settings, the Static middleware resolves files from the same form of the path that the router matched, so /admin%2Fsecret.txt or /%61dmin/secret.txt can no longer reach a file under a guarded /admin/* route. GHSA-375p-5qhx-8wq4 The Static middleware and StaticDirectoryHandler (used by Echo.Static, Echo.StaticFS, Group.Static and Group.StaticFS) no longer serve paths with a ., .. or empty segment, such as /assets/../admin/secret.txt, also after path unescaping. GHSA-3pmx-cf9f-34xr
Dependencies: update golang.org/x/text to v0.40.0 (GO-2026-5970).

Client IP address (no code change in v4)

Without Echo#IPExtractor, Context.RealIP() in v4 trusts the X-Forwarded-For and X-Real-IP headers from any client, so the rate limiter can be bypassed and the Proxy middleware forwards a spoofed X-Real-IP (GHSA-246p-cpwv-v3jq, GHSA-99jh-6h7p-pp36). Changing this default in v4 would put all clients behind a proxy into one rate-limit bucket, so v4 keeps it. Set an extractor that matches your deployment:

e.IPExtractor = echo.ExtractIPDirect()        // no proxy in front of the app
e.IPExtractor = echo.ExtractIPFromXFFHeader() // behind proxies in private networks that set X-Forwarded-For
// behind a proxy with public addresses (e.g. a CDN), also trust its ranges:
// e.IPExtractor = echo.ExtractIPFromXFFHeader(echo.TrustIPRange(cdnRange))

v5 uses the direct peer address by default since v5.1.0.

Behavior changes to check before upgrading

Proxies or load balancers with public IP addresses. If a proxy connects to your app from a public (or 100.64.0.0/10) address, its X-Forwarded-Proto is now ignored: HTTPSRedirect redirects in a loop and the Secure middleware stops sending HSTS. This affects, for example, Cloudflare, CloudFront and Azure Front Door connecting to a public origin, the GCP external HTTP(S) load balancer including GKE Ingress (35.191.0.0/16, 130.211.0.0/22), and networks that use 100.64.0.0/10 (such as Alibaba Cloud SLB or EKS custom networking). Trust the proxy's address ranges:
```
_, gclb1, _ := net.ParseCIDR("35.191.0.0/16")
_, gclb2, _ := net.ParseCIDR("130.211.0.0/22")
e.SchemeExtractor = echo.ExtractSchemeFromHeaders(echo.TrustIPRange(gclb1), echo.TrustIPRange(gclb2))
```
Proxies on the same host, in a private network (AWS ALB, in-cluster ingress controllers such as ingress-nginx or Traefik, most PaaS routers) or on a unix socket keep working without changes. echo.LegacySchemeExtractor() restores the old behavior but is not safe unless every request passes through a proxy that sets these headers. Serverless adapters or middleware that set RemoteAddr to the client's address also make X-Forwarded-Proto ignored (or, if they take it from a header, spoofable).
Trusted proxies must set X-Forwarded-Proto. A proxy on a trusted address that passes the client's X-Forwarded-Proto through (for example nginx without proxy_set_header X-Forwarded-Proto $scheme;) still lets the client choose the scheme. An invalid X-Forwarded-Proto value now results in http instead of falling back to the other scheme headers.
Your own tests. httptest.NewRequest sets RemoteAddr to 192.0.2.1:1234, which is not trusted, so tests that set X-Forwarded-Proto now see http. Set req.RemoteAddr = "10.0.0.1:1234" or use e.SchemeExtractor = echo.LegacySchemeExtractor() in such tests.
Proxy middleware headers. X-Forwarded-Ssl, X-Forwarded-Protocol and X-Url-Scheme are no longer forwarded to the upstream; X-Forwarded-Proto carries the scheme.
MethodOverride. Overriding a POST to GET (for example with X-HTTP-Method-Override: GET to send a long query in a POST body) is no longer done; such requests keep the POST method.
Static files. Paths with a double slash or dot segment (for example /assets//app.js) now return 404; in HTML5 mode the index is still served. The Static middleware no longer finds file names that the client sends with non-default escaping (for example %2C, %40 or lowercase hex like %c3%a9) unless StaticConfig.EnablePathUnescaping is set; Echo.Static has behaved this way since v4.15.4. With StaticConfig.EnablePathUnescaping or Echo#EnablePathUnescapingStaticFiles, encoded dots (%2e%2e) no longer traverse directories, but encoded slashes are still decoded, so do not combine these options with route-based access control.
JSONP. Context.JSONP returns an error for callbacks that are not JavaScript identifiers.

Documentation

Static middleware: when registered with Echo#Use it runs before route and group middleware, so route guards do not protect the files it serves.

If your company depends on Echo, please consider sponsoring it.

`v4.15.4`

Compare Source

Security

Fixes GHSA-vfp3-v2gw-7wfq: an encoded path separator (%2F or %5C) in a static file URL could bypass route-level middleware (e.g. authentication on a sibling route) and disclose static files. Both StaticDirectoryHandler (used by Static/StaticFS) and the Static middleware are affected. Backport of the v5 fix (#3016, released in v5.2.1). Thanks to @a-tt-om and @oran-gugu for reporting.

Make serving static file releated methods and middleware not unescape path by default - so how the way Router interprets paths and Static methods/middleware is consistent.

Given following situation:

// 0.
// given folder structure:
// private.txt
// public/
// public/index.html
// public/text.txt
// public/admin/private.txt

// 1. share `public/` folder contents from the server root. This folder actually contains subfolder `admin` which
// contents we want to forbid from downloading
e.Static("/", "public")

// 2. naively assume that everything under /admin folder is now forbidden
e.GET("/admin/*", func(c *Context) error {
    return ErrForbidden
})

Then requests to /admin%2fprivate.txt would not be matched to GET /admin/* route (routing does not look unescaped path) and static file serving will use unescaped path to serve the file.

Note: this way of "guarding" subfolders will never work for for paths like /assets/../admin%2fprivate.txt which will path.Clean("/assets/../admin%2fprivate.txt") to /admin/private.txt and are servable if static file serving is configured to unescape paths.

If you want to guard routes - use middlewares on Static* methods and before Static middleware.

Breaking change / migration: If you serve files whose names contain URL-encoded characters (e.g., /hello%20world.txt → hello world.txt), you must now opt in:

	e := echo.New()
	e.EnablePathUnescapingStaticFiles = true  // <-- enable old behavior
	e.Static("/", "public")

for static middleware

	e.Use(middleware.StaticWithConfig(middleware.StaticConfig{
		EnablePathUnescaping: true, // <-- enable old behavior
	}))

Full Changelog: labstack/echo@v4.15.3...v4.15.4

`v4.15.3`: - Static encoded-separator route bypass fix (GHSA-vfp3-v2gw-7wfq)

Compare Source

Security

fix(static): reject encoded path separators that bypass route-level middleware by @vishr in #3011

Fixes GHSA-vfp3-v2gw-7wfq: an encoded path separator (%2F or %5C) in a static file URL could bypass route-level middleware (e.g. authentication on a sibling route) and disclose static files. Both StaticDirectoryHandler (used by Static/StaticFS) and the Static middleware are affected. Backport of the v5 fix (#3009, released in v5.2.0). Thanks to @a-tt-om and @oran-gugu for reporting.

Full Changelog: labstack/echo@v4.15.2...v4.15.3

`v4.15.2`: - Context.Scheme() header validation

Compare Source

Security

Context.Scheme() should validate values taken from header by @aldas in #2962

Thanks to @shblue21 for reporting this issue.

Full Changelog: labstack/echo@v4.15.1...v4.15.2

`v4.15.1`

Compare Source

What's Changed

CSRF: support older token-based CSRF protection handler that want to render token into template by @aldas in #2905

Full Changelog: labstack/echo@v4.15.0...v4.15.1

`v4.15.0`

Compare Source

Security

NB: If your application relies on cross-origin or same-site (same subdomain) requests do not blindly push this version to production

The CSRF middleware now supports the Sec-Fetch-Site header as a modern, defense-in-depth approach to CSRF
protection, implementing the OWASP-recommended Fetch Metadata API alongside the traditional token-based mechanism.

How it works:

Modern browsers automatically send the Sec-Fetch-Site header with all requests, indicating the relationship
between the request origin and the target. The middleware uses this to make security decisions:

same-origin or none: Requests are allowed (exact origin match or direct user navigation)
same-site: Falls back to token validation (e.g., subdomain to main domain)
cross-site: Blocked by default with 403 error for unsafe methods (POST, PUT, DELETE, PATCH)

For browsers that don't send this header (older browsers), the middleware seamlessly falls back to
traditional token-based CSRF protection.

New Configuration Options:

TrustedOrigins []string: Allowlist specific origins for cross-site requests (useful for OAuth callbacks, webhooks)
AllowSecFetchSiteFunc func(echo.Context) (bool, error): Custom logic for same-site/cross-site request validation

Example:

e.Use(middleware.CSRFWithConfig(middleware.CSRFConfig{
    // Allow OAuth callbacks from trusted provider
    TrustedOrigins: []string{"https://oauth-provider.com"},

    // Custom validation for same-site requests
    AllowSecFetchSiteFunc: func(c echo.Context) (bool, error) {
        // Your custom authorization logic here
        return validateCustomAuth(c), nil
        // return true, err  // blocks request with error
        // return true, nil  // allows CSRF request through
        // return false, nil // falls back to legacy token logic
    },
}))

PR: #2858

Type-Safe Generic Parameter Binding

Added generic functions for type-safe parameter extraction and context access by @aldas in #2856

Echo now provides generic functions for extracting path, query, and form parameters with automatic type conversion,
eliminating manual string parsing and type assertions.

New Functions:
- Path parameters: PathParam[T], PathParamOr[T]
- Query parameters: QueryParam[T], QueryParamOr[T], QueryParams[T], QueryParamsOr[T]
- Form values: FormParam[T], FormParamOr[T], FormParams[T], FormParamsOr[T]
- Context store: ContextGet[T], ContextGetOr[T]
Supported Types:
Primitives (bool, string, int/uint variants, float32/float64), time.Duration, time.Time
(with custom layouts and Unix timestamp support), and custom types implementing BindUnmarshaler,
TextUnmarshaler, or JSONUnmarshaler.

Example:
```
// Before: Manual parsing
idStr := c.Param("id")
id, err := strconv.Atoi(idStr)

// After: Type-safe with automatic parsing
id, err := echo.PathParam[int](c, "id")

// With default values
page, err := echo.QueryParamOr[int](c, "page", 1)
limit, err := echo.QueryParamOr[int](c, "limit", 20)

// Type-safe context access (no more panics from type assertions)
user, err := echo.ContextGet[*User](c, "user")
```

PR: #2856

DEPRECATION NOTICE Timeout Middleware Deprecated - Use ContextTimeout Instead

The middleware.Timeout middleware has been deprecated due to fundamental architectural issues that cause
data races. Use middleware.ContextTimeout or middleware.ContextTimeoutWithConfig instead.

Why is this being deprecated?

The Timeout middleware manipulates response writers across goroutine boundaries, which causes data races that
cannot be reliably fixed without a complete architectural redesign. The middleware:

Swaps the response writer using http.TimeoutHandler
Must be the first middleware in the chain (fragile constraint)
Can cause races with other middleware (Logger, metrics, custom middleware)
Has been the source of multiple race condition fixes over the years

What should you use instead?

The ContextTimeout middleware (available since v4.12.0) provides timeout functionality using Go's standard
context mechanism. It is:

Race-free by design
Can be placed anywhere in the middleware chain
Simpler and more maintainable
Compatible with all other middleware

Migration Guide:

// Before (deprecated):
e.Use(middleware.Timeout())

// After (recommended):
e.Use(middleware.ContextTimeout(30 * time.Second))

Important Behavioral Differences:

Handler cooperation required: With ContextTimeout, your handlers must check context.Done() for cooperative
cancellation. The old Timeout middleware would send a 503 response regardless of handler cooperation, but had
data race issues.
Error handling: ContextTimeout returns errors through the standard error handling flow. Handlers that receive
context.DeadlineExceeded should handle it appropriately:

e.GET("/long-task", func(c echo.Context) error {
    ctx := c.Request().Context()

    // Example: database query with context
    result, err := db.QueryContext(ctx, "SELECT * FROM large_table")
    if err != nil {
        if errors.Is(err, context.DeadlineExceeded) {
            // Handle timeout
            return echo.NewHTTPError(http.StatusServiceUnavailable, "Request timeout")
        }
        return err
    }

    return c.JSON(http.StatusOK, result)
})

Background tasks: For long-running background tasks, use goroutines with context:

e.GET("/async-task", func(c echo.Context) error {
    ctx := c.Request().Context()

    resultCh := make(chan Result, 1)
    errCh := make(chan error, 1)

    go func() {
        result, err := performLongTask(ctx)
        if err != nil {
            errCh <- err
            return
        }
        resultCh <- result
    }()

    select {
    case result := <-resultCh:
        return c.JSON(http.StatusOK, result)
    case err := <-errCh:
        return err
    case <-ctx.Done():
        return echo.NewHTTPError(http.StatusServiceUnavailable, "Request timeout")
    }
})

Enhancements

Fixes by @aldas in #2852
Generic functions by @aldas in #2856
CRSF with Sec-Fetch-Site checks by @aldas in #2858

`v4.14.0`

Compare Source

middleware.Logger has been deprecated. For request logging, use middleware.RequestLogger or
middleware.RequestLoggerWithConfig.

middleware.RequestLogger replaces middleware.Logger, offering comparable configuration while relying on the
Go standard library’s new slog logger.

The previous default output format was JSON. The new default follows the standard slog logger settings.
To continue emitting request logs in JSON, configure slog accordingly:

slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stdout, nil)))
e.Use(middleware.RequestLogger())

Security

Logger middleware json string escaping and deprecation by @aldas in #2849

Enhancements

Update deps by @aldas in #2807
refactor to use reflect.TypeFor by @cuiweixie in #2812
Use Go 1.25 in CI by @aldas in #2810
Modernize context.go by replacing interface{} with any by @vishr in #2822
Fix typo in SetParamValues comment by @vishr in #2828
Fix typo in ContextTimeout middleware comment by @vishr in #2827
Improve BasicAuth middleware: use strings.Cut and RFC compliance by @vishr in #2825
Fix duplicate plus operator in router backtracking logic by @yuya-morimoto in #2832
Replace custom private IP range check with built-in net.IP.IsPrivate by @kumapower17 in #2835
Ensure proxy connection is closed in proxyRaw function(#2837) by @kumapower17 in #2838
Update deps by @aldas in #2843
Update golang.org/x/* deps by @aldas in #2850

`v4.13.4`

Compare Source

Enhancements

chore: fix some typos in comment by @zhuhaicity in #2735
CI: test with Go 1.24 by @aldas in #2748
Add support for TLS WebSocket proxy by @t-ibayashi-safie in #2762

Security

Update dependencies for GO-2025-3487, GO-2025-3503 and GO-2025-3595 in #2780

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

renovate · 2026-08-25T16:37:48Z

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

10 additional dependencies were updated
The go directive was updated for compatibility reasons

Details:

Package	Change
`go`	`1.24` -> `1.26.0`
`github.com/stretchr/testify`	`v1.10.0` -> `v1.11.1`
`golang.org/x/sync`	`v0.12.0` -> `v0.23.0`
`github.com/labstack/gommon`	`v0.4.2` -> `v0.5.0`
`github.com/mattn/go-colorable`	`v0.1.13` -> `v0.1.15`
`github.com/mattn/go-isatty`	`v0.0.20` -> `v0.0.22`
`golang.org/x/crypto`	`v0.31.0` -> `v0.57.0`
`golang.org/x/net`	`v0.33.0` -> `v0.60.0`
`golang.org/x/sys`	`v0.28.0` -> `v0.48.0`
`golang.org/x/text`	`v0.21.0` -> `v0.42.0`
`golang.org/x/time`	`v0.8.0` -> `v0.15.0`

…rity]

renovate Bot requested a review from a team as a code owner August 25, 2026 16:37

renovate Bot changed the title ~~fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security]~~ fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security] - autoclosed Aug 30, 2026

renovate Bot closed this Aug 30, 2026

renovate Bot deleted the renovate/go-github.com-labstack-echo-v4-vulnerability branch August 30, 2026 11:32

renovate Bot changed the title ~~fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security] - autoclosed~~ fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security] Aug 30, 2026

renovate Bot reopened this Aug 30, 2026

renovate Bot force-pushed the renovate/go-github.com-labstack-echo-v4-vulnerability branch 2 times, most recently from a5e9c59 to 6bddf74 Compare August 30, 2026 15:44

renovate Bot changed the title ~~fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security]~~ fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security] - autoclosed Aug 31, 2026

renovate Bot closed this Aug 31, 2026

renovate Bot changed the title ~~fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security] - autoclosed~~ fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security] Aug 31, 2026

renovate Bot reopened this Aug 31, 2026

renovate Bot force-pushed the renovate/go-github.com-labstack-echo-v4-vulnerability branch 2 times, most recently from 6bddf74 to 5d1cd6b Compare August 31, 2026 17:11

fix(deps): update module github.com/labstack/echo/v4 to v4.16.1 [secu…

5a64341

…rity]

renovate Bot force-pushed the renovate/go-github.com-labstack-echo-v4-vulnerability branch from 5d1cd6b to 5a64341 Compare October 29, 2026 12:54

renovate Bot changed the title ~~fix(deps): update module github.com/labstack/echo/v4 to v4.15.3 [security]~~ fix(deps): update module github.com/labstack/echo/v4 to v4.16.1 [security] Oct 29, 2026

Navigation Menu

Repository navigation

fix(deps): update module github.com/labstack/echo/v4 to v4.16.1 [security] - #270

fix(deps): update module github.com/labstack/echo/v4 to v4.16.1 [security]#270
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/go-github.com-labstack-echo-v4-vulnerability

renovate Bot commented Aug 25, 2026 •

edited

Loading

Uh oh!

renovate Bot commented Aug 25, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Echo: Encoded slash (%2F) bypasses route-level protection and exposes static files

Details

Summary

Details

PoC (Screenshot)

Impact

Severity

References

Echo: BodyDump captures request and response bodies without size limits in v4

Details

Impact

Affected versions and patch

Workarounds

Credits

Severity

References

Echo: Decompress permits unbounded gzip expansion in v4

Details

Impact

Affected versions and patch

Workarounds

Credits

Severity

References

Echo: Rejected WebSocket upgrades can bypass Echo route-level access controls

Details

Impact

Affected versions and patch

Workarounds

Credits

Severity

References

Release Notes

v4.16.1

Security fixes

Behavior to review when upgrading

Other changes

v4.16.0

v4.15.4

v4.15.3: - Static encoded-separator route bypass fix (GHSA-vfp3-v2gw-7wfq)

Security

v4.15.2: - Context.Scheme() header validation

v4.15.1

What's Changed

v4.15.0

v4.14.0

v4.13.4

Configuration

Uh oh!

renovate Bot commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ℹ️ Artifact update notice

File name: go.mod

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate Bot commented Aug 25, 2026 •

edited

Loading

`v4.16.1`

`v4.16.0`

`v4.15.4`

`v4.15.3`: - Static encoded-separator route bypass fix (GHSA-vfp3-v2gw-7wfq)

`v4.15.2`: - Context.Scheme() header validation

`v4.15.1`

`v4.15.0`

`v4.14.0`

`v4.13.4`

renovate Bot commented Aug 25, 2026 •

edited

Loading