Common Weakness Enumeration

CWE-601

Allowed

URL Redirection to Untrusted Site ('Open Redirect')

Abstraction: Base · Status: Draft

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

2305 vulnerabilities reference this CWE, most recent first.

GHSA-W4R7-VM83-Q2C7

Vulnerability from github – Published: 2023-03-06 00:30 – Updated: 2025-03-08 01:12
VLAI
Summary
Open redirect in web2py
Details

Open redirect vulnerability exists in web2py versions prior to 2.23.1. When using the tool, a web2py user may be redirected to an arbitrary website by accessing a specially crafted URL. As a result, the user may become a victim of a phishing attack.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "web2py"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.23.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-22432"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-13T20:41:00Z",
    "nvd_published_at": "2023-03-06T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Open redirect vulnerability exists in web2py versions prior to 2.23.1. When using the tool, a web2py user may be redirected to an arbitrary website by accessing a specially crafted URL. As a result, the user may become a victim of a phishing attack.",
  "id": "GHSA-w4r7-vm83-q2c7",
  "modified": "2025-03-08T01:12:57Z",
  "published": "2023-03-06T00:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22432"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN78253670"
    },
    {
      "type": "WEB",
      "url": "http://web2py.com"
    },
    {
      "type": "WEB",
      "url": "http://web2py.com/init/default/download"
    }
  ],
  "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": "Open redirect in web2py"
}

GHSA-W673-8FJW-457C

Vulnerability from github – Published: 2026-03-27 18:06 – Updated: 2026-03-27 18:06
VLAI
Summary
n8n: Authenticated XSS and Open Redirect via Form Node
Details

Impact

An authenticated user with permission to create or modify workflows could configure a Form Node with an unsanitized HTML description field or exploit an overly permissive iframe sandbox policy to perform stored cross-site scripting or redirect end users visiting the form to an arbitrary external URL. The vulnerability could be used to facilitate phishing attacks.

Patches

The issue has been fixed in n8n versions 1.123.24, 2.10.4 and 2.12.0. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow creation and editing permissions to fully trusted users only. - Disable the Form node by adding n8n-nodes-base.form to the NODES_EXCLUDE environment variable. - Disable the Form Trigger node by adding n8n-nodes-base.formTrigger to the NODES_EXCLUDE environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.11.0"
            },
            {
              "fixed": "2.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-rc.0"
            },
            {
              "fixed": "2.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.123.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-601",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T18:06:28Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\nAn authenticated user with permission to create or modify workflows could configure a Form Node with an unsanitized HTML description field or exploit an overly permissive iframe sandbox policy to perform stored cross-site scripting or redirect end users visiting the form to an arbitrary external URL. The vulnerability could be used to facilitate phishing attacks.\n\n## Patches\nThe issue has been fixed in n8n versions 1.123.24, 2.10.4 and 2.12.0. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Limit workflow creation and editing permissions to fully trusted users only.\n- Disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable.\n- Disable the Form Trigger node by adding `n8n-nodes-base.formTrigger` to the `NODES_EXCLUDE` environment variable.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-w673-8fjw-457c",
  "modified": "2026-03-27T18:06:28Z",
  "published": "2026-03-27T18:06:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-w673-8fjw-457c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Authenticated XSS and Open Redirect via Form Node"
}

GHSA-W745-XJQX-7WP8

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2023-07-06 21:49
VLAI
Summary
Artesãos SEOTools Open Redirect vulnerability
Details

A vulnerability has been found in Artesãos SEOTools up to and including version 0.17.1. This vulnerability affects the function setTitle of the file SEOMeta.php. The manipulation of the argument title leads to open redirect. Upgrading to version 0.17.2 is able to address this issue. The name of the patch is ca27cd0edf917e0bc805227013859b8b5a1f01fb. It is recommended to upgrade the affected component.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "artesaos/seotools"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-06T21:49:11Z",
    "nvd_published_at": "2023-03-04T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in Artes\u00e3os SEOTools up to and including version 0.17.1. This vulnerability affects the function setTitle of the file SEOMeta.php. The manipulation of the argument title leads to open redirect. Upgrading to version 0.17.2 is able to address this issue. The name of the patch is ca27cd0edf917e0bc805227013859b8b5a1f01fb. It is recommended to upgrade the affected component.",
  "id": "GHSA-w745-xjqx-7wp8",
  "modified": "2023-07-06T21:49:11Z",
  "published": "2023-07-06T19:24:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36664"
    },
    {
      "type": "WEB",
      "url": "https://github.com/artesaos/seotools/pull/201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/artesaos/seotools/commit/ca27cd0edf917e0bc805227013859b8b5a1f01fb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/artesaos/seotools"
    },
    {
      "type": "WEB",
      "url": "https://github.com/artesaos/seotools/releases/tag/v0.17.2"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.222232"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.222232"
    }
  ],
  "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": "Artes\u00e3os SEOTools Open Redirect vulnerability"
}

