Cloudanix VulnDB

CVE-2026-114619

Medium · 4.6

CVSS

4.6

EPSS

0.2%

Published

Oct 22, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in a popular Python security library could let certain apps receive user identity information they were never supposed to get.

Exploitation
Requires User Interaction
Attacker needs
User Interaction
Complexity
Low
Impact
Data Exposure
Component
Library
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw bypasses scope filtering in OpenIDImplicitGrant by inspecting the unfiltered client-controlled payload.scope for the openid value after the parent grant has already restricted request.scope, allowing issuance of a signed ID token containing subject and profile claims to a client that was never granted the openid scope.

Why it matters to the business

Deployments using Authlib for OIDC implicit flow may leak user identity assertions to clients that were intentionally denied the openid scope, increasing the risk of unintended exposure of user profile data without requiring ransomware or known-exploitation campaigns.

How an attack unfolds

An attacker registers or controls a client permitted an ID token response type but explicitly denied the openid scope, appends openid to the raw request payload, obtains user consent for the visible scopes, and receives a valid signed ID token that would otherwise have been withheld.

How to fix it

Upgrade Authlib to version 1.9.0 or newer so that validate_authorization_request checks the already-filtered request.scope instead of request.payload.scope.

How to confirm the fix worked

Confirm the installed Authlib version is 1.9.0 or later; test that a client registered without the openid scope receives an error or no ID token when the request attempts to include openid.

Typical attack path

  1. Register or compromise a client allowed ID token response type but without openid scope
  2. Submit authorization request containing openid inside the raw payload.scope field
  3. Obtain end-user consent for the filtered scopes
  4. Receive and parse the resulting signed ID token containing user claims

How to detect it

Review application or library logs for implicit authorization requests where the raw payload contains openid but the filtered request.scope does not; correlate with issuance of ID tokens to clients lacking the openid scope.

What your security team should do

  • Upgrade all Authlib installations to 1.9.0 or later within the next maintenance window
  • Audit existing client registrations to ensure openid scope is granted only where intended
  • Add logging around implicit-grant ID token issuance to detect scope mismatches

The record

Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.0, OpenIDImplicitGrant.validate_authorization_request() checks the client-controlled raw request.payload.scope for openid after the parent grant has filtered allowed scopes into request.scope. A registered client permitted an ID token response type but not the openid scope can add openid to the request, obtain user consent, and receive a signed ID token containing the user's subject and allowed profile claims. Authorization code flow and deployments that allow openid for every client permitted an ID token response are not affected. In authlib/oidc/core/grants/implicit.py, OpenIDImplicitGrant.validate_authorization_request() checks request.payload.scope instead of the filtered request.scope. This issue is fixed in version 1.9.0.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities