CVE-2024-8995: Authorization Code issued for Deleted User reuse in Multiple WSO2 Products Allows Unauthorized Access
Unused authorization codes issued to deleted users are not being properly invalidated or removed from the system. This allows for the persistence of these codes, enabling them to be potentially reused.
If an attacker possesses both the authorization code and the associated client credentials (client ID and client secret), they can leverage these unused codes to obtain access tokens on behalf of users who have already been deleted. This may lead to unauthorized access to sensitive resources and services, contingent on the scopes originally authorized for the compromised authorization code.
Security readout for executives and security teams
Plain-English summary
Deleting a user may not invalidate an unused OAuth authorization code previously issued to that account. Someone holding both that code and the application's client ID and secret could obtain an access token as the deleted user, potentially reaching resources allowed by the original scopes.
Executive priority
Treat this as a targeted identity-control weakness rather than an emergency. Prioritize systems handling sensitive APIs or privileged OAuth scopes, especially where client credentials might be shared or exposed. Confirm affected versions promptly, follow WSO2 guidance, and investigate token issuance involving deleted accounts.
Technical view
This is an OAuth authorization-code lifecycle failure classified as CWE-613. An unused code can persist after user deletion and remain redeemable with matching client credentials. CVSS 3.1 is 4.9: network-accessible, high complexity, low privileges, no user interaction, with limited confidentiality and integrity impact and no availability impact.
Likely exposure
Potential exposure includes deployments of the listed WSO2 products and Carbon OAuth versions that retain unused authorization codes after account deletion. Exact affected-version interpretation is uncertain because the supplied product records mostly state a default status of unaffected, while Carbon OAuth states unknown. Confirm applicability against the vendor advisory.
Exploitation context
Successful abuse requires an attacker to possess a still-unused authorization code plus the associated client ID and client secret. Impact is limited by the scopes originally authorized. The supplied sources provide no evidence of active exploitation, and the CVE is not listed as KEV in the bundle.
Researcher notes
The central condition is persistence of an unused authorization code beyond user deletion. Assessment should focus on code invalidation, identity-state checks during token exchange, and scope enforcement. The supplied metadata does not identify a specific fixed release, and its affected-version/default-status fields are ambiguous; use the vendor advisory as authoritative guidance.
Mitigation direction
Review WSO2 advisory WSO2-2024-2753 for product-specific fixed versions or mitigations.
Apply the vendor-recommended update or mitigation after confirming product and version applicability.
Rotate client secrets where authorization codes or client credentials may have been exposed.
Revoke residual codes and tokens associated with deleted users where supported.
Minimize OAuth scopes and protect authorization codes and client credentials from disclosure.
Validation and detection
Inventory deployed WSO2 products and compare exact versions with advisory WSO2-2024-2753.
Verify user deletion invalidates all outstanding authorization codes for that identity.
Audit token issuance records for access tokens granted after the associated user was deleted.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-613: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-613 · source CWE mapping
Insufficient Session Expiration
Insufficient Session Expiration represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.