GHSA-W7HW-FM35-MF9M

Vulnerability from github – Published: 2024-06-14 15:31 – Updated: 2024-06-14 15:31
VLAI
Details

An open redirect issue was discovered in Kibana that could lead to a user being redirected to an arbitrary website if they use a maliciously crafted Kibana URL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-23442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-14T15:15:49Z",
    "severity": "MODERATE"
  },
  "details": "An open redirect issue was discovered in Kibana that could lead to a user being redirected to an arbitrary website if they use a maliciously crafted Kibana URL.",
  "id": "GHSA-w7hw-fm35-mf9m",
  "modified": "2024-06-14T15:31:25Z",
  "published": "2024-06-14T15:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23442"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-8-14-0-7-17-22-security-update/361502"
    }
  ],
  "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-W832-GG5G-X44M

Vulnerability from github – Published: 2025-11-06 15:13 – Updated: 2026-05-19 20:23
VLAI
Summary
Open redirect endpoint in Datasette
Details

Impact

Deployed instances of Datasette prior to 0.65.2 and 1.0a21 include an open redirect vulnerability.

Hits to the path //example.com/foo/bar/ (the trailing slash is required) will redirect the user to https://example.com/foo/bar.

Patches

This problem has been patched in both Datasette 0.65.2 and 1.0a21.

Workarounds

If Datasette is running behind a proxy that proxy could be configured to replace // with / in incoming request URLs.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "datasette"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.65.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 1.0a20"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "datasette"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0a0"
            },
            {
              "fixed": "1.0a21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64481"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-06T15:13:33Z",
    "nvd_published_at": "2025-11-07T21:15:42Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nDeployed instances of Datasette prior to `0.65.2` and `1.0a21` include an open redirect vulnerability.\n\nHits to the path `//example.com/foo/bar/` (the trailing slash is required) will redirect the user to `https://example.com/foo/bar`.\n\n### Patches\n\nThis problem has been patched in both Datasette `0.65.2` and `1.0a21`.\n\n### Workarounds\n\nIf Datasette is running behind a proxy that proxy could be configured to replace `//` with `/` in incoming request URLs.",
  "id": "GHSA-w832-gg5g-x44m",
  "modified": "2026-05-19T20:23:11Z",
  "published": "2025-11-06T15:13:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/simonw/datasette/security/advisories/GHSA-w832-gg5g-x44m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64481"
    },
    {
      "type": "WEB",
      "url": "https://github.com/simonw/datasette/issues/2429"
    },
    {
      "type": "WEB",
      "url": "https://github.com/simonw/datasette/commit/f257ca6edb64848c3b04b54d41e347c54fe57c05"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/datasette/PYSEC-2025-73.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/simonw/datasette"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Open redirect endpoint in Datasette"
}

GHSA-W8CR-MF7C-GX8M

Vulnerability from github – Published: 2023-11-02 00:30 – Updated: 2023-11-02 00:30
VLAI
Details

Online Examination System v1.0 is vulnerable to multiple Open Redirect vulnerabilities. The 'q' parameter of the feed.php resource allows an attacker to redirect a victim user to an arbitrary web site using a crafted URL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-45202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-01T23:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Online Examination System v1.0 is vulnerable to multiple Open Redirect vulnerabilities. The \u0027q\u0027 parameter of the feed.php resource allows an attacker to redirect a victim user to an arbitrary web site using a crafted URL.\n\n",
  "id": "GHSA-w8cr-mf7c-gx8m",
  "modified": "2023-11-02T00:30:32Z",
  "published": "2023-11-02T00:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45202"
    },
    {
      "type": "WEB",
      "url": "https://fluidattacks.com/advisories/uchida"
    },
    {
      "type": "WEB",
      "url": "https://projectworlds.in"
    }
  ],
  "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-W8GF-92GC-CX36

