Casdoor Authentication Bypass Flaws Undermine SAML, MFA, and Token Controls

This is not a story about one edge-case bug in a low-value feature. It is a story about an identity and access management product potentially accepting untrusted SAML material, letting users bypass MFA in specific flows, enabling cross-organization token problems, and failing to honor token revocation properly. When identity breaks, downstream security controls often inherit the failure.

Summary

According to CERT/CC, the Casdoor issues span three core trust areas: SAML processing, account binding and MFA enforcement, and token exchange logic. The published note says an attacker interacting with Casdoor's authentication interface may impersonate users, bypass multifactor authentication, forge and replay assertions, and achieve persistent unauthorized access. Those are extremely strong claims, but they are grounded in specific implementation issues described in the advisory.

The reviewed public source does not provide evidence of active exploitation, a vendor-authored fix, or a vendor statement confirming remediation status. That means defenders should avoid exaggeration. The right conclusion is not that every Casdoor deployment has already been compromised. The right conclusion is that an IAM system has multiple disclosed weaknesses in the exact places where defenders normally rely on strict trust validation.

Why the technical details matter

The first and most alarming cluster involves SAML trust handling. CERT/CC says CVE-2026-9090 allows authentication bypass by supplying an arbitrary signing certificate because Casdoor extracts the certificate from the incoming SAMLResponse instead of relying on the pre-configured trusted identity provider certificate. In plain terms, that means trust can be defined by attacker-supplied material rather than by administrator-controlled configuration.

CERT/CC also says Casdoor does not validate AudienceRestriction, does not enforce replay protection for assertions, does not enforce SAML assertion time bounds, and accepts unsolicited or replayed SAMLResponse data without verifying that it corresponds to an earlier AuthnRequest. Those are not independent trivia items. They all chip away at the same guarantee: that a received SAML assertion is intended for this service, for this session, at this time, and from a trusted party.

The second cluster affects identity binding and MFA. The advisory says one code path in social-login binding calls the logged-in handler directly without enforcing MFA, which becomes CVE-2026-9091. It also says CVE-2026-9092 can match users by email without verifying whether the upstream provider actually validated that email, creating account takeover risk when the same address exists locally. In a modern identity stack, that is dangerous because many organizations treat upstream identity claims as higher-assurance than they really are.

The third cluster affects token exchange and revocation. CERT/CC says Casdoor validates JWT signatures but fails to confirm the same-organization relationship for token exchange in CVE-2026-9094. It also says revoked or invalidated tokens may still be exchangeable because revocation status is not checked in CVE-2026-9097. That weakens both tenant isolation and incident response, because administrators may believe they have terminated a compromised session when they have not.

Why defenders should care now

Identity platforms sit in the middle of everything. If they fail open, or if they trust the wrong assertions or tokens, the blast radius can extend well beyond the IAM server itself. Attackers do not need to break every downstream app individually if they can convince the identity layer to issue or accept the wrong session.

Casdoor is also not just another login form. CERT/CC describes it as an IAM platform and MCP gateway that centralizes authentication, single sign-on, and multi-protocol identity services. That centrality increases defender urgency. A flaw in a line-of-business application can often be segmented. A flaw in the identity fabric is much harder to bound cleanly.

The advisory's "no patch yet available" posture in the reviewed source makes the situation more operationally difficult. Defenders may need to rely on compensating controls rather than a clean version upgrade in the immediate term.

Practical response guidance

Start by enumerating where Casdoor is used. Do not stop at the main login page. Identify SAML service-provider functions, social login binding paths, token exchange dependencies, organization scoping assumptions, and administrator or service accounts that depend on the platform.

If possible, temporarily restrict usage to only the identity providers you trust most and reduce optional federation paths until the remediation picture is clearer. Review whether downstream applications can enforce their own higher-assurance checks for privileged actions rather than assuming the upstream login event was sufficient.

High-privilege accounts deserve extra attention. If administrators rely on Casdoor-backed SSO and MFA, consider whether compensating controls exist outside Casdoor itself, such as downstream step-up authentication, separate admin entry points, or tighter IP-based restrictions. Also review SAML and token logs for unusual replay-like behavior, unexpected cross-tenant actions, or successful logins that do not line up with normal MFA expectations.

What remains unclear

Based on the reviewed public source, there is no confirmed evidence of in-the-wild exploitation, no vendor statement, and no published fixed version tied to these nine CVEs. That limited sourcing should shape how defenders talk about the issue. Do not claim mass compromise, but do not dismiss the advisory either.

The public facts already justify urgency: CERT/CC says Casdoor 2.362.0 and earlier have multiple flaws that can enable impersonation, MFA bypass, assertion forgery or replay, cross-organization privilege escalation, and unreliable token revocation. For an IAM platform, that is enough to demand immediate review.