Kurzfassung

Casdoor bis einschließlich Version 4.4.0 weist mit CVE-2026-91998 eine kritische Autorisierungsumgehung auf. Die Schwachstelle hat einen CVSS-Wert von 9.4 und ermöglicht Angreifern mit gültigen Zugangsdaten einer beliebigen Anwendung weitreichenden Zugriff auf die Benutzerverwaltung über alle Organisationen hinweg. Für Unternehmen, die Casdoor mandantenübergreifend oder als zentrale Identitätskomponente einsetzen, ist das hochrelevant und sollte umgehend geprüft werden.

Was ist passiert?

Betroffen ist der Endpunkt /api/mcp in Casdoor. Dort lässt sich die Autorisierung so umgehen, dass ein Angreifer mit der clientId und dem clientSecret einer einzelnen legitimen Anwendung nicht nur auf deren eigenen Bereich zugreifen kann, sondern auf Benutzerdaten und Verwaltungsfunktionen in allen Organisationen.

Das Risiko geht damit deutlich über reine Informationsabflüsse hinaus. Laut NVD können Angreifer Benutzerkonten auflisten, E-Mail-Adressen und Passwort-Salts auslesen, Administrator-Konten anlegen, bestehende Nutzer verändern und Benutzer in beliebigen Organisationen löschen.

Technische Details

CVE-2026-91998 ist eine Autorisierungsumgehung in Casdoor bis 4.4.0 am Endpunkt /api/mcp. Der CVSS-Basiswert liegt bei 9.4 von 10 Punkten nach CVSS 4.0 und beschreibt damit eine sehr hohe technische Schwere, nicht automatisch eine bereits beobachtete Ausnutzung in freier Wildbahn.

Der Vektor CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H bedeutet: Der Angriff ist über das Netzwerk möglich, die Angriffskomplexität ist gering, es sind lediglich niedrige Berechtigungen erforderlich, und eine Nutzerinteraktion ist nicht nötig. In der Praxis reicht also offenbar ein gültiges Anwendungspaar aus clientId und clientSecret, um mandantenübergreifend Benutzerverwaltung zu missbrauchen.

Besonders kritisch ist die Kombination aus Vertraulichkeits-, Integritäts- und Verfügbarkeitsfolgen. Wenn Angreifer Benutzerkonten erstellen, ändern und löschen können, wird aus einem Identitätsdienst schnell ein Ausgangspunkt für weitere Kompromittierungen in nachgelagerten Systemen.

Wer ist betroffen?

Betroffen ist Casdoor bis einschließlich Version 4.4.0. Ob neuere Versionen bereits abgesichert sind, geht aus den verfügbaren Angaben hier nicht hervor.

Besonders genau hinsehen sollten Unternehmen im DACH-Raum, wenn Casdoor als zentrale Authentifizierungs- oder Identitätsplattform dient, mehrere Organisationen oder Mandanten abbildet oder wenn viele interne Anwendungen ihre Zugangsdaten dort hinterlegt haben. In solchen Umgebungen kann ein einzelnes kompromittiertes Anwendungspaar genügen, um deutlich größere Teile der Benutzerverwaltung zu übernehmen.

Weniger relevant ist der Fall für Umgebungen, in denen Casdoor zwar testweise läuft, aber weder produktive Nutzer noch organisationsübergreifende Trennung abbildet. Selbst dort bleibt die Schwachstelle ernst, weil Zugangsdaten aus Testsystemen oft wiederverwendet oder unzureichend geschützt werden.

Empfohlene Maßnahmen

1. Prüfen Sie sofort, ob Casdoor in Version 4.4.0 oder älter im Einsatz ist. Inventarisieren Sie dabei auch Staging-, Test- und Schatteninstanzen.

2. Begrenzen Sie kurzfristig den Zugriff auf Casdoor, falls das System aus dem Internet oder aus breiten internen Netzen erreichbar ist. Wo möglich, sollten nur vertrauenswürdige Administrationsnetze oder vorgeschaltete Zugriffskontrollen den Dienst erreichen.

3. Behandeln Sie alle in Casdoor hinterlegten clientId– und clientSecret-Paare als potenziell kritisch. Rotieren Sie diese Zugangsdaten priorisiert, vor allem für Anwendungen mit weiter Verbreitung oder hoher Berechtigung.

4. Prüfen Sie die Benutzerverwaltung auf Auffälligkeiten: neu angelegte Administratoren, geänderte Benutzerattribute, gelöschte Konten und ungewöhnliche Abfragen über Organisationsgrenzen hinweg. Wenn Protokolle vorhanden sind, sollten Anfragen an /api/mcp gezielt ausgewertet werden.

5. Trennen Sie betroffene Instanzen, wenn ein Missbrauchsverdacht besteht. Gerade bei zentralen Identitätsdiensten ist eine saubere Eingrenzung wichtiger als ein rein kosmetisches Weiterbetreiben.

6. Falls bereits Zugangsdaten einer Anwendung abgeflossen sein könnten, bewerten Sie Folgerisiken in angebundenen Diensten mit. Über manipulierte Benutzerkonten können weitere Systeme betroffen sein, selbst wenn diese selbst nicht verwundbar sind.

Ob ein Patch bereitsteht, ist hier nicht mitgeteilt.

Einschätzung von CyberSecurity-News.de

Die technische Tragweite ist erheblich, weil hier kein isolierter Fehler in einer Nebenfunktion beschrieben wird, sondern eine Schwäche an der Grenze zwischen Anwendung und Mandantentrennung. Wer Casdoor produktiv als Identitätsbaustein nutzt, sollte das nicht als gewöhnliche API-Schwachstelle abtun.

Die Informationslage ist derzeit knapp. NVD nennt Schweregrad, betroffene Versionen und die möglichen Auswirkungen, aber keine Angaben zu behobenen Releases, Workarounds oder bereits beobachteter Ausnutzung. Das erschwert die Priorisierung nicht grundsätzlich, erhöht aber den Druck auf Betreiber, selbst zügig zu prüfen und Zugangsdaten zu rotieren.

Für viele kleinere Umgebungen ohne produktive Mehrmandantenstruktur dürfte das Risiko beherrschbarer sein als in großen, zentralisierten Identity-Setups. In Unternehmen mit mehreren Organisationen, extern angebundenen Anwendungen oder automatisierter Benutzerverwaltung ist die Lücke dagegen klar prioritätswürdig.

Fazit

Wenn Sie Casdoor bis 4.4.0 einsetzen, sollten Sie den Dienst kurzfristig als potenziell kompromittierbar einstufen. Priorität haben Versionsprüfung, Zugangsbeschränkung, Rotation von Anwendungsschlüsseln und die Kontrolle auf unberechtigte Änderungen in der Benutzerverwaltung.

Quellenangabe

Weiterführende technische Informationen bietet der NVD-Eintrag zu CVE-2026-91998.