Vulnerability from github – Published: 2026-01-13 03:32 – Updated: 2026-01-13 03:32
VLAI
Details

Due to an Open Redirect Vulnerability in SAP Supplier Relationship Management (SICF Handler in SRM Catalog), an unauthenticated attacker could craft a malicious URL that, if accessed by a victim, redirects them to an attacker-controlled site.This causes low impact on integrity of the application. Confidentiality and availability are not impacted.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-0513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T02:15:53Z",
    "severity": "MODERATE"
  },
  "details": "Due to an Open Redirect Vulnerability in SAP Supplier Relationship Management (SICF Handler in SRM Catalog), an unauthenticated attacker could craft a malicious URL that, if accessed by a victim, redirects them to an attacker-controlled site.This causes low impact on integrity of the application. Confidentiality and availability are not impacted.",
  "id": "GHSA-w8gf-92gc-cx36",
  "modified": "2026-01-13T03:32:09Z",
  "published": "2026-01-13T03:32:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0513"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3638716"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W8GR-XWP4-R9F7

Vulnerability from github – Published: 2024-10-14 20:55 – Updated: 2024-12-20 17:55
VLAI
Summary
Keycloak has Vulnerable Redirect URI Validation Results in Open Redirect
Details

A misconfiguration flaw was found in Keycloak. This issue can allow an attacker to redirect users to an arbitrary URL if a 'Valid Redirect URI' is set to http://localhost/ or http://127.0.0.1/, enabling sensitive information such as authorization codes to be exposed to the attacker, potentially leading to session hijacking.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 22.0.12"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "22.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 24.0.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "24.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 25.0.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-8883"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-14T20:55:22Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A misconfiguration flaw was found in Keycloak. This issue can allow an attacker to redirect users to an arbitrary URL if a \u0027Valid Redirect URI\u0027 is set to http://localhost/ or http://127.0.0.1/, enabling sensitive information such as authorization codes to be exposed to the attacker, potentially leading to session hijacking.",
  "id": "GHSA-w8gr-xwp4-r9f7",
  "modified": "2024-12-20T17:55:01Z",
  "published": "2024-10-14T20:55:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-w8gr-xwp4-r9f7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8883"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/releases/tag/25.0.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/protocol/oidc/utils/RedirectUtils.java"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2312511"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-8883"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:8826"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:8824"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:8823"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6890"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6889"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6888"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6887"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6886"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6882"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6880"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6879"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6878"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10386"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:10385"
    }
  ],
  "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": "Keycloak has Vulnerable Redirect URI Validation Results in Open Redirect"
}

GHSA-W8JF-75VM-VJ9W

Vulnerability from github – Published: 2023-05-09 18:30 – Updated: 2024-04-04 03:56
VLAI
Details

There is an unvalidated redirect vulnerability in Esri Portal for ArcGIS 11.0 and 10.9.1 that may allow a remote, unauthenticated attacker to craft a URL that could redirect a victim to an arbitrary website, simplifying phishing attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-25829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-09T17:15:10Z",
    "severity": "MODERATE"
  },
  "details": "There is an unvalidated redirect vulnerability in Esri Portal for ArcGIS 11.0 and 10.9.1 that may allow a remote, unauthenticated attacker to craft a URL that could redirect a victim to an arbitrary website, simplifying phishing attacks.",
  "id": "GHSA-w8jf-75vm-vj9w",
  "modified": "2024-04-04T03:56:08Z",
  "published": "2023-05-09T18:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25829"
    },
    {
      "type": "WEB",
      "url": "https://support.esri.com/en-us/patches-updates/2023/portal-for-arcgis-security-2023-update-1-patch-8095"
    },
    {
      "type": "WEB",
      "url": "https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/portal-for-arcgis-security-2023-update-1-patch-is-now-available"
    }
  ],
  "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-W8P2-R796-3VMQ

Vulnerability from github – Published: 2026-06-08 17:52 – Updated: 2026-06-08 17:52
VLAI
Summary
Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type
Details

Summary

Authlib's OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported response_type and supplies an attacker-controlled redirect_uri.

