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.
2305 vulnerabilities reference this CWE, most recent first.
GHSA-4RQW-R289-96FW
Vulnerability from github – Published: 2022-05-17 02:27 – Updated: 2022-05-17 02:27IBM Emptoris Sourcing 9.5.x through 10.1.x 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. IBM X-Force ID: 118840.
{
"affected": [],
"aliases": [
"CVE-2016-8953"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-12T17:29:00Z",
"severity": "MODERATE"
},
"details": "IBM Emptoris Sourcing 9.5.x through 10.1.x 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. IBM X-Force ID: 118840.",
"id": "GHSA-4rqw-r289-96fw",
"modified": "2022-05-17T02:27:15Z",
"published": "2022-05-17T02:27:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8953"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/118840"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg22005549"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99545"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4V2V-P6M7-Q4JJ
Vulnerability from github – Published: 2022-05-14 03:20 – Updated: 2022-05-14 03:20MyBB 1.8.15, when accessed with Microsoft Edge, mishandles 'target="_blank" rel="noopener"' in A elements, which makes it easier for remote attackers to conduct redirection attacks.
{
"affected": [],
"aliases": [
"CVE-2018-10678"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-13T20:29:00Z",
"severity": "MODERATE"
},
"details": "MyBB 1.8.15, when accessed with Microsoft Edge, mishandles \u0027target=\"_blank\" rel=\"noopener\"\u0027 in A elements, which makes it easier for remote attackers to conduct redirection attacks.",
"id": "GHSA-4v2v-p6m7-q4jj",
"modified": "2022-05-14T03:20:28Z",
"published": "2022-05-14T03:20:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10678"
},
{
"type": "WEB",
"url": "https://gist.github.com/MayurUdiniya/7aaa50b878d82b6aab6ed0b3e2b080bc"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104187"
}
],
"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-4WCP-H664-5XC6
Vulnerability from github – Published: 2022-01-25 00:01 – Updated: 2022-01-29 00:01The WebP Converter for Media WordPress plugin before 4.0.3 contains a file (passthru.php) which does not validate the src parameter before redirecting the user to it, leading to an Open Redirect issue
{
"affected": [],
"aliases": [
"CVE-2021-25074"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-24T08:15:00Z",
"severity": "MODERATE"
},
"details": "The WebP Converter for Media WordPress plugin before 4.0.3 contains a file (passthru.php) which does not validate the src parameter before redirecting the user to it, leading to an Open Redirect issue",
"id": "GHSA-4wcp-h664-5xc6",
"modified": "2022-01-29T00:01:01Z",
"published": "2022-01-25T00:01:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25074"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/f3c0a155-9563-4533-97d4-03b9bac83164"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4WM2-CWCF-WWVP
Vulnerability from github – Published: 2023-05-03 21:57 – Updated: 2023-05-03 21:57Impact
The Tauri IPC is usually strictly isolated from external websites but the isolation can be bypassed by redirecting an existing Tauri window to an external website. This is either possible by an application implementing a feature for users to visit arbitrary websites or due to a bug allowing the open redirect^open-redirect.
This allows the external website access to the IPC layer and therefore to all configured and exposed Tauri API endpoints and application specific implemented Tauri commands.
Patches
This issue has been patched in the latest release and was backported to all previous 1.x releases.
Workarounds
Prevent arbitrary input in redirect features. Only allow trusted websites access to the IPC.
References
The feature to enable this behavior in a more constrained way was introduced in the 1.3 release and documentation around this can be found in the documentation.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tauri"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "tauri"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.0"
},
{
"fixed": "1.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "tauri"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-31134"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-03T21:57:22Z",
"nvd_published_at": "2023-05-09T14:15:13Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe Tauri IPC is usually strictly isolated from external websites but the isolation can be bypassed by redirecting an existing Tauri window to an external website. This is either possible by an application implementing a feature for users to visit arbitrary websites or due to a bug allowing the open redirect[^open-redirect].\n\nThis allows the external website access to the IPC layer and therefore to all configured and exposed Tauri API endpoints and application specific implemented Tauri commands.\n\n### Patches\nThis issue has been patched in the latest release and was backported to all previous `1.x` releases.\n\n### Workarounds\nPrevent arbitrary input in redirect features. Only allow trusted websites access to the IPC.\n\n### References\n\nThe feature to enable this behavior in a more constrained way was introduced in the `1.3` release and documentation around this can be found in the [documentation](https://tauri.app/v1/api/config/#securityconfig.dangerousremotedomainipcaccess).\n\n[^open-redirect]: [https://en.wikipedia.org/wiki/Open_redirect](https://en.wikipedia.org/wiki/Open_redirect)\n",
"id": "GHSA-4wm2-cwcf-wwvp",
"modified": "2023-05-03T21:57:22Z",
"published": "2023-05-03T21:57:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tauri-apps/tauri/security/advisories/GHSA-4wm2-cwcf-wwvp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31134"
},
{
"type": "WEB",
"url": "https://github.com/tauri-apps/tauri/commit/9c0593c33af52cd9e00ec784d15f63efebdf039c"
},
{
"type": "WEB",
"url": "https://en.wikipedia.org/wiki/Open_redirect"
},
{
"type": "PACKAGE",
"url": "https://github.com/tauri-apps/tauri"
},
{
"type": "WEB",
"url": "https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.0.9"
},
{
"type": "WEB",
"url": "https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.1.4"
},
{
"type": "WEB",
"url": "https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.2.5"
},
{
"type": "WEB",
"url": "https://tauri.app/v1/api/config/#securityconfig.dangerousremotedomainipcaccess"
},
{
"type": "WEB",
"url": "https://www.github.com/tauri-apps/tauri/commit/58ea0b45268dbd46cbac0ebb0887353d057ca767"
},
{
"type": "WEB",
"url": "https://www.github.com/tauri-apps/tauri/commit/fa90214b052b1a5d38d54fbf1ca422b4c37cfd1f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Tauri Open Redirect Vulnerability Possibly Exposes IPC to External Sites"
}
GHSA-4X3X-869W-XX3M
Vulnerability from github – Published: 2026-06-04 19:32 – Updated: 2026-06-04 19:32Description
This report describes an open redirect in Shopware's public SSO entry point at GET /api/oauth/sso/auth. When the endpoint is reached without the expected SSO session state, the application falls back to the request's Referer header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as javascript:. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata.
The security problem is not limited to a harmless navigation mismatch. The endpoint sits under /api/oauth/, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP 302 with a user-controlled Location header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to https://attacker.example/poc when that URL is supplied through Referer, and it also reflects javascript:alert(1) into Location and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect.
Steps To Reproduce
- Start a local Shopware instance that exposes the vulnerable endpoint at
http://127.0.0.1:8000/api/oauth/sso/auth. No login is required for the proof. The attached Python PoC already targets that base URL and is configured to send direct requests without following redirects automatically. - Run the attached PoC with
python3 poc_sso_referer_open_redirect.py. The script sends three requests toGET /api/oauth/sso/authand records the raw responses as evidence files. The first request omits theRefererheader entirely. The second request suppliesReferer: https://attacker.example/poc. The third request suppliesReferer: javascript:alert(1). - Inspect the first recorded response in
evidence/sso_redirect_no_referer.raw.txt. In the validated run, the endpoint returns401with the messageReferrer not found. Cannot redirect.This shows that the code path being exercised is the unauthenticated fallback behavior that depends onRefererwhen the expected SSO state is missing. - Inspect
evidence/sso_redirect_https_redirect.raw.txt. In the validated run, the endpoint returns302and setsLocation: https://attacker.example/poc. The HTML body also contains a meta refresh tag and redirect link pointing to the same external URL. This demonstrates that the server accepts an attacker-controlled external target and emits it as a redirect destination. - Inspect
evidence/sso_redirect_javascript_redirect.raw.txt. In the validated run, the endpoint again returns302, but this time the response setsLocation: javascript:alert(1). The HTML body mirrors the samejavascript:target in both the meta refresh tag and the anchor. This demonstrates that the fallback redirect does not even enforce anhttporhttpsscheme restriction before constructing the response. - Compare the PoC summary in
evidence/poc_sso_referer_open_redirect.output.txtwith the raw responses. The validated run shows401when noRefereris present,302tohttps://attacker.example/pocwhen an external HTTPS URL is supplied, and302tojavascript:alert(1)when a dangerous scheme is supplied. That behavior confirms the endpoint can be used as an open redirect with an arbitrary redirect target controlled throughReferer.
Recommendations
The endpoint should stop using Referer as a fallback redirect target when the expected SSO state is missing. If the application cannot complete the SSO flow because the required session state does not exist, it should return a fixed error response or redirect only to a fixed internal page that is not influenced by request headers. Referer is not a trustworthy source of navigation intent and should not be treated as an authorization or routing signal for security-sensitive redirect logic.
If the product needs to preserve a return destination, that destination should be derived from a server-generated state value or validated against a strict allowlist. At minimum, the code should reject non-HTTP schemes, reject scheme-relative targets such as //host, and reject absolute URLs that are not same-origin with the current Shopware instance. A regression test should cover the exact cases proven here: no Referer, an external HTTPS Referer, and a javascript: Referer, with assertions that none of the attacker-controlled values can be emitted into Location or the HTML redirect body.
Impact
The demonstrated impact is that an unauthenticated attacker can cause a trusted Shopware endpoint to emit arbitrary redirect targets chosen through the request's Referer header. In the minimum case, that enables standard open redirect abuse for phishing, brand impersonation, and redirect chaining through a legitimate application origin. Because the redirect is served from /api/oauth/sso/auth, the resulting URL can look more trustworthy than a generic off-site redirect and may be more likely to be followed by users or client software that expects the endpoint to participate in an authentication flow.
The validated evidence also shows that the endpoint does not restrict the redirect target to ordinary web URLs. It reflects javascript:alert(1) directly into Location and into the HTML redirect page. This report keeps the claim conservative and classifies the issue as an open redirect with arbitrary redirect targets, but the acceptance of dangerous schemes makes the behavior more severe than a simple same-browser redirect to another HTTPS site and increases the risk of downstream abuse depending on client behavior.
Note on submission channel:
I initially attempted to submit this issue through Shopware’s official security reporting form. The form backend returned HTTP 400 for normal submissions, and when an attachment was included it explicitly rejected .md, .py, .zip files with the message File type not allowed. Because the official form was not functioning correctly for me, I am submitting this report privately through GitHub’s vulnerability reporting flow.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.3.0"
},
{
"fixed": "6.7.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.3.0"
},
{
"fixed": "6.7.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48012"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-04T19:32:35Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Description\n\nThis report describes an open redirect in Shopware\u0027s public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request\u0027s `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata.\n\nThe security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect.\n\n## Steps To Reproduce\n\n1. Start a local Shopware instance that exposes the vulnerable endpoint at `http://127.0.0.1:8000/api/oauth/sso/auth`. No login is required for the proof. The attached Python PoC already targets that base URL and is configured to send direct requests without following redirects automatically.\n2. Run the attached PoC with `python3 poc_sso_referer_open_redirect.py`. The script sends three requests to `GET /api/oauth/sso/auth` and records the raw responses as evidence files. The first request omits the `Referer` header entirely. The second request supplies `Referer: https://attacker.example/poc`. The third request supplies `Referer: javascript:alert(1)`.\n3. Inspect the first recorded response in `evidence/sso_redirect_no_referer.raw.txt`. In the validated run, the endpoint returns `401` with the message `Referrer not found. Cannot redirect.` This shows that the code path being exercised is the unauthenticated fallback behavior that depends on `Referer` when the expected SSO state is missing.\n4. Inspect `evidence/sso_redirect_https_redirect.raw.txt`. In the validated run, the endpoint returns `302` and sets `Location: https://attacker.example/poc`. The HTML body also contains a meta refresh tag and redirect link pointing to the same external URL. This demonstrates that the server accepts an attacker-controlled external target and emits it as a redirect destination.\n5. Inspect `evidence/sso_redirect_javascript_redirect.raw.txt`. In the validated run, the endpoint again returns `302`, but this time the response sets `Location: javascript:alert(1)`. The HTML body mirrors the same `javascript:` target in both the meta refresh tag and the anchor. This demonstrates that the fallback redirect does not even enforce an `http` or `https` scheme restriction before constructing the response.\n6. Compare the PoC summary in `evidence/poc_sso_referer_open_redirect.output.txt` with the raw responses. The validated run shows `401` when no `Referer` is present, `302` to `https://attacker.example/poc` when an external HTTPS URL is supplied, and `302` to `javascript:alert(1)` when a dangerous scheme is supplied. That behavior confirms the endpoint can be used as an open redirect with an arbitrary redirect target controlled through `Referer`.\n\n## Recommendations\n\nThe endpoint should stop using `Referer` as a fallback redirect target when the expected SSO state is missing. If the application cannot complete the SSO flow because the required session state does not exist, it should return a fixed error response or redirect only to a fixed internal page that is not influenced by request headers. `Referer` is not a trustworthy source of navigation intent and should not be treated as an authorization or routing signal for security-sensitive redirect logic.\n\nIf the product needs to preserve a return destination, that destination should be derived from a server-generated state value or validated against a strict allowlist. At minimum, the code should reject non-HTTP schemes, reject scheme-relative targets such as `//host`, and reject absolute URLs that are not same-origin with the current Shopware instance. A regression test should cover the exact cases proven here: no `Referer`, an external HTTPS `Referer`, and a `javascript:` `Referer`, with assertions that none of the attacker-controlled values can be emitted into `Location` or the HTML redirect body.\n\n## Impact\n\nThe demonstrated impact is that an unauthenticated attacker can cause a trusted Shopware endpoint to emit arbitrary redirect targets chosen through the request\u0027s `Referer` header. In the minimum case, that enables standard open redirect abuse for phishing, brand impersonation, and redirect chaining through a legitimate application origin. Because the redirect is served from `/api/oauth/sso/auth`, the resulting URL can look more trustworthy than a generic off-site redirect and may be more likely to be followed by users or client software that expects the endpoint to participate in an authentication flow.\n\nThe validated evidence also shows that the endpoint does not restrict the redirect target to ordinary web URLs. It reflects `javascript:alert(1)` directly into `Location` and into the HTML redirect page. This report keeps the claim conservative and classifies the issue as an open redirect with arbitrary redirect targets, but the acceptance of dangerous schemes makes the behavior more severe than a simple same-browser redirect to another HTTPS site and increases the risk of downstream abuse depending on client behavior.\n\n## Note on submission channel:\n\nI initially attempted to submit this issue through Shopware\u2019s official security reporting form. The form backend returned HTTP 400 for normal submissions, and when an attachment was included it explicitly rejected `.md`, `.py`, `.zip` files with the message `File type not allowed`. Because the official form was not functioning correctly for me, I am submitting this report privately through GitHub\u2019s vulnerability reporting flow.",
"id": "GHSA-4x3x-869w-xx3m",
"modified": "2026-06-04T19:32:36Z",
"published": "2026-06-04T19:32:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/security/advisories/GHSA-4x3x-869w-xx3m"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Shopware SSO referer trust leading to an arbitrary redirect target"
}
GHSA-4X4M-9CQH-W9QG
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13EyouCMS 1.5.4 is vulnerable to Open Redirect. An attacker can redirect a user to a malicious url via the Logout function.
{
"affected": [],
"aliases": [
"CVE-2021-39501"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-07T21:15:00Z",
"severity": "MODERATE"
},
"details": "EyouCMS 1.5.4 is vulnerable to Open Redirect. An attacker can redirect a user to a malicious url via the Logout function.",
"id": "GHSA-4x4m-9cqh-w9qg",
"modified": "2022-05-24T19:13:06Z",
"published": "2022-05-24T19:13:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39501"
},
{
"type": "WEB",
"url": "https://github.com/eyoucms/eyoucms/issues/17"
},
{
"type": "WEB",
"url": "https://github.com/KietNA-HPT/CVE"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-525R-JW95-MH3F
Vulnerability from github – Published: 2025-06-16 09:30 – Updated: 2026-02-23 12:31An open redirection vulnerability in M-Files mobile applications for Android and iOS prior to version 25.6.0 allows attackers to use maliciously crafted PDF files to trick other users into making requests to untrusted URLs.
{
"affected": [],
"aliases": [
"CVE-2025-2091"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-16T09:15:19Z",
"severity": "MODERATE"
},
"details": "An open redirection vulnerability in M-Files mobile applications for Android and iOS prior to version 25.6.0 allows attackers to use maliciously crafted PDF files to trick other users into making requests to untrusted URLs.",
"id": "GHSA-525r-jw95-mh3f",
"modified": "2026-02-23T12:31:29Z",
"published": "2025-06-16T09:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2091"
},
{
"type": "WEB",
"url": "https://empower.m-files.com/security-advisories/CVE-2025-2091"
},
{
"type": "WEB",
"url": "https://product.m-files.com/security-advisories/cve-2025-2091"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:L/VI:N/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:M/U:Green",
"type": "CVSS_V4"
}
]
}
GHSA-5266-Q47C-7Q7C
Vulnerability from github – Published: 2025-08-26 18:31 – Updated: 2025-08-26 18:31IBM Cognos Command Center 10.2.4.1 and 10.2.5
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-2025-2697"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-26T17:15:37Z",
"severity": "HIGH"
},
"details": "IBM Cognos Command Center 10.2.4.1 and 10.2.5 \n\ncould 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-5266-q47c-7q7c",
"modified": "2025-08-26T18:31:15Z",
"published": "2025-08-26T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2697"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7242159"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-528Q-XXM6-3X57
Vulnerability from github – Published: 2022-05-17 03:03 – Updated: 2022-05-17 03:03Open redirect vulnerability in comment.php in Serendipity through 2.0.5 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the HTTP Referer header.
{
"affected": [],
"aliases": [
"CVE-2017-5474"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-01-14T07:59:00Z",
"severity": "MODERATE"
},
"details": "Open redirect vulnerability in comment.php in Serendipity through 2.0.5 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the HTTP Referer header.",
"id": "GHSA-528q-xxm6-3x57",
"modified": "2022-05-17T03:03:00Z",
"published": "2022-05-17T03:03:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5474"
},
{
"type": "WEB",
"url": "https://github.com/s9y/Serendipity/commit/6285933470bab2923e4573b5d54ba9a32629b0cd"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95652"
}
],
"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-52M2-7HR5-3FP9
Vulnerability from github – Published: 2023-02-14 06:31 – Updated: 2023-02-21 21:30SAP NetWeaver AS for ABAP and ABAP Platform - versions 740, 750, 751, 752, 753, 754, 755, 756, 757, 789, 790, allows an unauthenticated attacker to craft a link, which when clicked by an unsuspecting user can be used to redirect a user to a malicious site which could read or modify some sensitive information or expose the victim to a phishing attack.
{
"affected": [],
"aliases": [
"CVE-2023-23860"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-14T04:15:00Z",
"severity": "MODERATE"
},
"details": "SAP NetWeaver AS for ABAP and ABAP Platform - versions 740, 750, 751, 752, 753, 754, 755, 756, 757, 789, 790, allows an unauthenticated attacker to craft a link, which when clicked by an unsuspecting user can be used to redirect a user to a malicious site which could read or modify some sensitive information or expose the victim to a phishing attack.",
"id": "GHSA-52m2-7hr5-3fp9",
"modified": "2023-02-21T21:30:18Z",
"published": "2023-02-14T06:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23860"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3268959"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.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"
}
]
}
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.