CVE-2026-44681

What it actually does

Unauthenticated open redirect in Authlib’s OpenID Connect Implicit and Hybrid grant authorization endpoints. When a request omits the openid scope, redirect-target checks that normally constrain OIDC responses are skipped, so the server can emit an HTTP 302 Location to an attacker-chosen URL. Confidentiality and integrity impact is limited (reflected redirect / phishing aid); availability is unaffected.

Why it matters to the business

A trusted identity provider can be used as a springboard to phishing or token-harvesting pages, eroding user trust and enabling account takeover via social engineering. Authlib is a common Python OAuth/OIDC building block, so many downstream authorization servers may be exposed. Risk is moderate: CVSS 6.1, user interaction required, EPSS ~0.0029 (slight 30-day rise, still low), not on KEV, no ransomware use, and no public exploit maturity ~124 days after publication. Residual risk is reputational harm, credential theft, and OAuth-code/token leakage if users follow crafted links.

How an attack unfolds

An unauthenticated attacker crafts an authorization-endpoint request for OpenID Implicit or Hybrid grants that leaves out the openid scope and points the redirect at a site they control. They lure a user (email, chat, or compromised page) to that URL. The legitimate authorization server responds with HTTP 302 to the attacker host, making the malicious page appear to originate from the real IdP. The attacker then presents a lookalike login or captures redirected OAuth material. No privileged access or pre-auth foothold is required; success depends on the victim following the link. No named APT or ransomware campaigns are associated.

How to fix it

Upgrade Authlib to 1.6.12 on the 1.6 line or 1.7.1 on the 1.7 line (or later). Prefer Authorization Code + PKCE and disable or tightly restrict Implicit and Hybrid grants. Enforce that OIDC flows require the openid scope and that redirect_uri is an exact, pre-registered HTTPS match. Until patched, reject authorize requests that use implicit/hybrid response types without openid, and treat unexpected off-origin Location headers from the authorize endpoint as failures. Rebuild and redeploy any service that vendors Authlib.

How to confirm the fix worked

Confirm the running Authlib package is 1.6.12+, 1.7.1+, or a later release in lockfiles, images, and runtime metadata. In a non-production check, submit an authorize request for implicit/hybrid grants without openid and verify the server no longer 302s to an unregistered external URL (error or strict registered redirect only). Review IdP config: registered redirect URIs, disabled implicit/hybrid, openid required for OIDC. Inventory dependents and containers still pinning older Authlib.

Typical attack path

1. Locate an Authlib-based authorization server that still offers OpenID Implicit or Hybrid grants on a pre-fix release.
2. Build an authorization request that omits the openid scope and uses an attacker-controlled redirect target.
3. Distribute the link so a user interacts with it (phishing or embedded navigation).
4. Victim hits the real authorize endpoint; server issues HTTP 302 to the attacker URL.
5. Attacker hosts a lookalike IdP page or captures redirected OAuth/OIDC parameters.
6. Optional follow-on: phish credentials or misuse captured codes/tokens against the application.

How to detect it

This is a protocol-level open redirect, not malware, so look at IdP/web logs rather than hosts. Review authorization-endpoint access logs since at least 2026-05-27 for implicit or hybrid response types (token, id_token, code token, code id_token, code id_token token) where scope omits openid and the response is HTTP 302 with Location off the registered redirect set. Correlate those 302s with the same users later hitting unknown hosts, failed logins, or unusual token use. Check reverse-proxy/WAF logs for authorize query strings lacking openid and external Location headers. Email/web-proxy logs may show phishing URLs that embed your authorize endpoint. No public exploit kit, named actor, or ransomware overlay is documented; absence of these log patterns does not prove lack of phishing that never hit your logs.

• GET authorize query with response_type containing token or id_token and scope omitting openid
• HTTP 302 from OIDC authorize endpoint with Location host not in the client’s registered redirect_uri list
• Authorize requests using OpenIDImplicitGrant or OpenIDHybridGrant without scope=openid
• Phishing URLs whose path hits the authorization endpoint and whose redirect parameter is an unrelated external origin
• User sessions that follow a first-party authorize 302 immediately with a request to an unregistered external login-lookalike host

What your security team should do

• Patch Authlib to 1.6.12 or 1.7.1 (or newer) and redeploy all OAuth/OIDC servers that bundle it.
• Disable OpenID Implicit and Hybrid grants where not required; prefer code flow with PKCE.
• Enforce pre-registered exact redirect_uri matching and require openid for OIDC authorize requests.
• Hunt historical authorize logs for missing openid scope plus 302 to unregistered hosts; treat hits as phishing-assist events.
• Add WAF/IdP rules to flag implicit/hybrid authorize requests without openid and anomalous Location headers.
• Track Authlib in SCA/SBOM pipelines so future OIDC grant bugs are patched quickly.