CVE-2026-41425

What it actually does

Authlib's Starlette OAuth client (authlib.integrations.starlette_client.OAuth) prior to 1.6.11 omits CSRF defenses on cache operations used to store OAuth/OIDC flow material such as state, nonce, and related session bindings. A cross-site request that the victim's browser is induced to send can create or overwrite that cached material. Per the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N), impact is limited confidentiality and integrity of OAuth client cache state; availability is unaffected and user interaction is required.

Why it matters to the business

Applications that use Authlib's Starlette/FastAPI OAuth client can have a user's in-progress login or token-binding state altered if that user is tricked into visiting a malicious page. Effects are typically confused identity binding, login CSRF-style session association, or limited exposure of cached OAuth data—not full unauthenticated takeover. Exploit maturity is none, EPSS is about 0.0014 (still very low despite a +29% 30-day rise), the issue is not in CISA KEV, and no ransomware use is reported. Residual risk is therefore moderate and driven by user-trust, compliance, and the library's wide use in Python web stacks rather than by observed campaigns. Systems still on Authlib before 1.6.11 more than five months after publication remain unnecessarily exposed.

How an attack unfolds

An unauthenticated attacker hosts content that causes a victim's browser to issue a cross-site request against an application using the vulnerable Starlette OAuth client. Because cache operations lack CSRF protection, that request can insert or replace cached OAuth state while the victim is logged in or mid-flow. When the legitimate OAuth redirect or callback later reads the cache, the application may bind the victim to attacker-influenced state (for example, completing sign-in under an attacker-chosen account) or expose limited cached OAuth material. Success requires the victim to interact with the attacker's content and depends on the application's cache and cookie configuration; no public exploit code or named threat actors are associated with this CVE.

How to fix it

Upgrade the authlib package to 1.6.11 or later in every application and lockfile that depends on it, then redeploy. If an immediate upgrade is not possible, stop using authlib.integrations.starlette_client.OAuth cache-backed flows; require framework CSRF tokens on any endpoint that mutates OAuth client cache or session; set OAuth-related cookies to SameSite=Lax or Strict with Secure; and reject state-changing requests whose Origin or Referer is not an expected application origin. Re-test OAuth login, logout, and callback paths after the change. There is no KEV due date; treat 1.6.11 as the minimum fixed version stated by the project.

How to confirm the fix worked

Confirm installed and locked authlib versions are 1.6.11 or newer in application images, virtualenvs, and SBOM/lockfiles (pip, poetry, uv, pip-tools). Search source for authlib.integrations.starlette_client.OAuth and review that cache usage goes through the patched client. In a staging app still on the old version versus the patched version, verify that a cross-origin request cannot create or replace OAuth client cache entries, and that legitimate same-origin OAuth authorize and callback flows still succeed with valid state and nonce handling.

Typical attack path

1. Attacker identifies a web application that uses Authlib's Starlette OAuth client older than 1.6.11.
2. Attacker lures a victim to attacker-controlled content while the victim has a session or is about to start or finish an OAuth/OIDC login.
3. Victim interaction causes the browser to send a cross-site request that hits the unprotected OAuth client cache behavior.
4. Cached OAuth state, nonce, or related bindings for that victim are created or overwritten.
5. The victim continues the normal OAuth authorize or callback path.
6. The application consumes the attacker-influenced cache entries, producing an unauthorized state change or limited disclosure of cached OAuth data.

How to detect it

This is a CSRF-class flaw with no public exploit tooling, so successful abuse looks like an ordinary user OAuth flow rather than a distinct malware implant. Hunt web and reverse-proxy logs for OAuth authorize and callback requests whose Origin or Referer is not the application, especially when they coincide with cache or session writes around Starlette OAuth client usage. Look for callback failures or successes with missing, reused, or mismatched OAuth state or nonce values, sudden account-linkage or identity-provider binding changes after a cross-origin hit, and application error logs from authlib.integrations.starlette_client during login. There are no named APT campaigns to pivot from; absence of these anomalies does not prove non-exploitation because CSRF often leaves little unique residue.

What your security team should do

• Inventory all services that import authlib.integrations.starlette_client.OAuth and record the resolved authlib version.
• Upgrade those services to authlib 1.6.11 or later and ship updated lockfiles; prioritize internet-facing login and SSO apps.
• Until upgraded, enforce SameSite cookie policy and Origin/Referer checks on OAuth client routes and disable cache-backed Starlette OAuth client usage if feasible.
• Regression-test OAuth/OIDC login, callback, and logout after the upgrade.
• Do not treat this as an emergency KEV item; EPSS and exploit maturity remain low, but do not leave pre-1.6.11 Authlib in production given 157 days since publication.