Casdoor CVE-2026-9091

The social-login (OAuth/OIDC social identity provider binding) feature must be enabled on the Casdoor instance, as the flaw exists specifically in the binding-rule code path in controllers/auth.go - instances with social login disabled are not exposed to this attack vector. Exploitation additionally requires the attacker to possess or control a social identity provider account that is already bound, or can be bound, to a Casdoor user account that has MFA configured - accounts without MFA enforcement are unaffected because no bypass of a non-existent control occurs. The CVSS vector (PR:N/AC:L/UI:N) confirms unauthenticated remote exploitation with no user interaction required once these preconditions are met. Limiting factors for defenders: social login must be enabled (non-default in hardened deployments), the attacker must have or obtain a valid IdP credential linkable to a target account, and only MFA-protected accounts are meaningfully impacted by the bypass.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) scores 5.3 Medium, indicating fully remote, low-complexity, unauthenticated exploitation with no user interaction - but scoped impact limited to partial confidentiality. The low impact score reflects that the direct outcome is unauthorized session access rather than full system compromise; however, the strategic value of MFA bypass is significantly higher than CVSS alone conveys, as it dismantles a primary compensating control for accounts that may hold elevated privileges. EPSS at 0.02% (5th percentile) and SSVC exploitation status of 'none' confirm no observed exploitation activity. The critical tension in this assessment: SSVC also flags Automatable:yes, meaning the social-login endpoint can be targeted programmatically at scale once an attacker holds a linkable IdP credential - raising real-world risk above what EPSS suggests for targeted deployments. This vulnerability is not in CISA KEV and no POC is known, so the present risk is primarily to organizations that treat MFA as a hard compliance or access-control requirement for privileged Casdoor accounts.

An attacker who controls or can register a social identity provider account (e.g., a GitHub or Google OAuth account) that is bound or bindable to a target Casdoor user account initiates authentication through the social-login binding endpoint. Because controllers/auth.go skips the MFA enforcement check in this code path, the attacker receives a fully authenticated Casdoor session for the target user without completing - or even being prompted for - the configured second factor. No public exploit code is known, but the attack requires only standard OAuth flow interaction against the Casdoor social-login endpoint, making it automatable against any externally accessible instance.