Source: CERT/CC Vulnerability Notes, VU#780781 — https://kb.cert.org/vuls/id/780781
Casdoor versions 2.362.0 and earlier are affected by multiple identity and access management vulnerabilities, according to CERT/CC Vulnerability Note VU#780781. The common thread is serious: Casdoor may accept authentication material it should not trust, then issue sessions or tokens from it.
That changes the operational priority. This is not a narrow UI bug or a single edge-case login flaw. CERT/CC describes weaknesses across SAML processing, social-login binding, account binding, and token exchange. The reported impact includes authentication bypass, MFA bypass, account takeover, assertion replay, cross-organization privilege escalation, and difficulty revoking compromised tokens.
Casdoor is an open-source IAM platform and Model Context Protocol gateway used for authentication, single sign-on, and multi-protocol identity services. If it sits in front of real applications, a failure here is upstream of many other controls.
What changed in VU#780781#
CERT/CC published VU#780781 on May 28, 2026, covering Casdoor versions 2.362.0 and earlier. The note groups several CVEs around the same control plane: how Casdoor decides that an identity assertion, login binding, or token exchange should be trusted.
The SAML findings are the most structurally important. CERT/CC says Casdoor can extract an X.509 certificate from an incoming SAML message instead of relying on a trusted preconfigured Identity Provider certificate. If that behavior is reachable in a deployment, an attacker could sign forged assertions with an attacker-controlled key and have Casdoor treat them as valid.
Other SAML-related issues compound that risk. The note says Casdoor may fail to validate assertion audience, may map SAML assertions to sessions without replay protection, may ignore assertion time bounds, and may process unsolicited or stale SAML responses without confirming that they correspond to a previously issued request. In plain terms: the system may accept an assertion for the wrong service, at the wrong time, more than once, or outside the expected login flow.
CERT/CC maps several of these flaws to CVE-2026-9090, CVE-2026-9093, CVE-2026-9095, CVE-2026-9096, and CVE-2026-9098. The note’s summary is direct: these weaknesses can allow assertion forgery or replay, misuse of assertions across sessions, and processing of expired or unsolicited SAML responses.
The non-SAML issues also matter. CERT/CC describes a social-login binding path that can bypass configured MFA requirements. It also describes an account-binding issue where users may be matched by email address without verifying whether the upstream provider’s email claim was verified. Those findings are associated with CVE-2026-9091 and CVE-2026-9092.
Token exchange has its own failure mode. CERT/CC says Casdoor validates JWT signatures but does not verify that the token’s user belongs to the same organization as the target application. It also says Casdoor does not verify that a JWT used for token exchange is still active or check whether the token has been revoked. Those token-exchange findings are associated with CVE-2026-9094 and CVE-2026-9097.
Why this cve cluster matters#
The risk is broad because IAM is a multiplier. A vulnerable identity provider can turn one authentication weakness into access across many connected applications. That is why exploitability should not be judged only by whether an internet-facing endpoint has a flashy proof-of-concept. The more useful question is whether an attacker can interact with the Casdoor authentication interface in a way that reaches these flows.
CERT/CC says an attacker able to interact with Casdoor’s authentication interface may impersonate users, bypass MFA, forge and replay assertions, and gain persistent unauthorized access. That is enough to move this into security operations work, not just dependency hygiene.
The SAML findings are especially dangerous in environments where SSO is treated as a hard boundary. If audience checks, time bounds, request correlation, certificate trust, and replay protection are weak, then the usual SAML safety model breaks. The assertion stops being a short-lived, destination-bound proof and becomes something closer to a reusable login artifact.
The token revocation issue has a different operational edge. If administrators cannot reliably invalidate a token after compromise, incident response becomes weaker. Revocation is not decorative. It is one of the few levers defenders have after they suspect a session or token has escaped control.
There is also a privacy risk. IAM platforms handle identity attributes, account linkage, and access relationships. A takeover or impersonation path can expose more than application data. It can expose who has access to what, which accounts are linked, and which organizations or tenants share the same identity infrastructure.
What to check before acting#
Start with exposure. Confirm whether your organization runs Casdoor, whether it is version 2.362.0 or earlier, and whether it is reachable by untrusted users or external identity providers. Do not stop at the public edge. Internal IAM services can still be reachable by contractors, partners, compromised accounts, or federated IdPs.
Then check which flows are enabled. The CERT/CC note points to SAML, social-login binding, account binding, and token exchange. A deployment that does not use a given flow may have a narrower practical exposure, but that should be verified from configuration and logs, not assumed from memory.
Useful operational checks:
- Identify all Casdoor instances and their versions.
- Review whether SAML service provider functionality is enabled.
- Check configured IdPs and whether any are unused, disabled, stale, or externally controlled.
- Inspect whether MFA is enforced on all login and binding paths, not only the primary password flow.
- Review account-binding rules that rely on email claims from upstream providers.
- Confirm whether upstream providers mark email claims as verified and whether Casdoor consumes that distinction safely.
- Review token exchange paths across organizations or tenants.
- Test whether token revocation actually terminates access in your deployment.
- Look for suspicious SAML callbacks, repeated assertions, unsolicited responses, or logins that bypass normal MFA prompts.
Patching is the obvious next step if a fixed version is available from the project or your distribution channel. But patching alone should not be the only action. These flaws involve authentication state. Review recent access logs for administrator accounts, privileged users, and cross-organization activity. If exploitation is suspected, rotate relevant secrets, invalidate sessions where possible, and review connected applications that trust Casdoor-issued sessions or tokens.
Open source security work often fails at the handoff between disclosure and operations. The useful artifact is not just the CVE list. It is the mapping from vulnerability to enabled feature, reachable endpoint, trusted IdP, token lifetime, and revocation behavior. That is the same lesson behind broader security-artifact work: inventories and advisories only help when they become operational checks. See also: OpenSSF’s April signal: make security artifacts operational — https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
What not to overclaim#
CERT/CC describes severe impact, but the provided source material does not establish that every Casdoor deployment is equally exposed. Exploitability depends on enabled features, authentication flow configuration, IdP relationships, network reachability, and whether attackers can interact with the relevant interfaces.
Do not assume SAML impact if SAML is not enabled. Do not assume cross-organization privilege escalation if the deployment does not use the relevant token exchange pattern. Do not assume account takeover from email binding without checking how upstream providers issue and verify email claims.
Also do not minimize the issue because of those conditions. Conditional exposure is normal in IAM vulnerabilities. The right response is to reduce uncertainty quickly: find the instances, check the version, map the flows, patch where applicable, and review evidence of misuse.
The strongest supported judgment from VU#780781 is this: Casdoor deployments on affected versions deserve priority review if they act as a central login layer. When the identity control plane is wrong, downstream application controls may never get a fair chance.