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.
2453 vulnerabilities reference this CWE, most recent first.
GHSA-2WRP-6FG6-HMC5
Vulnerability from github – Published: 2024-04-16 06:30 – Updated: 2025-02-13 19:00Applications that use UriComponentsBuilder to parse an externally provided URL (e.g. through a query parameter) AND perform validation checks on the host of the parsed URL may be vulnerable to a open redirect https://cwe.mitre.org/data/definitions/601.html attack or to a SSRF attack if the URL is used after passing validation checks.
This is the same as CVE-2024-22259 https://spring.io/security/cve-2024-22259 and CVE-2024-22243 https://spring.io/security/cve-2024-22243 , but with different input.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"fixed": "6.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-22262"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-16T16:15:13Z",
"nvd_published_at": "2024-04-16T06:15:46Z",
"severity": "HIGH"
},
"details": "Applications that use UriComponentsBuilder\u00a0to parse an externally provided URL (e.g. through a query parameter) AND\u00a0perform validation checks on the host of the parsed URL may be vulnerable to a open redirect https://cwe.mitre.org/data/definitions/601.html \u00a0attack or to a SSRF attack if the URL is used after passing validation checks.\n\nThis is the same as CVE-2024-22259 https://spring.io/security/cve-2024-22259 \u00a0and CVE-2024-22243 https://spring.io/security/cve-2024-22243 , but with different input.",
"id": "GHSA-2wrp-6fg6-hmc5",
"modified": "2025-02-13T19:00:56Z",
"published": "2024-04-16T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22262"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-framework"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/util/UriComponentsBuilder.java"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240524-0003"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2024-22262"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Spring Framework URL Parsing with Host Validation"
}
GHSA-2WVM-8MVP-22QV
Vulnerability from github – Published: 2026-08-28 16:28 – Updated: 2026-08-28 16:28Summary
The OIDC authorization page in the pocket-id frontend redirects the browser to an attacker-controlled URL without consulting the backend redirect_uri allow-list when the request uses prompt=none. An attacker who knows a valid client_id can craft an /authorize link that sends a victim (or a victim's browser doing a silent re-auth) to any external https URL, enabling phishing and OAuth response smuggling. The backend allow-list validation that protects the normal authenticated flow is bypassed because this path is handled entirely client-side.
Details
For an OIDC authorization request with prompt=none, the SvelteKit frontend short-circuits the flow before the backend ever validates the redirect_uri against the client's registered callback list.
File: frontend/src/routes/authorize/+page.ts (line 14) parses the raw redirect_uri query parameter from the incoming URL.
File: frontend/src/routes/authorize/+page.svelte - in onMount(), when the request carries prompt=none and the user cannot be silently authorized (for example the visitor is not logged in, so login_required must be returned), the page builds the callback URL from the raw redirect_uri and performs:
window.location.href = `${callbackURL}?error=login_required...`
The callbackURL is taken directly from the user-supplied redirect_uri. The only filtering applied is a scheme check that blocks javascript: and data: URLs; any http: or https: origin passes through. The backend allow-list validator GetCallbackURLFromList (which the authenticated code path uses to confirm the redirect_uri matches one of the client's registered callback URLs) is never invoked on this branch.
This means the per-client redirect_uri allow-list, the central control that makes redirect_uri safe in OAuth/OIDC, is not enforced for the prompt=none error-return path. A client_id is not a secret: client metadata is retrievable at /api/oidc/clients/:id/meta, and client_ids appear in any integration's authorization links.
Confirmation that the bypass is purely frontend: an unauthenticated POST to the backend /api/oidc/authorize endpoint correctly returns 401 ({"error":"You are not signed in"}), so the backend never authorizes the request. The redirect nonetheless happens in the browser because +page.svelte issues window.location.href before/without a successful backend authorization.
A second variant exists for an authenticated victim: when prompt=none is combined with a first-time (not yet consented) authorization of a client, the same client-side path can be reached.
Contrast: the standard interactive flow (no prompt=none) posts to the backend, which validates redirect_uri against the registered list before returning a callback. The defect is specific to the client-side prompt=none short-circuit.
PoC
Prerequisites: a running pocket-id instance, a registered OIDC client whose client_id is known to the attacker (obtainable from /api/oidc/clients/:id/meta or any existing integration), and a victim whose browser opens the link (the victim need not be logged in for the login_required branch).
- Attacker constructs an authorization URL pointing at the victim's pocket-id, supplying an external redirect_uri and prompt=none:
https://idp.victim.example/authorize?client_id=&redirect_uri=https://attacker.example/collect&response_type=code&scope=openid&prompt=none
- Victim opens the link. The frontend authorize page loads, determines the silent auth cannot succeed (login_required), and executes:
window.location.href = "https://attacker.example/collect?error=login_required&state=..."
- The browser is redirected to https://attacker.example/collect. Expected result on a fixed build: the page would refuse the redirect because redirect_uri does not match the client's registered callback list and would render an error in place instead of navigating off-origin.
Validation level: code-level confirmation at commit fc42f62. This is a browser-side window.location.href redirect, so it is not reproducible with curl; the backend was confirmed to reject the unauthenticated request (401) while the frontend performs the navigation regardless. Evidence notes saved to screenshots/001_open_redirect_evidence.txt.
Impact
Unauthenticated attacker, victim interaction required (clicking or being silently redirected). The trusted pocket-id domain is used to bounce a victim to an arbitrary external site, which is effective for credential phishing (the user trusts the IdP origin in the initial link) and for leaking OIDC error/state parameters to an attacker endpoint. Integrity impact is limited to redirection; no confidentiality or availability loss of pocket-id itself. Note: an abandoned PR (#1450) addressed a related protocol-relative URL issue in a different email-redirect path but was not merged and does not cover this authorize-page path.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.8.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/pocket-id/pocket-id/backend"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55834"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T16:28:20Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe OIDC authorization page in the pocket-id frontend redirects the browser to an attacker-controlled URL without consulting the backend redirect_uri allow-list when the request uses prompt=none. An attacker who knows a valid client_id can craft an /authorize link that sends a victim (or a victim\u0027s browser doing a silent re-auth) to any external https URL, enabling phishing and OAuth response smuggling. The backend allow-list validation that protects the normal authenticated flow is bypassed because this path is handled entirely client-side.\n\n### Details\nFor an OIDC authorization request with prompt=none, the SvelteKit frontend short-circuits the flow before the backend ever validates the redirect_uri against the client\u0027s registered callback list.\n\nFile: frontend/src/routes/authorize/+page.ts (line 14) parses the raw redirect_uri query parameter from the incoming URL.\n\nFile: frontend/src/routes/authorize/+page.svelte - in onMount(), when the request carries prompt=none and the user cannot be silently authorized (for example the visitor is not logged in, so login_required must be returned), the page builds the callback URL from the raw redirect_uri and performs:\n\n window.location.href = `${callbackURL}?error=login_required...`\n\nThe callbackURL is taken directly from the user-supplied redirect_uri. The only filtering applied is a scheme check that blocks javascript: and data: URLs; any http: or https: origin passes through. The backend allow-list validator GetCallbackURLFromList (which the authenticated code path uses to confirm the redirect_uri matches one of the client\u0027s registered callback URLs) is never invoked on this branch.\n\nThis means the per-client redirect_uri allow-list, the central control that makes redirect_uri safe in OAuth/OIDC, is not enforced for the prompt=none error-return path. A client_id is not a secret: client metadata is retrievable at /api/oidc/clients/:id/meta, and client_ids appear in any integration\u0027s authorization links.\n\nConfirmation that the bypass is purely frontend: an unauthenticated POST to the backend /api/oidc/authorize endpoint correctly returns 401 ({\"error\":\"You are not signed in\"}), so the backend never authorizes the request. The redirect nonetheless happens in the browser because +page.svelte issues window.location.href before/without a successful backend authorization.\n\nA second variant exists for an authenticated victim: when prompt=none is combined with a first-time (not yet consented) authorization of a client, the same client-side path can be reached.\n\nContrast: the standard interactive flow (no prompt=none) posts to the backend, which validates redirect_uri against the registered list before returning a callback. The defect is specific to the client-side prompt=none short-circuit.\n\n### PoC\nPrerequisites: a running pocket-id instance, a registered OIDC client whose client_id is known to the attacker (obtainable from /api/oidc/clients/:id/meta or any existing integration), and a victim whose browser opens the link (the victim need not be logged in for the login_required branch).\n\n1. Attacker constructs an authorization URL pointing at the victim\u0027s pocket-id, supplying an external redirect_uri and prompt=none:\n\n https://idp.victim.example/authorize?client_id=\u003cknown_client_id\u003e\u0026redirect_uri=https://attacker.example/collect\u0026response_type=code\u0026scope=openid\u0026prompt=none\n\n2. Victim opens the link. The frontend authorize page loads, determines the silent auth cannot succeed (login_required), and executes:\n\n window.location.href = \"https://attacker.example/collect?error=login_required\u0026state=...\"\n\n3. The browser is redirected to https://attacker.example/collect. Expected result on a fixed build: the page would refuse the redirect because redirect_uri does not match the client\u0027s registered callback list and would render an error in place instead of navigating off-origin.\n\nValidation level: code-level confirmation at commit fc42f62. This is a browser-side window.location.href redirect, so it is not reproducible with curl; the backend was confirmed to reject the unauthenticated request (401) while the frontend performs the navigation regardless. Evidence notes saved to screenshots/001_open_redirect_evidence.txt.\n\n### Impact\nUnauthenticated attacker, victim interaction required (clicking or being silently redirected). The trusted pocket-id domain is used to bounce a victim to an arbitrary external site, which is effective for credential phishing (the user trusts the IdP origin in the initial link) and for leaking OIDC error/state parameters to an attacker endpoint. Integrity impact is limited to redirection; no confidentiality or availability loss of pocket-id itself. Note: an abandoned PR (#1450) addressed a related protocol-relative URL issue in a different email-redirect path but was not merged and does not cover this authorize-page path.",
"id": "GHSA-2wvm-8mvp-22qv",
"modified": "2026-08-28T16:28:20Z",
"published": "2026-08-28T16:28:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-2wvm-8mvp-22qv"
},
{
"type": "WEB",
"url": "https://github.com/pocket-id/pocket-id/commit/8a7577497131229badb35cb4b3a4227b1300afff"
},
{
"type": "PACKAGE",
"url": "https://github.com/pocket-id/pocket-id"
},
{
"type": "WEB",
"url": "https://github.com/pocket-id/pocket-id/releases/tag/v2.9.0"
}
],
"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": "Pocket-ID has an Open Redirect on the OIDC /authorize page via unvalidated redirect_uri with prompt=none"
}
GHSA-2XCR-P767-F3RV
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-07-15 00:32Severity: medium (5.8) / important
Server-Side Request Forgery (SSRF), Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Apache Druid.
This issue affects all previous Druid versions.
When using the Druid management proxy, a request that has a specially crafted URL could be used to redirect the request to an arbitrary server instead. This has the potential for XSS or XSRF. The user is required to be authenticated for this exploit. The management proxy is enabled in Druid's out-of-box configuration. It may be disabled to mitigate this vulnerability. If the management proxy is disabled, some web console features will not work properly, but core functionality is unaffected.
Users are recommended to upgrade to Druid 31.0.2 or Druid 32.0.1, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.druid:druid"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "31.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.druid:druid"
},
"ranges": [
{
"events": [
{
"introduced": "32.0.0"
},
{
"fixed": "32.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"32.0.0"
]
}
],
"aliases": [
"CVE-2025-27888"
],
"database_specific": {
"cwe_ids": [
"CWE-601",
"CWE-79",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T22:46:39Z",
"nvd_published_at": "2025-03-20T12:15:14Z",
"severity": "MODERATE"
},
"details": "Severity: medium (5.8) / important\n\nServer-Side Request Forgery (SSRF), Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027),\u00a0URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in Apache Druid.\n\nThis issue affects all previous Druid versions.\n\nWhen using the Druid management proxy, a request that has a specially crafted URL could be used to redirect the request to an arbitrary server instead. This has the potential for XSS or XSRF. The user is required to be authenticated for this exploit. The management proxy is enabled in Druid\u0027s out-of-box configuration. It may be disabled to mitigate this vulnerability. If the management proxy is disabled, some web console features will not work properly, but core functionality is unaffected.\n\nUsers are recommended to upgrade to Druid 31.0.2 or Druid 32.0.1, which fixes the issue.",
"id": "GHSA-2xcr-p767-f3rv",
"modified": "2025-07-15T00:32:25Z",
"published": "2025-03-20T12:32:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27888"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/druid"
},
{
"type": "WEB",
"url": "https://github.com/apache/druid/releases/tag/druid-31.0.2"
},
{
"type": "WEB",
"url": "https://github.com/apache/druid/releases/tag/druid-32.0.1"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/c0qo989pwtrqkjv6xfr0c30dnjq8vf39"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/03/19/7"
}
],
"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:P/PR:L/UI:A/VC:H/VI:L/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache Druid vulnerable to Server-Side Request Forgery, Cross-site Scripting, Open Redirect"
}
GHSA-2XJC-5RQ3-QQGW
Vulnerability from github – Published: 2023-05-08 15:30 – Updated: 2024-04-04 03:50Open redirect vulnerability in typecho 1.1-17.10.30-release via the referer parameter to Login.php.
{
"affected": [],
"aliases": [
"CVE-2020-21038"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-08T14:15:10Z",
"severity": "MODERATE"
},
"details": "Open redirect vulnerability in typecho 1.1-17.10.30-release via the referer parameter to Login.php.",
"id": "GHSA-2xjc-5rq3-qqgw",
"modified": "2024-04-04T03:50:25Z",
"published": "2023-05-08T15:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21038"
},
{
"type": "WEB",
"url": "https://github.com/typecho/typecho/issues/952"
},
{
"type": "WEB",
"url": "https://github.com/typecho/typecho"
}
],
"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-2XM9-JVFF-C46X
Vulnerability from github – Published: 2022-05-01 23:41 – Updated: 2022-05-01 23:41Open redirect vulnerability in exchweb/bin/redir.asp in Microsoft Outlook Web Access (OWA) for Exchange Server 2003 SP2 (aka build 6.5.7638) allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the URL parameter.
{
"affected": [],
"aliases": [
"CVE-2008-1547"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-10-21T01:18:00Z",
"severity": "MODERATE"
},
"details": "Open redirect vulnerability in exchweb/bin/redir.asp in Microsoft Outlook Web Access (OWA) for Exchange Server 2003 SP2 (aka build 6.5.7638) allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the URL parameter.",
"id": "GHSA-2xm9-jvff-c46x",
"modified": "2022-05-01T23:41:13Z",
"published": "2022-05-01T23:41:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1547"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/46061"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/4441"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/497374/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/497390/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/497433/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/497500/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/497534/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/31765"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-323M-J8JX-G8PQ
Vulnerability from github – Published: 2023-06-29 03:30 – Updated: 2024-04-04 05:16Ericsson Network Manager (ENM), versions prior to 22.2, contains a vulnerability in the REST endpoint “editprofile” where Open Redirect HTTP Header Injection can lead to redirection of the submitted request to domain out of control of ENM deployment. The attacker would need admin/elevated access to exploit the vulnerability
{
"affected": [],
"aliases": [
"CVE-2022-46407"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-29T02:15:15Z",
"severity": "MODERATE"
},
"details": "Ericsson Network Manager (ENM), versions prior to 22.2, contains a vulnerability in the REST endpoint \u201ceditprofile\u201d where Open Redirect HTTP Header Injection can lead to redirection of the submitted request to domain out of control of ENM deployment. The attacker would need admin/elevated access to exploit the vulnerability",
"id": "GHSA-323m-j8jx-g8pq",
"modified": "2024-04-04T05:16:53Z",
"published": "2023-06-29T03:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46407"
},
{
"type": "WEB",
"url": "https://www.gruppotim.it/it/footer/red-team.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-32FX-V9HC-86M5
Vulnerability from github – Published: 2023-12-29 12:30 – Updated: 2026-04-28 21:33URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Pexle Chris Library Viewer.This issue affects Library Viewer: from n/a through 2.0.6.
{
"affected": [],
"aliases": [
"CVE-2023-32101"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-29T10:15:10Z",
"severity": "MODERATE"
},
"details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in Pexle Chris Library Viewer.This issue affects Library Viewer: from n/a through 2.0.6.",
"id": "GHSA-32fx-v9hc-86m5",
"modified": "2026-04-28T21:33:38Z",
"published": "2023-12-29T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32101"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/library-viewer/wordpress-library-viewer-plugin-2-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-32X6-QVW6-MXJ4
Vulnerability from github – Published: 2022-03-01 22:14 – Updated: 2026-07-20 21:32Impact
Using followRedirects or followRedirectsWith with any of the redirection strategies built into fluture-node 4.0.0 or 4.0.1, paired with a request that includes confidential headers such as Authorization or Cookie, exposes you to a vulnerability where, if the destination server were to redirect the request to a server on a third-party domain, or the same domain over unencrypted HTTP, the headers would be included in the follow-up request and be exposed to the third party, or potential http traffic sniffing.
Patches
The redirection strategies made available in version 4.0.2 automatically redact confidential headers when a redirect is followed across to another origin.
Workarounds
Use a custom redirection strategy via the followRedirectsWith function. The custom strategy can be based on the new strategies available in fluture-node@4.0.2.
References
- This vulnerability was discovered after the announcement of similar vulnerabilities in the
follow-redirectspackage. There is more information there: https://github.com/advisories/GHSA-74fj-2j2h-c42q and https://huntr.dev/bounties/7cf2bf90-52da-4d59-8028-a73b132de0db/ - Fixed in 125e4474f910c1507f8ec3232848626fbc0f55c4 and 0c99bc511533d48be17dc6bfe641f7d0aeb34d77
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fluture-node"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-24719"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-212",
"CWE-359",
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2022-03-01T22:14:57Z",
"nvd_published_at": "2022-03-01T21:15:00Z",
"severity": "LOW"
},
"details": "### Impact\n\nUsing `followRedirects` or `followRedirectsWith` with any of the redirection strategies built into fluture-node 4.0.0 or 4.0.1, paired with a request that includes confidential headers such as Authorization or Cookie, exposes you to a vulnerability where, if the destination server were to redirect the request to a server on a third-party domain, or the same domain over unencrypted HTTP, the headers would be included in the follow-up request and be exposed to the third party, or potential http traffic sniffing.\n\n### Patches\n\nThe redirection strategies made available in version 4.0.2 automatically redact confidential headers when a redirect is followed across to another origin.\n\n### Workarounds\n\nUse a custom redirection strategy via the `followRedirectsWith` function. The custom strategy can be based on the new strategies available in fluture-node@4.0.2.\n\n### References\n\n- This vulnerability was discovered after the announcement of similar vulnerabilities in the `follow-redirects` package. There is more information there: https://github.com/advisories/GHSA-74fj-2j2h-c42q and https://huntr.dev/bounties/7cf2bf90-52da-4d59-8028-a73b132de0db/\n- Fixed in 125e4474f910c1507f8ec3232848626fbc0f55c4 and 0c99bc511533d48be17dc6bfe641f7d0aeb34d77",
"id": "GHSA-32x6-qvw6-mxj4",
"modified": "2026-07-20T21:32:20Z",
"published": "2022-03-01T22:14:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fluture-js/fluture-node/security/advisories/GHSA-32x6-qvw6-mxj4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24719"
},
{
"type": "WEB",
"url": "https://github.com/psf/requests/pull/4718"
},
{
"type": "WEB",
"url": "https://github.com/fluture-js/fluture-node/commit/0c99bc511533d48be17dc6bfe641f7d0aeb34d77"
},
{
"type": "WEB",
"url": "https://github.com/fluture-js/fluture-node/commit/125e4474f910c1507f8ec3232848626fbc0f55c4"
},
{
"type": "PACKAGE",
"url": "https://github.com/fluture-js/fluture-node"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pyquest/PYSEC-2022-43051.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/request-util/PYSEC-2022-43052.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Forwarding of confidentials headers to third parties in fluture-node"
}
GHSA-338X-J9C9-2C8V
Vulnerability from github – Published: 2025-12-17 21:30 – Updated: 2025-12-18 21:31This issue was addressed with improved URL validation. This issue is fixed in macOS Tahoe 26.2, Safari 26.2. On a Mac with Lockdown Mode enabled, web content opened via a file URL may be able to use Web APIs that should be restricted.
{
"affected": [],
"aliases": [
"CVE-2025-43526"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-17T21:16:11Z",
"severity": "CRITICAL"
},
"details": "This issue was addressed with improved URL validation. This issue is fixed in macOS Tahoe 26.2, Safari 26.2. On a Mac with Lockdown Mode enabled, web content opened via a file URL may be able to use Web APIs that should be restricted.",
"id": "GHSA-338x-j9c9-2c8v",
"modified": "2025-12-18T21:31:36Z",
"published": "2025-12-17T21:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43526"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125886"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125892"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-33C5-9FX5-FVJM
Vulnerability from github – Published: 2024-04-24 20:01 – Updated: 2024-05-20 22:08The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.7 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/apimachinery"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/apimachinery"
},
"ranges": [
{
"events": [
{
"introduced": "0.17.0"
},
{
"fixed": "0.17.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/apimachinery"
},
"ranges": [
{
"events": [
{
"introduced": "0.18.0"
},
{
"fixed": "0.18.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.16.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.17.0"
},
{
"fixed": "1.17.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.18.0"
},
{
"fixed": "1.18.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-8559"
],
"database_specific": {
"cwe_ids": [
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-24T20:01:22Z",
"nvd_published_at": "2020-07-22T14:15:00Z",
"severity": "MODERATE"
},
"details": "The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.7 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.",
"id": "GHSA-33c5-9fx5-fvjm",
"modified": "2024-05-20T22:08:21Z",
"published": "2024-04-24T20:01:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8559"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/92914"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/pull/92941"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1851422"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubernetes/kubernetes"
},
{
"type": "WEB",
"url": "https://github.com/tdwyer/CVE-2020-8559"
},
{
"type": "WEB",
"url": "https://groups.google.com/d/msg/kubernetes-security-announce/JAIGG5yNROs/19nHQ5wkBwAJ"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/kubernetes-security-announce/c/JAIGG5yNROs"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200810-0004"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Privilege Escalation in Kubernetes"
}
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.