WSO2 Identity Server EUVD-2026-112401

Exploitation is confined to WSO2 Identity Server deployments configured with a case-insensitive user store paired with a case-sensitive database for identity data - this specific mismatch is the root condition and is non-default. Additionally, the targeted account's username must contain mixed-case characters, and the attacker must already hold a valid, unexpired access or refresh token for that account (reflected as PR:L). The bypass window is bounded by the token's natural expiry: once the token expires, continued access ends. Deployments using a case-sensitive user store, lowercase-only usernames, or where token lifetimes are short are correspondingly less exposed. The available sources do not state whether this configuration combination is common across the installed base.

The input CVSS of 7.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L) looks high, but the real-world risk is materially lower than that number suggests once the signals are cross-referenced. The PR:L already encodes the core precondition: an attacker must already possess a valid access or refresh token for a target account, so this is a post-authentication access-control-persistence flaw, not a path to initial compromise. The network vector (AV:N) is accurate for OAuth token use, and the scope change (S:C) inflates the base score because the stale token grants continued access to resources beyond the identity component itself. No EPSS score, KEV listing, or PoC/exploit reference is present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active or automatable exploitation. The vuln.today decision label is this_week, consistent with a prioritize-but-not-emergency posture rather than act_now. The most important caveat is configuration dependence: the flaw only manifests in deployments that pair a case-insensitive user store with a case-sensitive identity database AND involve usernames containing mixed-case characters - the input does not confirm how common that combination is, so exposure is likely a subset of WSO2 Identity Server installations rather than all of them. Net assessment: a genuine but conditional token-revocation bypass worth patching on a near-term schedule, not a widespread emergency.

In a WSO2 Identity Server deployment using a case-insensitive user store backed by a case-sensitive identity database, an attacker holds a still-valid access or refresh token issued to an account whose username contains mixed-case characters (for example 'JohnDoe'). When a lifecycle event that should revoke that token occurs - such as logout, credential change, or administrative revocation - the username case mismatch causes revocation to silently fail, and the attacker continues using the un-revoked token to act with the victim's authorization until the token naturally expires. No public exploit identified at time of analysis; exploitation requires the attacker to already possess a valid token (PR:L) and is network-reachable (AV:N).