The vulnerable behavior happens before client lookup and before any redirect URI validation. As a result, an attacker does not need a valid client registration, an authenticated user, or any prior state. A single request to the authorization endpoint is enough to obtain a 302 Location response to an arbitrary attacker-controlled URL.

It was confirmed that the vulnerable code is present in tag v1.6.6 and in the current HEAD under test (68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1, git describe: v1.6.6-104-g68e6ab3f). The issue was dynamically reproduced locally on the current HEAD.

Details

The root cause is that AuthorizationServer.get_authorization_grant() copies the raw request redirect_uri into an UnsupportedResponseTypeError before any client has been resolved and before any redirect URI validation has happened:

```python # authlib/oauth2/rfc6749/authorization_server.py raise UnsupportedResponseTypeError( f"The response type '{request.payload.response_type}' is not supported by the server.", request.payload.response_type, redirect_uri=request.payload.redirect_uri, )

That error object is later rendered by OAuth2Error.call(). If redirect_uri is set, Authlib automatically returns a redirect response to that URI:

# authlib/oauth2/base.py def call(self, uri=None): if self.redirect_uri: params = self.get_body() loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment) return 302, "", [("Location", loc)] return super().call(uri=uri)

This means an unsupported response_type request can force the authorization server to redirect to an attacker-controlled URL even when:

  1. no valid client exists,
  2. no grant matched the request,
  3. no registered redirect_uri was ever checked.

This is not a contrived code path. It is reachable through the normal Authlib authorization endpoint flow documented for Flask and Django integrations, where applications are told to call server.get_consent_grant(...) and then server.handle_error_response(...) on OAuth2Error.

Relevant source and documentation references:

  • authlib/oauth2/rfc6749/authorization_server.py
  • authlib/oauth2/base.py
  • docs/flask/2/authorization-server.rst
  • docs/django/2/authorization-server.rst

### PoC

Local test environment:

  • Repository checkout: 68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1
  • git describe: v1.6.6-104-g68e6ab3f
  • Python virtualenv: ./.venv
  • Environment variable: AUTHLIB_INSECURE_TRANSPORT=true

Note: AUTHLIB_INSECURE_TRANSPORT=true was only used to allow local loopback HTTP reproduction. It does not create the vulnerable behavior. In a real deployment the same logic is reachable over HTTPS.

Run this exact PoC from the repository root:

export AUTHLIB_INSECURE_TRANSPORT=true ./.venv/bin/python - <<'PY' import os, json from flask import Flask, request from authlib.integrations.flask_oauth2 import AuthorizationServer from authlib.oauth2 import OAuth2Error from authlib.oauth2.rfc6749.grants import AuthorizationCodeGrant as _AuthorizationCodeGrant

os.environ["AUTHLIB_INSECURE_TRANSPORT"] = "true"

class AuthorizationCodeGrant(_AuthorizationCodeGrant): def save_authorization_code(self, code, request): raise RuntimeError("not reached") def query_authorization_code(self, code, client): return None def delete_authorization_code(self, authorization_code): pass def authenticate_user(self, authorization_code): return None

app = Flask(name) app.secret_key = "testing"

server = AuthorizationServer( app, query_client=lambda client_id: None, save_token=lambda token, request: None, ) server.register_grant(AuthorizationCodeGrant)

@app.route("/oauth/authorize", methods=["GET", "POST"]) def authorize(): try: grant = server.get_consent_grant(end_user=None) except OAuth2Error as error: return server.handle_error_response(request, error) return server.create_authorization_response(grant=grant, grant_user=None)

with app.test_client() as c: cases = { "without_redirect_uri": "/oauth/authorize?response_type=totally-unsupported&state=s1", "with_attacker_redirect_uri": "/oauth/authorize?response_type=totally- unsupported&redirect_uri=https%3A%2F%2Fevil.example%2Flanding&state=s1", } out = {} for name, url in cases.items(): r = c.get(url) out[name] = { "status": r.status_code, "location": r.headers.get("Location"), "body": r.get_data(as_text=True), } print(json.dumps(out, indent=2)) PY

Observed result:

{ "without_redirect_uri": { "status": 400, "location": null, "body": "{\"error\": \"unsupported_response_type\", \"error_description\": \"totally- unsupported\", \"state\": \"s1\"}" }, "with_attacker_redirect_uri": { "status": 302, "location": "https://evil.example/landing?error=unsupported_response_type&error_description=totally-unsupported&state=s1",
"body": "" } }

This demonstrates that the only difference between a local error and an external redirect is whether the attacker supplies redirect_uri.

The same behavior was locally reproduced with the Django integration using RequestFactory; it returned:

{ "status": 302, "location": "https://evil.example/landing?error=unsupported_response_type&error_description=totally-unsupported&state=s1",
"body": "" }

Impact

This is an unauthenticated open redirect in an internet-facing authorization endpoint.

Who is impacted:

  • Any deployment using Authlib's OAuth 2.0 authorization server and the documented authorization endpoint flow.
  • No special feature flag is required beyond running the authorization endpoint itself.

Attacker prerequisites:

  • None beyond the ability to send a victim to a crafted authorization URL.

Practical harm:

  • Phishing and credential theft by abusing a trusted authorization server domain as a redirector.
  • Bypass of domain-based allowlists that trust the authorization server's host.
  • SSO / OAuth confusion in ecosystems where trusted authorization endpoints are expected to reject unregistered redirect URIs before redirecting.

The issue is especially concerning because the redirect happens before client existence and redirect URI legitimacy are established.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.7.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T17:52:04Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nAuthlib\u0027s OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported response_type and supplies an attacker-controlled redirect_uri.\n\nThe vulnerable behavior happens before client lookup and before any redirect URI validation. As a result, an attacker does not need a valid client registration, an authenticated user, or any prior state. A single request to the authorization endpoint is enough to obtain a 302 Location response to an arbitrary attacker-controlled URL.\n\nIt was confirmed that the vulnerable code is present in tag v1.6.6 and in the current HEAD under test (68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1, git describe: v1.6.6-104-g68e6ab3f). The issue was dynamically reproduced locally on the current HEAD.\n\n### Details\nThe root cause is that `AuthorizationServer.get_authorization_grant()` copies the raw request\n  `redirect_uri` into an `UnsupportedResponseTypeError` before any client has been resolved and\n  before any redirect URI validation has happened:\n\n  ```python\n  # authlib/oauth2/rfc6749/authorization_server.py\n  raise UnsupportedResponseTypeError(\n      f\"The response type \u0027{request.payload.response_type}\u0027 is not supported by the server.\",\n      request.payload.response_type,\n      redirect_uri=request.payload.redirect_uri,\n  )\n\n  That error object is later rendered by OAuth2Error.__call__(). If redirect_uri is set, Authlib\n  automatically returns a redirect response to that URI:\n\n  # authlib/oauth2/base.py\n  def __call__(self, uri=None):\n      if self.redirect_uri:\n          params = self.get_body()\n          loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment)\n          return 302, \"\", [(\"Location\", loc)]\n      return super().__call__(uri=uri)\n\n  This means an unsupported response_type request can force the authorization server to redirect\n  to an attacker-controlled URL even when:\n\n  1. no valid client exists,\n  2. no grant matched the request,\n  3. no registered redirect_uri was ever checked.\n\n  This is not a contrived code path. It is reachable through the normal Authlib authorization\n  endpoint flow documented for Flask and Django integrations, where applications are told to call\n  server.get_consent_grant(...) and then server.handle_error_response(...) on OAuth2Error.\n\n  Relevant source and documentation references:\n\n  - authlib/oauth2/rfc6749/authorization_server.py\n  - authlib/oauth2/base.py\n  - docs/flask/2/authorization-server.rst\n  - docs/django/2/authorization-server.rst\n\n  ### PoC\n\n  Local test environment:\n\n  - Repository checkout: 68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1\n  - git describe: v1.6.6-104-g68e6ab3f\n  - Python virtualenv: ./.venv\n  - Environment variable: AUTHLIB_INSECURE_TRANSPORT=true\n\n  Note: AUTHLIB_INSECURE_TRANSPORT=true was only used to allow local loopback HTTP reproduction.\n  It does not create the vulnerable behavior. In a real deployment the same logic is reachable\n  over HTTPS.\n\n  Run this exact PoC from the repository root:\n\n  export AUTHLIB_INSECURE_TRANSPORT=true\n  ./.venv/bin/python - \u003c\u003c\u0027PY\u0027\n  import os, json\n  from flask import Flask, request\n  from authlib.integrations.flask_oauth2 import AuthorizationServer\n  from authlib.oauth2 import OAuth2Error\n  from authlib.oauth2.rfc6749.grants import AuthorizationCodeGrant as _AuthorizationCodeGrant\n\n  os.environ[\"AUTHLIB_INSECURE_TRANSPORT\"] = \"true\"\n\n  class AuthorizationCodeGrant(_AuthorizationCodeGrant):\n      def save_authorization_code(self, code, request):\n          raise RuntimeError(\"not reached\")\n      def query_authorization_code(self, code, client):\n          return None\n      def delete_authorization_code(self, authorization_code):\n          pass\n      def authenticate_user(self, authorization_code):\n          return None\n\n  app = Flask(__name__)\n  app.secret_key = \"testing\"\n\n  server = AuthorizationServer(\n      app,\n      query_client=lambda client_id: None,\n      save_token=lambda token, request: None,\n  )\n  server.register_grant(AuthorizationCodeGrant)\n\n  @app.route(\"/oauth/authorize\", methods=[\"GET\", \"POST\"])\n  def authorize():\n      try:\n          grant = server.get_consent_grant(end_user=None)\n      except OAuth2Error as error:\n          return server.handle_error_response(request, error)\n      return server.create_authorization_response(grant=grant, grant_user=None)\n\n  with app.test_client() as c:\n      cases = {\n          \"without_redirect_uri\": \"/oauth/authorize?response_type=totally-unsupported\u0026state=s1\",\n          \"with_attacker_redirect_uri\": \"/oauth/authorize?response_type=totally-\n  unsupported\u0026redirect_uri=https%3A%2F%2Fevil.example%2Flanding\u0026state=s1\",\n      }\n      out = {}\n      for name, url in cases.items():\n          r = c.get(url)\n          out[name] = {\n              \"status\": r.status_code,\n              \"location\": r.headers.get(\"Location\"),\n              \"body\": r.get_data(as_text=True),\n          }\n      print(json.dumps(out, indent=2))\n  PY\n\n  Observed result:\n\n  {\n    \"without_redirect_uri\": {\n      \"status\": 400,\n      \"location\": null,\n      \"body\": \"{\\\"error\\\": \\\"unsupported_response_type\\\", \\\"error_description\\\": \\\"totally-\n  unsupported\\\", \\\"state\\\": \\\"s1\\\"}\"\n    },\n    \"with_attacker_redirect_uri\": {\n      \"status\": 302,\n      \"location\":\n  \"https://evil.example/landing?error=unsupported_response_type\u0026error_description=totally-unsupported\u0026state=s1\",                                                                                    \n      \"body\": \"\"\n    }\n  }\n\n  This demonstrates that the only difference between a local error and an external redirect is\n  whether the attacker supplies redirect_uri.\n\n  The same behavior was locally reproduced with the Django integration using RequestFactory; it\n  returned:\n\n  {\n    \"status\": 302,\n    \"location\":\n  \"https://evil.example/landing?error=unsupported_response_type\u0026error_description=totally-unsupported\u0026state=s1\",                                                                                    \n    \"body\": \"\"\n  }\n\n### Impact\n  This is an unauthenticated open redirect in an internet-facing authorization endpoint.\n\n  Who is impacted:\n\n  - Any deployment using Authlib\u0027s OAuth 2.0 authorization server and the documented authorization\n    endpoint flow.\n  - No special feature flag is required beyond running the authorization endpoint itself.\n\n  Attacker prerequisites:\n\n  - None beyond the ability to send a victim to a crafted authorization URL.\n\n  Practical harm:\n\n  - Phishing and credential theft by abusing a trusted authorization server domain as a\n    redirector.\n  - Bypass of domain-based allowlists that trust the authorization server\u0027s host.\n  - SSO / OAuth confusion in ecosystems where trusted authorization endpoints are expected to\n    reject unregistered redirect URIs before redirecting.\n\n  The issue is especially concerning because the redirect happens before client existence and\n  redirect URI legitimacy are established.",
  "id": "GHSA-w8p2-r796-3vmq",
  "modified": "2026-06-08T17:52:04Z",
  "published": "2026-06-08T17:52:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type"
}

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.