Affected: Go: github.com/labstack/echo/v5, Go: github.com/labstack/echo/v4

## Summary

The `c.Scheme()` method in Echo (`context.go:162-181`) trusts the `X-Forwarded-Proto`, `X-Forwarded-Protocol`, and `X-Url-Scheme` request headers without validating that the value is `http` or `https`. The `WWWRedirect()` and `NonWWWRedirect()` middlewares use this unsanitized scheme to construct redirect URLs, allowing an attacker to inject arbitrary URI schemes into the `Location` response header.

## Affected Components

- `context.go:162-181` - `Scheme()` method returns attacker-controlled value verbatim - `middleware/redirect.go:172-184` - `redirectWWW`/`redirectNonWWW` use unsanitized scheme

## Proof of Concept

``` GET /path HTTP/1.1 Host: example.com X-Forwarded-Proto: javascript

Response: HTTP/1.1 301 Moved Permanently Location: javascript://www.example.com/path ```

Confirmed injectable schemes: `javascript`, `data`, `vbscript`, `file`, `ftp`, `ssh`, `telnet`, `gopher`.

Only `WWWRedirect()` and `NonWWWRedirect()` (and `WithConfig` variants) are affected. `HTTPSRedirect`, `HTTPSWWWRedirect`, `HTTPSNonWWWRedirect` are NOT affected (they hardcode `https://`).

## Impact

- Open redirect to arbitrary scheme URLs when app is not behind a proxy that strips `X-Forwarded-Proto` - Cache poisoning when behind a CDN that caches redirect responses keyed by path - `file://` scheme injection could trigger file access in some browser configurations

## Suggested Fix

Whitelist scheme in `c.Scheme()` to only return `http` or `https`:

```go func (c *Context) Scheme(…

Affected: Ubuntu:20.04:LTS: golang-github-labstack-echo.v2, Ubuntu:20.04:LTS: golang-github-labstack-echo.v3, Ubuntu:22.04:LTS: golang-github-labstack-echo, Ubuntu:22.04:LTS: golang-github-labstack-echo.v2, Ubuntu:22.04:LTS: golang-github-labstack-echo.v3, Ubuntu:24.04:LTS: golang-github-labstack-echo, Ubuntu:26.10: golang-github-labstack-echo, Ubuntu:26.04:LTS: golang-github-labstack-echo

Echo is a Go web framework. Prior to 4.15.2 and 5.1.1, Context.Scheme returns values from X-Forwarded-Proto, X-Forwarded-Protocol, or X-Url-Scheme without validating that they are supported web schemes. WWWRedirect and NonWWWRedirect use that value to construct a Location header, so an attacker controlling a forwarded scheme header can cause a redirect to use an arbitrary URI scheme. Exploitation requires an affected redirect middleware and user interaction with the response; the HTTPS-specific redirect variants hardcode HTTPS and are unaffected. This issue is fixed in 4.15.2 and 5.1.1.