Wso2 Carbon Oauth
Monthly
OAuth token revocation in WSO2 Identity Server fails to invalidate access and refresh tokens for accounts whose usernames contain mixed-case characters when the deployment pairs a case-insensitive user store with a case-sensitive identity database. An authenticated attacker (PR:L) who already holds a valid, unexpired token for such an account can keep using it for actions that should have been blocked after a revocation-triggering lifecycle event, bounded by the token's natural expiry. Affected deployments are a non-default configuration subset, the trigger requires that specific store/database mismatch plus a mixed-case username, and no public exploit has been identified at time of analysis; the input 7.4 score assumes AC:L, whereas the assessed vector uses AC:H, so real-world risk is materially lower than the headline number suggests.
WSO2 Identity Server and the related WSO2 Carbon OAuth family of products will issue OAuth2 access tokens for JWT Bearer and SAML2 Bearer grant requests even when the federated Identity Provider (IDP) that vouched for the assertion has been disabled, because the IDP's enabled state is not re-validated before the token is minted. Remote unauthenticated attackers can exploit this only if they already hold a valid assertion issued by that now-disabled IDP, which is why the vendor rates it CVSS 4.8 with high attack complexity (AC:H) and limited confidentiality/integrity impact. It is not listed in CISA KEV and no public exploit has been identified at time of analysis, but the priority label is this_month, so it warrants scheduling rather than emergency response.
Cached OAuth2 introspection responses in WSO2 API Manager, WSO2 Identity Server and related WSO2 identity/gateway products can cause a revoked access token to be returned to the client again until the cache entry is cleared, but only when the allowed_scopes configuration is enabled. An authenticated OAuth2 client able to call both the introspection and revocation endpoints must also hit a narrow ordering window - introspecting a token immediately before revoking it - which is why the issue is rated low (CVSS 3.1, AV:N/AC:H/PR:L, C:N/I:N/A:L). The re-issued token is not accepted for API authorization, so there is no confidentiality or integrity loss; the practical effect is a limited availability/authentication-flow disruption, since affected users may be unable to obtain a new valid token until the cache is flushed. No public exploit code and no active exploitation have been identified at time of analysis, and the priority decision is monitor.
Previously issued OAuth access tokens for sub-organization users remain valid in WSO2 Identity Server 7.0.0 before 7.0.0.85 and WSO2 Carbon OAuth 7.0.26 before 7.0.26.51 after a password reset, role change, or sub-organization disablement. The flaw is a conditional token-revocation gap: an attacker must already hold a valid token for a user whose access context was changed, so the bug does not itself grant token access. EPSS is 0.14% (3rd percentile), no public exploit is identified at time of analysis, and a vendor patch is available with a vuln.today priority of this_week.
WSO2 Carbon OAuth, as shipped in WSO2 Identity Server, API Manager, and related WSO2 products, can leave session-bound tokens valid after the user session ends when token binding validation is enabled and the 'Revoke token upon user logout' option is inactive. An attacker who already possesses such a token can retain access to protected applications and data after logout; this is a moderate, conditionally exploitable session-management flaw that requires a non-default configuration and prior token acquisition, and no public exploit code or active exploitation is identified at time of analysis.
Insufficient refresh token invalidation in WSO2 Identity Server's user impersonation flow allows a privileged attacker who has already obtained an impersonated access token to silently renew that authorization via the OAuth refresh token grant, sustaining unauthorized access well beyond the intended session lifetime. The integrity impact is two-fold: the attacker continues performing actions on behalf of the legitimate user, and audit logs attribute those actions to the victim identity rather than the true actor, corrupting traceability and compliance posture. No public exploit is identified and exploitation is bounded by high privilege prerequisites (PR:H) and adjacent network access (AV:A), placing realistic risk firmly in insider-threat and compromised-administrator scenarios.
OAuth token revocation in WSO2 Identity Server fails to invalidate access and refresh tokens for accounts whose usernames contain mixed-case characters when the deployment pairs a case-insensitive user store with a case-sensitive identity database. An authenticated attacker (PR:L) who already holds a valid, unexpired token for such an account can keep using it for actions that should have been blocked after a revocation-triggering lifecycle event, bounded by the token's natural expiry. Affected deployments are a non-default configuration subset, the trigger requires that specific store/database mismatch plus a mixed-case username, and no public exploit has been identified at time of analysis; the input 7.4 score assumes AC:L, whereas the assessed vector uses AC:H, so real-world risk is materially lower than the headline number suggests.
WSO2 Identity Server and the related WSO2 Carbon OAuth family of products will issue OAuth2 access tokens for JWT Bearer and SAML2 Bearer grant requests even when the federated Identity Provider (IDP) that vouched for the assertion has been disabled, because the IDP's enabled state is not re-validated before the token is minted. Remote unauthenticated attackers can exploit this only if they already hold a valid assertion issued by that now-disabled IDP, which is why the vendor rates it CVSS 4.8 with high attack complexity (AC:H) and limited confidentiality/integrity impact. It is not listed in CISA KEV and no public exploit has been identified at time of analysis, but the priority label is this_month, so it warrants scheduling rather than emergency response.
Cached OAuth2 introspection responses in WSO2 API Manager, WSO2 Identity Server and related WSO2 identity/gateway products can cause a revoked access token to be returned to the client again until the cache entry is cleared, but only when the allowed_scopes configuration is enabled. An authenticated OAuth2 client able to call both the introspection and revocation endpoints must also hit a narrow ordering window - introspecting a token immediately before revoking it - which is why the issue is rated low (CVSS 3.1, AV:N/AC:H/PR:L, C:N/I:N/A:L). The re-issued token is not accepted for API authorization, so there is no confidentiality or integrity loss; the practical effect is a limited availability/authentication-flow disruption, since affected users may be unable to obtain a new valid token until the cache is flushed. No public exploit code and no active exploitation have been identified at time of analysis, and the priority decision is monitor.
Previously issued OAuth access tokens for sub-organization users remain valid in WSO2 Identity Server 7.0.0 before 7.0.0.85 and WSO2 Carbon OAuth 7.0.26 before 7.0.26.51 after a password reset, role change, or sub-organization disablement. The flaw is a conditional token-revocation gap: an attacker must already hold a valid token for a user whose access context was changed, so the bug does not itself grant token access. EPSS is 0.14% (3rd percentile), no public exploit is identified at time of analysis, and a vendor patch is available with a vuln.today priority of this_week.
WSO2 Carbon OAuth, as shipped in WSO2 Identity Server, API Manager, and related WSO2 products, can leave session-bound tokens valid after the user session ends when token binding validation is enabled and the 'Revoke token upon user logout' option is inactive. An attacker who already possesses such a token can retain access to protected applications and data after logout; this is a moderate, conditionally exploitable session-management flaw that requires a non-default configuration and prior token acquisition, and no public exploit code or active exploitation is identified at time of analysis.
Insufficient refresh token invalidation in WSO2 Identity Server's user impersonation flow allows a privileged attacker who has already obtained an impersonated access token to silently renew that authorization via the OAuth refresh token grant, sustaining unauthorized access well beyond the intended session lifetime. The integrity impact is two-fold: the attacker continues performing actions on behalf of the legitimate user, and audit logs attribute those actions to the victim identity rather than the true actor, corrupting traceability and compliance posture. No public exploit is identified and exploitation is bounded by high privilege prerequisites (PR:H) and adjacent network access (AV:A), placing realistic risk firmly in insider-threat and compromised-administrator scenarios.