Casdoor v2.95.0 CSRF: Unintended Password Changes

On 2025-10-23 a Cross-Site Request Forgery (CSRF) weakness was reported in Casdoor v2.95.0 (release date 2025-10-22). The vulnerable endpoint (/api/set-password) could be invoked in the context of an authenticated user to change that user’s password without requiring the user’s current password. The issue is referenced as CVE-2023-34927 in the report (note: the listing or assignment may still be finalized).

Put plainly: if a user is logged into a Casdoor instance and later visits a malicious page or link, that page can submit a request which changes the victim’s password, enabling account takeover or the creation of an account with attacker-chosen credentials.

Why this matters

1. Password changes that don’t require the user’s current password are high impact when combined with CSRF.
2. Many admins and service accounts use meaningful names (e.g., admin or built-in); if such identities are targeted, the attacker can gain persistent access.
3. Because Casdoor is an identity provider, compromise can cascade to services that trust it (SSO sessions, integrated apps).

Affected versions

1. Confirmed: Casdoor v2.95.0 and earlier (per the report).
2. Any publicly reachable Casdoor instance running an affected release is at risk.

What an attacker can do

1. Force a logged-in user to have their password changed, then log in as that user.
2. Create or alter accounts if the endpoint accepts parameters enabling that behavior.
3. Pivot from a compromised application account into systems that rely on Casdoor for authentication (SSO integrations).

Detection — what to look for

1. Unexpected POST requests to /api/set-password in access logs where the Referer header comes from an external origin.
2. Rapid or unexplained password change events for admin/service accounts.
3. New logins from unfamiliar IPs immediately after a password-change event.
4. Web server logs showing form submissions or requests to /api/set-password without corresponding UI flows in your monitoring/telemetry.
5. Unexpected account creations or modifications around the same time window.

Immediate mitigation (short term)

If you cannot patch immediately, apply one or more of these mitigations right away:

1. Require current password for password changes — change server logic so /api/set-password only accepts requests that include the account’s existing password (or a valid token from a prior verified flow).
2. Enable/require CSRF protection — validate a per-session CSRF token on all state-changing endpoints.
3. Set cookies to SameSite=Strict or Lax where appropriate to reduce cross-site POSTs.
4. Restrict access to the admin API — firewall rules, IP allow-lists, or placing Casdoor behind a VPN for administrative interfaces.
5. Short-term ACL — if possible, restrict /api/set-password to authenticated API clients (e.g., require an Authorization header signed by the client).
6. Enable MFA for privileged accounts so password changes alone are not sufficient to take over sensitive accounts.
7. Invite user action — force a password reset for high-risk or admin accounts and notify owners of the incident.

Long-term fixes (recommended)

1. Enforce CSRF tokens across all POST, PUT, DELETE endpoints and validate origin/host headers where possible.
2. Require proof of knowledge (current password) or out-of-band confirmation (email/SMS) for sensitive account changes.
3. Harden session management (shorter session lifetimes, detect anomalous session usage).
4. Add explicit headers checks (Origin/Referer) logic as part of CSRF mitigation — but don’t rely on them as the only control.
5. Add automated behavioral alerts for “password change followed by login from new IP” events.

Incident response checklist (if you suspect exploitation)

1. Identify affected accounts and immediately reset credentials for high-privilege accounts.
2. Check logs for suspicious requests to /api/set-password and follow the access trail (timestamps, IPs, user agents).
3. Force logout of user sessions and rotate any API tokens or client secrets that may have been exposed.
4. Enable MFA and require re-verification for administrative users.
5. Restore from backups only if you detect further malicious persistence (webshells, modified binaries).
6. Notify impacted users and stakeholders with remediation steps (change passwords, review sessions).
7. Patch the application and any dependent libraries; validate the patch in a staging environment before full rollout.

More: https://www.exploit-db.com/exploits/52439