Casdoor versions 2.362.0 and earlier do not verify that a JWT used for token exchange is still active. The GetTokenExchangeToken() function in object/tokenoauth.go validates the JWT signature and parses its claims, but never queries the Token table to verify whether the subject token has been revoked or invalidated. Because the revocation check is entirely absent, administrators are unable to terminate active sessions or revoke compromised tokens.

In Casdoor versions 2.362.0 and earlier, the SAML service provider implementation does not validate the AudienceRestriction element in SAML assertions. The buildSp function in object/samlsp.go never sets AudienceURI on the gosaml2 SAMLServiceProvider struct and never inspects WarningInfo.NotInAudience. This allows assertions issued for other service providers to be accepted by Casdoor.

Casdoor versions 2.362.0 and earlier contain a vulnerability enabling cross-organization token exchange. The GetTokenExchangeToken function in object/tokenoauth.go validates JWT signatures but does not verify that the token's user belongs to the same organization as the target application. This can result in privilege escalation across organizational boundaries.

Casdoor versions 2.362.0 and earlier contain a vulnerability that allows an attacker to bypass authentication by supplying an arbitrary signing certificate. The buildSpCertificateStore function extracts the X.509 certificate directly from the incoming SAMLResponse instead of using the trusted pre-configured Identity Provider certificate, allowing an attacker to forge assertions signed with an attacker-controlled key.

Casdoor versions 2.362.0 and earlier contain a vulnerability involving unverified email binding that may enable account takeover. The getExistUserByBindingRule function matches users by email without checking the emailverified claim from upstream providers; the idp.UserInfo struct does not even include a EmailVerified field. An attacker can supply an unverified email claim from an upstream provider to take over accounts that use the same email address.

In Casdoor versions 2.362.0 and earlier, the SAML callback handler in controllers/auth.go accepts any well-formed SAMLResponse sent to /api/acs without verifying that it corresponds to an AuthnRequest previously issued by Casdoor. Additionally, if an administrator disables or deletes an IdP (Identity Provider) after a SAML flow has started, the handler still processes the response using the provider snapshot loaded at the start of the request. As a result, an attacker controlling a registered upstream IdP can send unsolicited SAML responses, or replay a legitimately captured response in a different session or after the original flow has ended. In both cases, Casdoor accepts the response and issues a session, enabling persistent unauthorized access.

Casdoor versions 2.362.0 and earlier map SAML assertions to user sessions without replay protection. The ParseSamlResponse() function in object/samlsp.go calls sp.RetrieveAssertionInfo() and immediately maps the result to a user session. There is no assertion ID cache, OneTimeUse condition enforcement, or replay detection anywhere in the SAML SP code path. As a result, an attacker can replay a previously captured SAML assertion to obtain an authenticated session for the assertion’s subject, including administrator accounts, without needing the user’s password or MFA credentials.

Casdoor versions 2.362.0 and earlier do not enforce SAML assertion time bounds. The gosaml2 library reports all time-validation results, including NotOnOrAfter and NotBefore, in the assertionInfo.WarningInfo field. However, ParseSamlResponse() never reads this field, meaning that time bounds are computed by the library but silently discarded before the user session is issued.

An issue in the permission verification module and organization/application editing interface in Casdoor before 2.63.0 allows remote authenticated administrators of any organization within the system to bypass the system's permission verification mechanism by directly concatenating URLs after login.

A vulnerability was found in Casdoor up to 1.335.0. It has been classified as problematic. Affected is an unknown function of the file /conf/app.conf of the component Configuration File Handler. The manipulation leads to files or directories accessible. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-266838 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability has been found in Casdoor up to 4.0.0. This affects an unknown function of the file controllers/resource.go of the component upload-resource API. Such manipulation leads to missing authentication. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The vendor deleted the GitHub issue for this vulnerability without any explanation. Afterwards the vendor was contacted early about this disclosure via email but did not respond in any way.

Casdoor versions 2.362.0 and earlier contain a logic flaw in the social‑login binding flow that allows users to bypass configured MFA requirements. The binding‑rule code path in controllers/auth.go calls HandleLoggedIn directly without invoking checkMfaEnable. Any user authenticating via this path is logged in without MFA enforcement.

Casdoor is vulnerable to a CORS misconfiguration and a reflected Cross-Site Scripting (XSS) vulnerability, both of which may allow an attacker to take actions on behalf of the signed-in user.

Casdoor is vulnerable to a CORS misconfiguration and a reflected Cross-Site Scripting (XSS) vulnerability, both of which may allow an attacker to take actions on behalf of the signed-in user.