Casdoor CVE-2026-9093

Exploitation requires that Casdoor is configured as a SAML Service Provider (the buildSp code path must be reached) AND that the IdP it federates with also issues assertions for at least one other service provider to which the attacker has legitimate access - the attacker needs a validly-signed SAML assertion bound by Audience to a different SP, which they then replay to Casdoor. The attack does not require credentials against Casdoor itself (PR:N) and needs no user interaction (UI:N) on the victim side, but it is bounded to deployments using SAML SSO and federated to a multi-tenant or multi-SP IdP; single-SP IdPs that only ever issue assertions audienced to Casdoor itself cannot supply a usable cross-audience assertion. Affected only on Casdoor versions ≤ 2.362.0.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H reflects an unauthenticated, network-reachable authentication bypass with full confidentiality, integrity and availability impact on the Casdoor identity tier - a realistic worst-case for an IAM product since compromise cascades to every downstream relying party. However, EPSS is exceptionally low at 0.02% (5th percentile) and the CVE is not on CISA KEV, indicating no observed mass exploitation; the 'Denial Of Service' tag in the input also conflicts with the description's authentication-bypass impact and appears to be miscategorized metadata that should be disregarded. Practical exploitability requires the attacker to first obtain a SAML assertion legitimately issued by a shared IdP for any other SP, which constrains the attack to environments where Casdoor trusts an IdP that also signs assertions for at least one other relying party - common in enterprise SSO but not in single-tenant deployments. Net assessment: high-severity-but-conditional; treat as priority patching for any Casdoor deployment federated to a multi-SP IdP, lower urgency for isolated single-SP setups.

An attacker who is a legitimate user of any other service provider federated to the same IdP that Casdoor trusts obtains a signed SAML assertion intended for that other SP (for example, by completing a normal login flow and capturing the POSTed SAMLResponse from their browser). They then replay the unmodified, validly-signed assertion to Casdoor's SAML ACS endpoint; because Casdoor never checks the Audience, it accepts the assertion and provisions a Casdoor session under the attacker-controlled NameID, granting access to whatever applications Casdoor fronts. No public exploit identified at time of analysis, but the attack requires only an HTTP POST of a captured assertion.