WSO2 Identity Server EUVD-2025-211243

Exploitation requires the deployment to use the JWT Bearer or SAML2 Bearer OAuth2 grant types with a federated Identity Provider that has been disabled (not deleted) in the WSO2 configuration, and the attacker must present a valid assertion/token associated with that disabled IDP - the server fails to re-validate IDP enabled-state before issuing an access token. Limiting factors: the flaw only manifests in deployments actually using these bearer grant types with a previously-configured-then-disabled IDP, and the high attack complexity (AC:H) reflects that the attacker needs a valid IDP-issued assertion rather than exploiting a default configuration. It does not affect deployments that never enabled these grant types, and the impact is bounded to resources that should have been gated by the disabled IDP.

This is a genuine but moderate-priority issue, not a top-tier emergency. The vendor CVSS vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, base 4.8) describes a network-reachable, unauthenticated flaw with high attack complexity and only Low confidentiality and Low integrity impact, no availability impact - consistent with CWE-862 (missing authorization check on IDP state). The AC:H rating reflects that exploitation is not trivial: it depends on the specific precondition of an Identity Provider having been disabled while federated bearer grant types remain in use. On exploitation signals, there is no CISA KEV listing, no EPSS score supplied in the input, and no public exploit or PoC reference (the only reference is the WSO2 security advisory itself), so the status is no public exploit identified at time of analysis. The vuln.today decision label is 'this_month', which aligns with a scheduled-remediation posture rather than act_now/emergency. No signals conflict here; the main gap is the absence of an EPSS probability, so widespread opportunistic exploitation cannot be quantified from the data - treat this as a correctness/access-control fix to schedule, not a drop-everything event.

An administrator disables a previously configured Identity Provider, expecting all tokens associated with it to stop working, but the JWT Bearer or SAML2 Bearer grant path never re-checks the IDP's enabled state. An attacker who still possesses a valid assertion tied to that disabled IDP submits it to the token endpoint and receives an access token, then uses it to reach protected resources that should have been cut off. No public exploit code is identified at time of analysis, and the high attack complexity reflects the need for a valid assertion against a now-disabled IDP.