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.
2303 vulnerabilities reference this CWE, most recent first.
GHSA-XWGQ-PCQX-HPMV
Vulnerability from github – Published: 2020-02-12 18:45 – Updated: 2021-08-19 16:56In Ktor through 1.2.6, the client resends data from the HTTP Authorization header to a redirect location.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.2.6"
},
"package": {
"ecosystem": "Maven",
"name": "io.ktor:ktor-client-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-19703"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2020-02-11T17:33:16Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "In Ktor through 1.2.6, the client resends data from the HTTP Authorization header to a redirect location.",
"id": "GHSA-xwgq-pcqx-hpmv",
"modified": "2021-08-19T16:56:45Z",
"published": "2020-02-12T18:45:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19703"
},
{
"type": "WEB",
"url": "https://github.com/ktorio/ktor/issues/1467"
},
{
"type": "WEB",
"url": "https://github.com/ktorio/ktor/commit/0c108156f45423d09014b47be810188629cb878f"
}
],
"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 (Open Redirect) in Ktor"
}
GHSA-XWPH-X6XJ-WGGV
Vulnerability from github – Published: 2023-04-12 20:38 – Updated: 2023-04-26 22:17Impact
It is possible to bypass the existing security measures put in place to avoid open redirect by using a redirect such as //mydomain.com (i.e. omitting the http:). It was also possible to bypass it when using URL such as http:/mydomain.com.
Patches
The problem has been patched on XWiki 13.10.10, 14.4.4 and 14.8RC1.
Workarounds
The only way to workaround the bug is by providing a patched jar of xwiki-platform-oldcore containing the following changes: https://github.com/xwiki/xwiki-platform/commit/e4f7f68e93cb08c25632c126356d218abf192d1e#diff-c445f288d5d63424f56ef13f65514ab4e174a72e979b53b88197c2b7def267cf.
References
- Jira ticket of the reported vulnerability: https://jira.xwiki.org/browse/XWIKI-19994
- Jira ticket of the original mechanism put in place to prevent open redirect: https://jira.xwiki.org/browse/XWIKI-10309
- Original advisory about open redirect: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-jp55-vvmf-63mv
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira * Email us at Security ML
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "6.0-rc-1"
},
{
"fixed": "13.10.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "14.0-rc-1"
},
{
"fixed": "14.4.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.8-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-29204"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-12T20:38:42Z",
"nvd_published_at": "2023-04-15T16:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nIt is possible to bypass the existing security measures put in place to avoid open redirect by using a redirect such as `//mydomain.com` (i.e. omitting the `http:`). It was also possible to bypass it when using URL such as `http:/mydomain.com`.\n\n### Patches\nThe problem has been patched on XWiki 13.10.10, 14.4.4 and 14.8RC1.\n\n### Workarounds\nThe only way to workaround the bug is by providing a patched jar of xwiki-platform-oldcore containing the following changes: https://github.com/xwiki/xwiki-platform/commit/e4f7f68e93cb08c25632c126356d218abf192d1e#diff-c445f288d5d63424f56ef13f65514ab4e174a72e979b53b88197c2b7def267cf.\n\n### References\n\n * Jira ticket of the reported vulnerability: https://jira.xwiki.org/browse/XWIKI-19994\n * Jira ticket of the original mechanism put in place to prevent open redirect: https://jira.xwiki.org/browse/XWIKI-10309\n * Original advisory about open redirect: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-jp55-vvmf-63mv\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira](https://jira.xwiki.org)\n* Email us at [Security ML](mailto:security@xwiki.org)",
"id": "GHSA-xwph-x6xj-wggv",
"modified": "2023-04-26T22:17:18Z",
"published": "2023-04-12T20:38:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-jp55-vvmf-63mv"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-xwph-x6xj-wggv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29204"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/e4f7f68e93cb08c25632c126356d218abf192d1e#diff-c445f288d5d63424f56ef13f65514ab4e174a72e979b53b88197c2b7def267cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-10309"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19994"
}
],
"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"
}
],
"summary": "org.xwiki.platform:xwiki-platform-oldcore Open Redirect vulnerability"
}
GHSA-XXHQ-69MF-W8CR
Vulnerability from github – Published: 2026-06-23 16:42 – Updated: 2026-06-23 16:42Summary
An open redirect vulnerability exists in Gogs where attacker-controlled redirect_to parameters can bypass validation, allowing redirection to arbitrary external sites.
Details
All redirects in Gogs that are validated via the IsSameSite function are vulnerable:
func IsSameSite(url string) bool {
return len(url) >= 2 && url[0] == '/' && url[1] != '/' && url[1] != '\\'
}
The function only inspects the first two characters of the URL string. This check fails to account for directory traversal sequences followed by backslashes. For example:
/a/../\example.com
The IsSameSite function checks the input supplied to the redirect_to query parameter value /a/../\example.com and considers it valid.
Because web browsers normalize backslashes \ to forward slashes /, the normalized URL becomes //example.com.
The normalized URL becomes:
//example.com
Resulting in a cross-origin redirect.
This affects all endpoints using the redirect_to query parameter, including login and other post-action flows.
PoC
- An attacker can provide a user with a link to login to Gogs with a
redirect_toquery parameter that redirects a user to a site the attacker wants them to visit:
http://192.168.236.132:3000/user/login?redirect_to=/a/../\example.com
- After the user successfully logs in, they would be redirected to the site an attacker wants them to visit:
Impact
- Phishing: Attackers can use trusted domain links to redirect victims to credential-harvesting pages
- OAuth/SSO Token Theft: In authentication flows, authorization codes or tokens may leak via redirect
- Referer Leakage: Sensitive URL parameters may be exposed to attacker domains via the Referer header
- Cache Poisoning: In deployments with shared caches, malicious redirects may be cached and served to other users
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.14.2"
},
"package": {
"ecosystem": "Go",
"name": "gogs.io/gogs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.14.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52802"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T16:42:02Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nAn open redirect vulnerability exists in Gogs where attacker-controlled `redirect_to` parameters can bypass validation, allowing redirection to arbitrary external sites.\n\n\n### Details\nAll redirects in Gogs that are validated via the `IsSameSite` function are vulnerable:\n```go\nfunc IsSameSite(url string) bool {\n return len(url) \u003e= 2 \u0026\u0026 url[0] == \u0027/\u0027 \u0026\u0026 url[1] != \u0027/\u0027 \u0026\u0026 url[1] != \u0027\\\\\u0027\n}\n```\n\nThe function only inspects the first two characters of the URL string. This check fails to account for directory traversal sequences followed by backslashes. For example:\n```\n/a/../\\example.com\n```\n\nThe `IsSameSite` function checks the input supplied to the `redirect_to` query parameter value `/a/../\\example.com` and considers it valid.\n\nBecause web browsers normalize backslashes `\\` to forward slashes `/`, the normalized URL becomes `//example.com`.\n\nThe normalized URL becomes:\n```\n//example.com\n```\n\nResulting in a cross-origin redirect.\n\nThis affects all endpoints using the `redirect_to` query parameter, including login and other post-action flows.\n\n\n### PoC\n\n1. An attacker can provide a user with a link to login to Gogs with a `redirect_to` query parameter that redirects a user to a site the attacker wants them to visit:\n```\nhttp://192.168.236.132:3000/user/login?redirect_to=/a/../\\example.com\n```\n\n\u003cimg width=\"1339\" height=\"536\" alt=\"image\" src=\"https://github.com/user-attachments/assets/3c2a13b8-f0b7-42c2-a223-6f0ebf083589\" /\u003e \n\n\u003cbr\u003e\n\u003cbr\u003e\n\n2. After the user successfully logs in, they would be redirected to the site an attacker wants them to visit:\n\n\u003cimg width=\"1066\" height=\"463\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1726a3d9-6705-43cc-bdd2-90aad105d021\" /\u003e\n\n\u003cimg width=\"1097\" height=\"396\" alt=\"image\" src=\"https://github.com/user-attachments/assets/376052f5-0e00-4d14-a548-fa75a6269530\" /\u003e\n\n\n### Impact\n* Phishing: Attackers can use trusted domain links to redirect victims to credential-harvesting pages\n* OAuth/SSO Token Theft: In authentication flows, authorization codes or tokens may leak via redirect\n* Referer Leakage: Sensitive URL parameters may be exposed to attacker domains via the Referer header\n* Cache Poisoning: In deployments with shared caches, malicious redirects may be cached and served to other users",
"id": "GHSA-xxhq-69mf-w8cr",
"modified": "2026-06-23T16:42:02Z",
"published": "2026-06-23T16:42:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/security/advisories/GHSA-xxhq-69mf-w8cr"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/pull/8322"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/commit/c5da9631dc75f692f313373ae229c4d47ba6517f"
},
{
"type": "PACKAGE",
"url": "https://github.com/gogs/gogs"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
}
],
"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": "Gogs has an Open Redirect via redirect_to"
}
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.