Casdoor EUVD-2026-32948

Exploitation requires a network-reachable Casdoor instance at version ≤ 2.362.0 with the OAuth 2.0 Token Exchange grant (RFC 8693) enabled and at least two organizations (tenants) configured on the same instance - the attack is meaningless on single-tenant deployments. The attacker must possess any validly signed JWT issued by that Casdoor instance, which despite the CVSS PR:N rating typically means holding a legitimate account in at least one organization (trivially obtained where self-registration is enabled in any tenant, or via a compromised low-privilege account). No user interaction by a victim is required, no special platform is needed, and exploitation runs entirely against the token endpoint over HTTP(S); the practical ceiling on exploitation is therefore the availability of any valid token plus the existence of a cross-organization target application worth pivoting to.

The CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H scores 9.8 and indicates a network-reachable, low-complexity, unauthenticated path to full confidentiality, integrity, and availability impact - appropriate for an IAM service that can be pivoted to compromise downstream applications. However, EPSS sits at just 0.02% (5th percentile), and the vulnerability is not listed in CISA KEV, with no public exploit identified at time of analysis. The CVSS PR:N rating warrants scrutiny: token exchange typically requires the attacker to first obtain a validly signed JWT from any organization in the same Casdoor instance, so practical exploitation usually requires being a legitimate user of at least one tenant (or accessing a self-registration-enabled tenant) rather than truly anonymous attack. This is best characterized as a high-severity tenant-isolation break that is highly impactful where multi-tenant Casdoor deployments exist, but the absence of weaponized POCs, the niche of the affected product, and the prerequisite of holding any valid token explain the low EPSS. Reporting by CERT/CC (kb.cert.org/vuls/id/780781) raises confidence in the vendor coordination, but the public KB entry should be reviewed for any disclosed exploitation details before treating it as theoretical.

An attacker obtains a valid JWT in a low-privilege Casdoor organization - for example by registering in a tenant that allows self-signup or by compromising a single low-value account - then calls the OAuth 2.0 Token Exchange endpoint pointing subject_token at their JWT and the target audience at an application owned by a different, higher-value organization on the same Casdoor instance. Because GetTokenExchangeToken validates only the signature and not the tenant binding, Casdoor returns a new access token scoped to the victim organization's application, which the attacker uses to access administrative resources, internal SaaS, or downstream services federated through that tenant. No public exploit identified at time of analysis, but the bug is straightforward to weaponize once the endpoint and parameters are known.