CVE-2026-87011: Denial of Service via Event-Loop Starvation in Open WebUI OIDC Back-Channel Logout

Open WebUI is a self-hosted user interface designed for interacting with large language models. The platform features integration with OpenID Connect (OIDC) for identity management and single sign-on capabilities. To facilitate user session synchronization, the application implements an OIDC back-channel logout endpoint at the URL path /oauth/backchannel-logout. This unauthenticated endpoint is exposed to the public internet to receive asynchronous logout notifications from external Identity Providers (IDPs).

The vulnerability, registered as CVE-2026-87011, represents a design flaw in how the platform processes inbound back-channel logout requests. In affected versions (starting from version 0.9.0 up to, but not including, 0.11.1), the system implements an unauthenticated mechanism that makes uncached outbound network requests and executes synchronous blocking operations within an asynchronous context. This configuration introduces a significant attack vector targeting application availability.

The underlying failure mode is categorized under CWE-405 (Asymmetric Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). An unauthenticated remote attacker can exploit this endpoint to deplete system resources and trigger a complete denial-of-service condition. Because the platform executes within a single-threaded ASGI event loop by default, the resource depletion immediately halts all concurrent application features for all users.

The root cause of CVE-2026-87011 involves a mismatch between synchronous blocking libraries and asynchronous execution environments. In Python-based web applications, frameworks like FastAPI utilize the asyncio event loop to manage thousands of concurrent connections on a single execution thread. To maintain responsiveness, any function running on the event loop must execute quickly or delegate blocking I/O operations to separate worker threads. When blocking synchronous calls are made directly within an async def handler, the entire event loop pauses until that operation completes.

In the vulnerable implementation of handle_backchannel_logout in backend/open_webui/utils/oauth.py, the code attempted to resolve the key used to sign the inbound logout_token dynamically. The endpoint parsed the unverified token to retrieve the issuer string (iss) and then entered a loop over all configured providers. For each provider, the application instantiated a new aiohttp.ClientSession and executed a network request to the provider's server metadata URL to check for matching configuration values. Because these requests were uncached, every individual HTTP request to the back-channel logout endpoint forced the server to make multiple dynamic outbound network requests.

Once a matching provider was identified, the application instantiated a pyjwt.PyJWKClient passing the provider's JSON Web Key Set (JWKS) URI. The application then called get_signing_key_from_jwt(logout_token) to retrieve the public verification key. The standard PyJWKClient implements synchronous socket operations to download the JWKS document. When executing inside the asynchronous handler, this synchronous call blocked the execution thread, starving the event loop of CPU time and preventing other asynchronous tasks from progressing.

An attacker can trigger this blocking sequence by transmitting a token with an issuer claim that matches a configured identity provider. The server is forced to perform network queries and block its execution thread while waiting for remote server responses. If the identity provider is slow, or if the attacker controls a registered identity provider endpoint that delays its responses, the event loop remains blocked, resulting in a persistent denial-of-service condition.

Analyzing the patch applied in commit aeda6ff13a25d3b3ba1b303609f35382db22142c clarifies both the mechanics of the vulnerability and the design of the fix. The vulnerable code relied on dynamically instantiating raw client sessions to perform lookup operations on every incoming packet. The patch resolves this by shifting from dynamic, uncached discovery to structured, asynchronous metadata resolution using the persistent OAuth client structures.

Below is an annotated comparison demonstrating how the application handles the OIDC provider lookup in the patched version. The patched implementation utilizes pre-initialized, cached client objects instead of performing raw outbound requests:

# PATCHED: In backend/open_webui/utils/oauth.py
# The application iterates over configured provider clients and loads cached metadata
matched_provider = None
matched_client = None
matched_jwks_uri = None
 
for provider_name in OAUTH_PROVIDERS:
    client = self.get_client(provider_name)
    if not client:
        continue
 
    try:
        # Non-blocking, cached loading of server metadata
        oidc_config = await client.load_server_metadata()
    except Exception as e:
        log.debug('Back-channel logout: error checking provider %s: %s', provider_name, e)
        continue
 
    if oidc_config.get('issuer') == token_issuer:
        matched_provider = provider_name
        matched_client = client
        matched_jwks_uri = oidc_config.get('jwks_uri')
        break

