Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-41479

CVE-2026-41479: Authlib OAuth Open Redirect Vulnerability

CVE-2026-41479 is an open redirect flaw in Authlib's OAuth 2.0 authorization endpoint that allows unauthenticated attackers to redirect users to malicious sites. This post covers technical details, affected versions, and patches.

Published:

CVE-2026-41479 Overview

CVE-2026-41479 is an open redirect vulnerability [CWE-601] in Authlib, a Python library used to build OAuth 2.0 and OpenID Connect servers. Versions prior to 1.6.10 and 1.7.1 allow the OAuth 2.0 authorization endpoint to redirect to an attacker-controlled URL when a request specifies an unsupported response_type. The vulnerable code path executes before client lookup and before any redirect URI validation. An attacker can craft a single unauthenticated request to obtain a 302 Location response pointing to an arbitrary URL. No valid client registration, authenticated user, or prior session state is required.

Critical Impact

Unauthenticated attackers can weaponize the OAuth 2.0 authorization endpoint as an open redirect to support phishing and credential theft campaigns that appear to originate from the trusted identity provider domain.

Affected Products

  • Authlib versions prior to 1.6.10
  • Authlib versions prior to 1.7.1
  • Python applications exposing OAuth 2.0 or OpenID Connect authorization endpoints built on Authlib

Discovery Timeline

  • 2026-06-22 - CVE-2026-41479 published to NVD
  • 2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-41479

Vulnerability Analysis

The flaw resides in Authlib's OAuth 2.0 authorization server logic, specifically in authlib/oauth2/rfc6749/authorization_server.py. When the authorization endpoint receives a request whose response_type does not match any registered grant handler, the server raises an UnsupportedResponseTypeError and passes the user-supplied redirect_uri directly into the error response. The framework then issues an HTTP 302 redirect to that value without validating it against a registered client.

RFC 6749 §4.1.2.1 explicitly requires that the authorization server only redirect with an error response after confirming the client exists and the redirect_uri matches a registered URI. The pre-patch behavior violates this requirement and converts the endpoint into an unauthenticated open redirect primitive.

Root Cause

The root cause is missing input validation order. Client lookup and redirect_uri validation occur after grant dispatch, so an unsupported response_type short-circuits the validation flow entirely. The unvalidated request.payload.redirect_uri value reaches the error handler unchecked.

Attack Vector

An attacker sends a single GET request to the authorization endpoint with an unsupported response_type parameter and a malicious redirect_uri pointing to an attacker-controlled host. The server returns a 302 response with the Location header set to the attacker's URL. The attacker distributes the crafted link in phishing emails, leveraging the legitimate identity provider domain to bypass user suspicion and email security filters.

python
             if grant_cls.check_authorization_endpoint(request):
                 return _create_grant(grant_cls, extensions, request, self)
 
+        # Per RFC 6749 §4.1.2.1, only redirect with the error if the client
+        # exists and the redirect_uri has been validated against it.
+        redirect_uri = None
+        if client_id := request.payload.client_id:
+            if client := self.query_client(client_id):
+                if requested_uri := request.payload.redirect_uri:
+                    if client.check_redirect_uri(requested_uri):
+                        redirect_uri = requested_uri
+                else:
+                    redirect_uri = client.get_default_redirect_uri()
+
         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,
+            redirect_uri=redirect_uri,
         )

Source: Authlib Security Patch Commit 3be0846

Detection Methods for CVE-2026-41479

Indicators of Compromise

  • HTTP 302 responses from the OAuth 2.0 authorization endpoint with Location headers pointing to external, untrusted domains.
  • Authorization endpoint requests containing uncommon or invalid response_type values such as random strings or unsupported grant identifiers.
  • Repeated authorization requests with varying redirect_uri parameters from the same source IP, indicating fuzzing or weaponization attempts.

Detection Strategies

  • Inspect web access logs for requests to /oauth/authorize (or equivalent) where response_type does not match the application's documented supported values.
  • Correlate authorization endpoint requests with redirect_uri query parameters whose host does not match the registered client domains.
  • Deploy a Web Application Firewall (WAF) rule that flags redirect_uri values containing external hostnames at the authorization endpoint.

Monitoring Recommendations

  • Alert on outbound referrer chains originating from the identity provider domain to unknown destinations.
  • Track the rate of UnsupportedResponseTypeError events in application logs to detect probing activity.
  • Monitor phishing intelligence feeds for URLs abusing your authorization endpoint as an open redirect.

How to Mitigate CVE-2026-41479

Immediate Actions Required

  • Upgrade Authlib to version 1.6.10 or 1.7.1 immediately, depending on the branch in use.
  • Audit production OAuth 2.0 authorization endpoints for unsupported response_type traffic over the past 90 days.
  • Notify users and downstream relying parties if phishing campaigns leveraging the endpoint are observed.

Patch Information

The fix is delivered in Authlib 1.6.10 and 1.7.1. Commit 3be08468201a7766a93012ce149ea12822cab096 adds client lookup and redirect_uri validation before raising UnsupportedResponseTypeError. The patched code only echoes a redirect_uri after confirming the client exists via query_client() and the URI passes client.check_redirect_uri(). Review the GitHub Security Advisory GHSA-w8p2-r796-3vmq for full advisory details.

Workarounds

  • If patching is not immediately possible, deploy a reverse proxy or WAF rule that rejects requests to the authorization endpoint where redirect_uri does not match an allow-list of registered client URIs.
  • Strip or normalize unsupported response_type values at the proxy layer to prevent the vulnerable code path from executing.
  • Apply rate limiting to the authorization endpoint to slow automated abuse until the patch is rolled out.
bash
# Upgrade Authlib to a patched version
pip install --upgrade "authlib>=1.7.1"

# For the 1.6.x branch
pip install --upgrade "authlib>=1.6.10,<1.7.0"

# Verify installed version
python -c "import authlib; print(authlib.__version__)"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.