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.
2685 vulnerabilities reference this CWE, most recent first.
GHSA-JHCR-83JP-PJVR
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14Kibana versions before 4.6.3 and 5.0.1 have an open redirect vulnerability that would enable an attacker to craft a link in the Kibana domain that redirects to an arbitrary website.
{
"affected": [],
"aliases": [
"CVE-2016-10365"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-16T21:29:00Z",
"severity": "MODERATE"
},
"details": "Kibana versions before 4.6.3 and 5.0.1 have an open redirect vulnerability that would enable an attacker to craft a link in the Kibana domain that redirects to an arbitrary website.",
"id": "GHSA-jhcr-83jp-pjvr",
"modified": "2022-05-13T01:14:31Z",
"published": "2022-05-13T01:14:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10365"
},
{
"type": "WEB",
"url": "https://www.elastic.co/community/security"
}
],
"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-JHFR-W52P-37QV
Vulnerability from github – Published: 2023-06-05 18:30 – Updated: 2023-06-05 18:30A vulnerability classified as problematic was found in WooFramework Tweaks Plugin up to 1.0.1 on WordPress. Affected by this vulnerability is the function admin_screen_logic of the file wooframework-tweaks.php. The manipulation of the argument url leads to open redirect. The attack can be launched remotely. Upgrading to version 1.0.2 is able to address this issue. The identifier of the patch is 3b57d405149c1a59d1119da6e0bb8212732c9c88. It is recommended to upgrade the affected component. The identifier VDB-230653 was assigned to this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2015-10113"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-05T16:15:09Z",
"severity": "MODERATE"
},
"details": "A vulnerability classified as problematic was found in WooFramework Tweaks Plugin up to 1.0.1 on WordPress. Affected by this vulnerability is the function admin_screen_logic of the file wooframework-tweaks.php. The manipulation of the argument url leads to open redirect. The attack can be launched remotely. Upgrading to version 1.0.2 is able to address this issue. The identifier of the patch is 3b57d405149c1a59d1119da6e0bb8212732c9c88. It is recommended to upgrade the affected component. The identifier VDB-230653 was assigned to this vulnerability.",
"id": "GHSA-jhfr-w52p-37qv",
"modified": "2023-06-05T18:30:27Z",
"published": "2023-06-05T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-10113"
},
{
"type": "WEB",
"url": "https://github.com/wp-plugins/wooframework-tweaks/commit/3b57d405149c1a59d1119da6e0bb8212732c9c88"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.230653"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.230653"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JHQW-CQ3Q-2P2G
Vulnerability from github – Published: 2025-02-18 15:31 – Updated: 2026-06-06 09:31URL Redirection to Untrusted Site ('Open Redirect') vulnerability in HAVELSAN Liman MYS allows Cross-Site Flashing.This issue affects Liman MYS: before 2.1.1 - 1010.
{
"affected": [],
"aliases": [
"CVE-2025-1269"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T14:15:28Z",
"severity": "MODERATE"
},
"details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in HAVELSAN Liman MYS allows Cross-Site Flashing.This issue affects Liman MYS: before 2.1.1 - 1010.",
"id": "GHSA-jhqw-cq3q-2p2g",
"modified": "2026-06-06T09:31:11Z",
"published": "2025-02-18T15:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1269"
},
{
"type": "WEB",
"url": "https://github.com/limanmys/core/releases/tag/release.master.1010"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0038"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-25-0038"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-JJ3P-6MW3-6QMM
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2023-02-13 00:30A vulnerability was found in Moodle 3.7 to 3.7.1, 3.6 to 3.6.5, 3.5 to 3.5.7 and earlier unsupported versions, where the mobile launch endpoint contained an open redirect in some circumstances, which could result in a user's mobile access token being exposed. (Note: This does not affect sites with a forced URL scheme configured, mobile service disabled, or where the mobile app login method is "via the app").
{
"affected": [],
"aliases": [
"CVE-2019-14830"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-19T21:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Moodle 3.7 to 3.7.1, 3.6 to 3.6.5, 3.5 to 3.5.7 and earlier unsupported versions, where the mobile launch endpoint contained an open redirect in some circumstances, which could result in a user\u0027s mobile access token being exposed. (Note: This does not affect sites with a forced URL scheme configured, mobile service disabled, or where the mobile app login method is \"via the app\").",
"id": "GHSA-jj3p-6mw3-6qmm",
"modified": "2023-02-13T00:30:58Z",
"published": "2022-05-24T17:44:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14830"
},
{
"type": "WEB",
"url": "https://git.moodle.org/gw?p=moodle.git%3Ba=commit%3Bh=d4985a77391123c5959db432c076328f8d5e3624"
},
{
"type": "WEB",
"url": "https://git.moodle.org/gw?p=moodle.git;a=commit;h=d4985a77391123c5959db432c076328f8d5e3624"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=391036"
}
],
"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-JJ78-5FMV-MV28
Vulnerability from github – Published: 2024-10-03 21:31 – Updated: 2024-10-09 23:46URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Express. This vulnerability affects the use of the Express Response object. This issue impacts Express: from 3.4.5 before 4.0.0-rc1.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "express"
},
"ranges": [
{
"events": [
{
"introduced": "3.4.5"
},
{
"fixed": "4.0.0-rc1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-9266"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-09T17:03:12Z",
"nvd_published_at": "2024-10-03T19:15:05Z",
"severity": "LOW"
},
"details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in Express. This vulnerability affects the use of the Express Response object. This issue impacts Express: from 3.4.5 before 4.0.0-rc1.",
"id": "GHSA-jj78-5fmv-mv28",
"modified": "2024-10-09T23:46:55Z",
"published": "2024-10-03T21:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9266"
},
{
"type": "PACKAGE",
"url": "https://github.com/expressjs/express"
},
{
"type": "WEB",
"url": "https://github.com/expressjs/express/compare/3.4.4...3.4.5"
},
{
"type": "WEB",
"url": "https://www.herodevs.com/vulnerability-directory/cve-2024-9266"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Express Open Redirect vulnerability"
}
GHSA-JJ7H-C3HG-M23X
Vulnerability from github – Published: 2026-10-27 15:37 – Updated: 2026-10-27 15:37Summary
authlib.common.security.is_secure_transport() is used throughout Authlib to enforce the OAuth 2.0 / OIDC requirement that endpoint and redirect URIs use TLS, with an RFC 8252 §7.3 exemption for loopback http:// URIs. The check is implemented as a textual str.startswith prefix match, so a URL such as http://localhost:80@evil.example/cb — whose actual host is evil.example and whose scheme is plain http — is accepted as "secure". An attacker who can supply a URL to any of the sinks that rely on this check (OIDC RP-Initiated Logout dynamic client registration, RFC 8414 authorization-server metadata validation, error-redirect rendering) can smuggle a cleartext non-loopback URL past the TLS-required guard. This is a defense-in-depth / spec-conformance failure; severity is low.
Details
Affected versions: authlib >= 0.13, <= 1.7.2 (all releases containing the loopback prefix exemption; verified against 1.7.2, the current latest)
The vulnerable function, from authlib/common/security.py at v1.7.2:
13 def is_secure_transport(uri):
14 """Check if the uri is over ssl."""
15 if os.getenv("AUTHLIB_INSECURE_TRANSPORT"):
16 return True
17
18 uri = uri.lower()
19 return uri.startswith(
20 ("https://", "http://localhost:", "http://127.0.0.1:", "http://[::1]:")
21 )
Per RFC 3986 §3.2 the authority component of a URI is [ userinfo "@" ] host [ ":" port ]. The URL http://localhost:80@evil.example/cb therefore has userinfo localhost:80 and host evil.example. Because the check is a raw prefix match against the full URL string, the http://localhost: prefix matches the userinfo portion and the function returns True even though the scheme is http and the host is an arbitrary external name. The trailing : in each allow-list entry — presumably intended to force a host:port shape and reject http://localhost.evil.com — is also satisfied by the user:password separator inside userinfo, so http://localhost:@evil.example/ matches too. The same construction works against all three loopback prefixes (http://127.0.0.1:...@evil.example/, http://[::1]:...@evil.example/).
is_secure_transport() is consumed at the following locations in v1.7.2, none of which independently reject URLs containing a userinfo component:
authlib/oidc/rpinitiated/registration.py:50-57— validation ofpost_logout_redirect_urisduring OIDC dynamic client registration for public clients (token_endpoint_auth_method == "none"). The precedingis_valid_url()check (authlib/common/urls.py:142-146) only requiresparsed.scheme and parsed.hostnameand does not reject userinfo, so the crafted URL passes both guards. A public client can therefore registerhttp://localhost:80@attacker.example/cbas a post-logout redirect target; the OpenID Provider will later 302 the end-user's browser to that cleartext non-loopback URL (carryingstate).authlib/oauth2/rfc8414/models.py:61,75,100,115,123,248,284— validation ofissuer,authorization_endpoint,token_endpoint,jwks_uri,registration_endpoint,revocation_endpoint,introspection_endpointin Authorization Server Metadata / OIDC Discovery documents. A relying party usingAuthorizationServerMetadata.validate()would accept endpoint values of this form as satisfying the "MUST use https" requirement when they do not.authlib/oidc/rpinitiated/discovery.py:12— validation ofend_session_endpointin provider metadata.authlib/oauth2/rfc6749/errors.py:64andauthlib/oauth1/rfc5849/errors.py:33— governs howredirect_uriis rendered in error bodies (cosmetic).
The http://localhost: prefix was introduced in commit 0225c86b (first released in v0.13); http://127.0.0.1: and http://[::1]: were added later in the 1.6.x line. All variants share the same prefix-match weakness.
PoC
Against the current latest release (1.7.2):
python3 -m venv venv
./venv/bin/pip install 'authlib==1.7.2'
./venv/bin/python poc.py
poc.py:
#!/usr/bin/env python3
"""
is_secure_transport() must return True only for https:// URLs, or http://
URLs whose host is a loopback address (localhost / 127.0.0.1 / ::1).
Bypass: http://localhost:80@evil.example/cb has host 'evil.example'
(userinfo = 'localhost:80') per RFC 3986, but matches the prefix
'http://localhost:' and is therefore accepted as secure.
"""
from urllib.parse import urlparse
from authlib.common.security import is_secure_transport
cases = [
"http://localhost:80@evil.example/cb",
"http://127.0.0.1:80@evil.example/cb",
"http://localhost:@evil.example/cb",
]
vulnerable = False
for url in cases:
parsed = urlparse(url)
ok = is_secure_transport(url)
print(f"is_secure_transport({url!r}) = {ok} "
f"[actual host = {parsed.hostname!r}, scheme = {parsed.scheme!r}]")
if ok and parsed.hostname not in ("localhost", "127.0.0.1", "::1") and parsed.scheme != "https":
vulnerable = True
if vulnerable:
print("\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP "
"URL whose host is NOT a loopback address.")
else:
print("\nNOT VULNERABLE")
assert vulnerable, "expected bypass not observed"
Expected output:
is_secure_transport('http://localhost:80@evil.example/cb') = True [actual host = 'evil.example', scheme = 'http']
is_secure_transport('http://127.0.0.1:80@evil.example/cb') = True [actual host = 'evil.example', scheme = 'http']
is_secure_transport('http://localhost:@evil.example/cb') = True [actual host = 'evil.example', scheme = 'http']
VULNERABLE: is_secure_transport() returned True for a plain-HTTP URL whose host is NOT a loopback address.
Impact
Deployments are affected if they rely on is_secure_transport() — directly or via the Authlib call sites listed above — to reject cleartext non-loopback URLs supplied by an external party. The most realistic path is an OpenID Provider that enables OIDC dynamic client registration and RP-Initiated Logout: a public client can register a post_logout_redirect_uris entry of the form http://localhost:80@attacker.example/…, which the provider will later use as an open-redirect target over plain HTTP. Relying parties that call AuthorizationServerMetadata.validate() on fetched discovery documents are also affected, though exploiting that sink requires the attacker to influence the metadata document. This does not bypass the OAuth 2.0 redirect-URI exact-match registration check and does not by itself yield authentication bypass or token theft; it defeats a TLS-required hardening check.
Suggested fix: Parse the URI with urllib.parse.urlsplit() and return True only if scheme == "https", or scheme == "http" and hostname in {"localhost", "127.0.0.1", "::1"}; additionally reject any URI whose parsed username/password is non-empty at these validation sites.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.7.2"
},
"package": {
"ecosystem": "PyPI",
"name": "authlib"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-114614"
],
"database_specific": {
"cwe_ids": [
"CWE-319",
"CWE-601",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-27T15:37:48Z",
"nvd_published_at": "2026-10-22T21:17:16Z",
"severity": "LOW"
},
"details": "### Summary\n`authlib.common.security.is_secure_transport()` is used throughout Authlib to enforce the OAuth 2.0 / OIDC requirement that endpoint and redirect URIs use TLS, with an RFC 8252 \u00a77.3 exemption for loopback `http://` URIs. The check is implemented as a textual `str.startswith` prefix match, so a URL such as `http://localhost:80@evil.example/cb` \u2014 whose actual host is `evil.example` and whose scheme is plain `http` \u2014 is accepted as \"secure\". An attacker who can supply a URL to any of the sinks that rely on this check (OIDC RP-Initiated Logout dynamic client registration, RFC 8414 authorization-server metadata validation, error-redirect rendering) can smuggle a cleartext non-loopback URL past the TLS-required guard. This is a defense-in-depth / spec-conformance failure; severity is low.\n\n### Details\n**Affected versions:** `authlib \u003e= 0.13, \u003c= 1.7.2` (all releases containing the loopback prefix exemption; verified against 1.7.2, the current latest)\n\nThe vulnerable function, from `authlib/common/security.py` at v1.7.2:\n\n```python\n13 def is_secure_transport(uri):\n14 \"\"\"Check if the uri is over ssl.\"\"\"\n15 if os.getenv(\"AUTHLIB_INSECURE_TRANSPORT\"):\n16 return True\n17\n18 uri = uri.lower()\n19 return uri.startswith(\n20 (\"https://\", \"http://localhost:\", \"http://127.0.0.1:\", \"http://[::1]:\")\n21 )\n```\n\nPer RFC 3986 \u00a73.2 the authority component of a URI is `[ userinfo \"@\" ] host [ \":\" port ]`. The URL `http://localhost:80@evil.example/cb` therefore has userinfo `localhost:80` and host `evil.example`. Because the check is a raw prefix match against the full URL string, the `http://localhost:` prefix matches the userinfo portion and the function returns `True` even though the scheme is `http` and the host is an arbitrary external name. The trailing `:` in each allow-list entry \u2014 presumably intended to force a `host:port` shape and reject `http://localhost.evil.com` \u2014 is also satisfied by the `user:password` separator inside userinfo, so `http://localhost:@evil.example/` matches too. The same construction works against all three loopback prefixes (`http://127.0.0.1:...@evil.example/`, `http://[::1]:...@evil.example/`).\n\n`is_secure_transport()` is consumed at the following locations in v1.7.2, none of which independently reject URLs containing a userinfo component:\n\n- `authlib/oidc/rpinitiated/registration.py:50-57` \u2014 validation of `post_logout_redirect_uris` during OIDC dynamic client registration for public clients (`token_endpoint_auth_method == \"none\"`). The preceding `is_valid_url()` check (`authlib/common/urls.py:142-146`) only requires `parsed.scheme and parsed.hostname` and does **not** reject userinfo, so the crafted URL passes both guards. A public client can therefore register `http://localhost:80@attacker.example/cb` as a post-logout redirect target; the OpenID Provider will later 302 the end-user\u0027s browser to that cleartext non-loopback URL (carrying `state`).\n- `authlib/oauth2/rfc8414/models.py:61,75,100,115,123,248,284` \u2014 validation of `issuer`, `authorization_endpoint`, `token_endpoint`, `jwks_uri`, `registration_endpoint`, `revocation_endpoint`, `introspection_endpoint` in Authorization Server Metadata / OIDC Discovery documents. A relying party using `AuthorizationServerMetadata.validate()` would accept endpoint values of this form as satisfying the \"MUST use https\" requirement when they do not.\n- `authlib/oidc/rpinitiated/discovery.py:12` \u2014 validation of `end_session_endpoint` in provider metadata.\n- `authlib/oauth2/rfc6749/errors.py:64` and `authlib/oauth1/rfc5849/errors.py:33` \u2014 governs how `redirect_uri` is rendered in error bodies (cosmetic).\n\nThe `http://localhost:` prefix was introduced in commit `0225c86b` (first released in v0.13); `http://127.0.0.1:` and `http://[::1]:` were added later in the 1.6.x line. All variants share the same prefix-match weakness.\n\n### PoC\nAgainst the current latest release (1.7.2):\n\n```sh\npython3 -m venv venv\n./venv/bin/pip install \u0027authlib==1.7.2\u0027\n./venv/bin/python poc.py\n```\n\n`poc.py`:\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nis_secure_transport() must return True only for https:// URLs, or http://\nURLs whose host is a loopback address (localhost / 127.0.0.1 / ::1).\n\nBypass: http://localhost:80@evil.example/cb has host \u0027evil.example\u0027\n(userinfo = \u0027localhost:80\u0027) per RFC 3986, but matches the prefix\n\u0027http://localhost:\u0027 and is therefore accepted as secure.\n\"\"\"\nfrom urllib.parse import urlparse\nfrom authlib.common.security import is_secure_transport\n\ncases = [\n \"http://localhost:80@evil.example/cb\",\n \"http://127.0.0.1:80@evil.example/cb\",\n \"http://localhost:@evil.example/cb\",\n]\n\nvulnerable = False\nfor url in cases:\n parsed = urlparse(url)\n ok = is_secure_transport(url)\n print(f\"is_secure_transport({url!r}) = {ok} \"\n f\"[actual host = {parsed.hostname!r}, scheme = {parsed.scheme!r}]\")\n if ok and parsed.hostname not in (\"localhost\", \"127.0.0.1\", \"::1\") and parsed.scheme != \"https\":\n vulnerable = True\n\nif vulnerable:\n print(\"\\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP \"\n \"URL whose host is NOT a loopback address.\")\nelse:\n print(\"\\nNOT VULNERABLE\")\n\nassert vulnerable, \"expected bypass not observed\"\n```\n\nExpected output:\n\n```\nis_secure_transport(\u0027http://localhost:80@evil.example/cb\u0027) = True [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\nis_secure_transport(\u0027http://127.0.0.1:80@evil.example/cb\u0027) = True [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\nis_secure_transport(\u0027http://localhost:@evil.example/cb\u0027) = True [actual host = \u0027evil.example\u0027, scheme = \u0027http\u0027]\n\nVULNERABLE: is_secure_transport() returned True for a plain-HTTP URL whose host is NOT a loopback address.\n```\n\n### Impact\nDeployments are affected if they rely on `is_secure_transport()` \u2014 directly or via the Authlib call sites listed above \u2014 to reject cleartext non-loopback URLs supplied by an external party. The most realistic path is an OpenID Provider that enables OIDC dynamic client registration and RP-Initiated Logout: a public client can register a `post_logout_redirect_uris` entry of the form `http://localhost:80@attacker.example/\u2026`, which the provider will later use as an open-redirect target over plain HTTP. Relying parties that call `AuthorizationServerMetadata.validate()` on fetched discovery documents are also affected, though exploiting that sink requires the attacker to influence the metadata document. This does **not** bypass the OAuth 2.0 redirect-URI exact-match registration check and does not by itself yield authentication bypass or token theft; it defeats a TLS-required hardening check.\n\n**Suggested fix:** Parse the URI with `urllib.parse.urlsplit()` and return `True` only if `scheme == \"https\"`, or `scheme == \"http\"` and `hostname in {\"localhost\", \"127.0.0.1\", \"::1\"}`; additionally reject any URI whose parsed `username`/`password` is non-empty at these validation sites.",
"id": "GHSA-jj7h-c3hg-m23x",
"modified": "2026-10-27T15:37:48Z",
"published": "2026-10-27T15:37:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authlib/authlib/security/advisories/GHSA-jj7h-c3hg-m23x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114614"
},
{
"type": "WEB",
"url": "https://github.com/authlib/authlib/commit/95ad1f90acf0c7b9cf2a8f25e6eb3f1135b8dc70"
},
{
"type": "PACKAGE",
"url": "https://github.com/authlib/authlib"
},
{
"type": "WEB",
"url": "https://github.com/authlib/authlib/releases/tag/v1.8.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Authlib: is_secure_transport() loopback exemption can be bypassed with a userinfo component, allowing cleartext-HTTP URLs to non-loopback hosts"
}
GHSA-JJHM-F66G-QVQ9
Vulnerability from github – Published: 2022-05-17 03:00 – Updated: 2022-05-17 03:00IBM BigFix Inventory v9 could allow a remote attacker to conduct phishing attacks, using an open redirect attack. By persuading a victim to visit a specially-crafted Web site, a remote attacker could exploit this vulnerability to spoof the URL displayed to redirect a user to a malicious Web site that would appear to be trusted. This could allow the attacker to obtain highly sensitive information or conduct further attacks against the victim.
{
"affected": [],
"aliases": [
"CVE-2016-8961"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-01T20:59:00Z",
"severity": "MODERATE"
},
"details": "IBM BigFix Inventory v9 could allow a remote attacker to conduct phishing attacks, using an open redirect attack. By persuading a victim to visit a specially-crafted Web site, a remote attacker could exploit this vulnerability to spoof the URL displayed to redirect a user to a malicious Web site that would appear to be trusted. This could allow the attacker to obtain highly sensitive information or conduct further attacks against the victim.",
"id": "GHSA-jjhm-f66g-qvq9",
"modified": "2022-05-17T03:00:00Z",
"published": "2022-05-17T03:00:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8961"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg21995037"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95128"
}
],
"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-JJJG-67RC-QF87
Vulnerability from github – Published: 2026-08-13 18:31 – Updated: 2026-08-13 18:31Saurus CMS Community Edition contains an unauthenticated open redirect vulnerability in the logout handling code in classes/port.inc.php, where the url parameter supplied via GET or POST is passed directly to the Location header without domain allowlist, scheme validation, or relative path enforcement. Attackers can craft a malicious logout URL containing an arbitrary external domain or javascript: URI scheme to redirect authenticated users to attacker-controlled phishing pages after session destruction, enabling credential theft and OAuth redirect abuse.
{
"affected": [],
"aliases": [
"CVE-2026-73671"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T16:19:07Z",
"severity": "MODERATE"
},
"details": "Saurus CMS Community Edition contains an unauthenticated open redirect vulnerability in the logout handling code in classes/port.inc.php, where the url parameter supplied via GET or POST is passed directly to the Location header without domain allowlist, scheme validation, or relative path enforcement. Attackers can craft a malicious logout URL containing an arbitrary external domain or javascript: URI scheme to redirect authenticated users to attacker-controlled phishing pages after session destruction, enabling credential theft and OAuth redirect abuse.",
"id": "GHSA-jjjg-67rc-qf87",
"modified": "2026-08-13T18:31:38Z",
"published": "2026-08-13T18:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73671"
},
{
"type": "WEB",
"url": "https://github.com/DevVaibhav07/VULN-POC/blob/main/Saurus_OpenRedirect.md"
},
{
"type": "WEB",
"url": "https://github.com/sauruscms/Saurus-CMS-Community-Edition"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/saurus-cms-unauthenticated-open-redirect-via-logout-url-parameter"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-JJMJ-JMHJ-QWJ2
Vulnerability from github – Published: 2026-07-23 19:36 – Updated: 2026-09-08 15:09Applications with open redirects could permit attacker crafted links to result in redirects to unexpected external location or XSS vectors.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.30.5"
},
"package": {
"ecosystem": "npm",
"name": "react-router-dom"
},
"ranges": [
{
"events": [
{
"introduced": "6.30.2"
},
{
"fixed": "6.30.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.12.0"
},
"package": {
"ecosystem": "npm",
"name": "react-router"
},
"ranges": [
{
"events": [
{
"introduced": "7.9.6"
},
{
"fixed": "7.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53668"
],
"database_specific": {
"cwe_ids": [
"CWE-601",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T19:36:31Z",
"nvd_published_at": "2026-07-27T22:17:31Z",
"severity": "MODERATE"
},
"details": "Applications with open redirects could permit attacker crafted links to result in redirects to unexpected external location or XSS vectors.",
"id": "GHSA-jjmj-jmhj-qwj2",
"modified": "2026-09-08T15:09:27Z",
"published": "2026-07-23T19:36:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/security/advisories/GHSA-jjmj-jmhj-qwj2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53668"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/pull/14718"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/commit/3a5b5ad0e5cf9918c646509563f5c41a89226ff3"
},
{
"type": "PACKAGE",
"url": "https://github.com/remix-run/react-router"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v7180"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/blob/v6/CHANGELOG.md#v6306"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/releases/tag/react-router@6.30.6"
},
{
"type": "WEB",
"url": "https://github.com/remix-run/react-router/releases/tag/react-router@7.18.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "React Router: Open redirect leading to XSS"
}
GHSA-JJVJ-F9JX-5JV4
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42On BIG-IP Advanced WAF and ASM version 15.1.x before 15.1.0.2, 15.0.x before 15.0.1.4, 14.1.x before 14.1.2.5, 13.1.x before 13.1.3.4, 12.1.x before 12.1.5.2, and 11.6.x before 11.6.5.2, when receiving a unauthenticated client request with a maliciously crafted URI, a BIG-IP Advanced WAF or ASM virtual server configured with a DoS profile with Proactive Bot Defense (versions prior to 14.1.0), or a Bot Defense profile (versions 14.1.0 and later), may subject clients and web servers to Open Redirection attacks. Note: Software versions which have reached End of Software Development (EoSD) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2021-22984"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-12T20:15:00Z",
"severity": "MODERATE"
},
"details": "On BIG-IP Advanced WAF and ASM version 15.1.x before 15.1.0.2, 15.0.x before 15.0.1.4, 14.1.x before 14.1.2.5, 13.1.x before 13.1.3.4, 12.1.x before 12.1.5.2, and 11.6.x before 11.6.5.2, when receiving a unauthenticated client request with a maliciously crafted URI, a BIG-IP Advanced WAF or ASM virtual server configured with a DoS profile with Proactive Bot Defense (versions prior to 14.1.0), or a Bot Defense profile (versions 14.1.0 and later), may subject clients and web servers to Open Redirection attacks. Note: Software versions which have reached End of Software Development (EoSD) are not evaluated.",
"id": "GHSA-jjvj-f9jx-5jv4",
"modified": "2022-05-24T17:42:06Z",
"published": "2022-05-24T17:42:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22984"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K33440533"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.