The most significant architectural change occurs during signature verification. The synchronous PyJWKClient lookup, which forced the event loop to freeze, was completely eliminated. The patched version implements an asynchronous fetch mechanism coupled with early input validation:

# PATCHED: Early validation of Key ID (kid) to fail fast
token_kid = jwt.get_unverified_header(logout_token).get('kid')
if not token_kid:
    raise jwt.InvalidTokenError('logout_token missing kid header')
 
try:
    # Asynchronous retrieval of JWKS dataset
    jwk_set = jwt.PyJWKSet.from_dict(await matched_client.fetch_jwk_set())
except jwt.PyJWTError as e:
    raise jwt.InvalidTokenError(str(e))
 
# Local, synchronous key lookup within the retrieved key set
signing_key = next(
    (
        key
        for key in jwk_set.keys
        if key.key_id == token_kid and key.public_key_use in ['sig', None]
    ),
    None,
) 

This remediation is complete. By utilizing the asynchronous method fetch_jwk_set() on the persistent matched_client, the application delegates network I/O to the event loop without blocking thread execution. If a network wait occurs, control returns to the event loop, allowing other concurrent user sessions to be processed. The addition of the early kid header check also prevents downstream key lookup operations for structurally malformed tokens.

Exploitation of CVE-2026-87011 requires no authentication and minimal network complexity. The target endpoint /oauth/backchannel-logout is designed to receive unauthenticated POST requests containing form-encoded data. An attacker only needs to know the issuer identifier of a configured OIDC provider on the target system to construct a token that triggers the vulnerable execution path.

To perform the attack, a client generates a JSON Web Token containing a valid header and claims, setting the iss (issuer) claim to match the target's configured provider. The attacker then issues an HTTP POST request containing this token to the target endpoint. Because signature verification occurs after the network resolution steps, the attacker does not need to possess a valid signing key. The server parses the unverified token, matches the issuer, and initiates the blocking JWKS retrieval.

When multiple concurrent requests are dispatched, each request triggers its own blocking cycle. Because the application runs on a single execution thread, the blocking duration scales with the number of concurrent requests. During this window, any other user attempting to connect to the Open WebUI instance faces an unresponsive interface, as the server cannot process any concurrent HTTP or WebSocket traffic.

The impact of CVE-2026-87011 is classified as High, with a CVSS v3.1 base score of 7.5. The primary security consequence is a complete denial of service (DoS) affecting the availability of the Open WebUI application. Because the application acts as an interface for managing and executing artificial intelligence inference tasks, an interruption of service halts active conversational sessions, model deployments, and background pipeline processing.

The vulnerability also acts as a traffic reflector, causing asymmetric resource consumption on upstream infrastructure. For every request processed by the vulnerable endpoint, the Open WebUI host issues outbound requests to the OIDC identity provider. A sustained attack can cause the identity provider to flag the Open WebUI host for rate-limit violations, which can disable authentication capabilities even after the attack traffic stops.

The vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H highlights that the attack is fully remote, requires no privileges, and demands no user interaction. While the exploit does not compromise data confidentiality or integrity directly, the complete loss of availability poses a significant operational risk for environments relying on self-hosted AI interfaces.

The definitive remediation for CVE-2026-87011 is upgrading the Open WebUI installation to version 0.11.1 or higher. This update replaces the synchronous network operations with non-blocking asynchronous calls and caches the retrieved identity provider metadata, neutralizing both the event-loop starvation and the traffic amplification vulnerabilities.

For systems where immediate upgrades are not possible, administrators should apply defensive configurations to mitigate risk. If the back-channel logout feature is not explicitly required by the authentication provider, it can be disabled by setting the environment variable ENABLE_OAUTH_BACKCHANNEL_LOGOUT=false. Disabling this feature prevents the application from exposing the vulnerable route, eliminating the attack surface entirely.

In addition to configuration changes, network-level rate limiting should be deployed on reverse proxies or Web Application Firewalls (WAFs) positioned in front of Open WebUI. Restricting POST requests directed at /oauth/backchannel-logout using low-frequency thresholds prevents automated tools from sustaining event-loop starvation. This defense-in-depth approach ensures the application remains responsive even when vulnerable endpoints are targeted.