In der Low-Code-Werkstatt gibt es eine Sorte Schraube, die besonders freundlich aussieht: Zugriff geregelt, Rolle sortiert, Häkchen gesetzt. Dann greift jemand an die falsche Stelle, und plötzlich dreht sich die Berechtigung rückwärts durch die Maschine. Genau dort liegt die neue Mendix-Warnlampe.
CISA hat am 28. Juli 2026 die Siemens-Meldung ICSA-26-209-02 zu Mendix Runtime republiziert. Der Kern ist kein klassischer Speicherüberlauf mit Funkenflug, sondern ein Dokumentations- und Berechtigungsproblem rund um System.User: Entwickler können laut Advisory Zugriffsregeln so verstehen, dass Spezialisierungen enger wirken, als es die Plattformregeln tatsächlich zulassen.
Der Nutzer liegt in der falschen Schublade
Die Schwachstelle läuft unter CVE-2026-7891 und betrifft nach CISA/Siemens Mendix Runtime in allen Versionen. Beschrieben wird eine Lage, in der Access Rules für die System.User-Entität nicht ausreichend erklären, wie deren Sonderverhalten funktioniert. Ergebnis: Anwendungen können unbeabsichtigt zu freizügig werden, bis hin zur Offenlegung sensibler Nutzerdaten oder Privilegienausweitung.
Das klingt erst trocken. Ist es aber nicht. In der Werkstatt heißt das: Man schraubt an der Spezialschiene, glaubt, die Schublade sei zu, und darunter läuft noch ein Plattformförderband mit eigenem Willen. Besonders unangenehm ist der Fall, den CISA nennt: eine anonyme Benutzerrolle mit System.User-Spezialisierung kann Zugriff auf gespeicherte Datensätze bekommen, obwohl dort keine ausdrücklichen Rechte konfiguriert wurden.
CVSS 9.1, aber kein Patch-Hammer
Die Bewertung ist mit CVSS 3.1: 9.1 Critical deutlich. Trotzdem empfiehlt Siemens keinen simplen „Version hoch, Problem weg“-Knopfdruck. Die Maßnahme sitzt in der Anwendungskonfiguration: Security-Modelle, die allein auf XPath-Beschränkungen einer System.User-Spezialisierung beruhen, sollen überarbeitet werden. Einschränkungen gehören auf die App-Security-Rollenverwaltungsebene, nicht nur an die Spezialisierungszierleiste.
Mendix verweist ebenfalls auf die Sicherheitsmeldung und auf aktualisierte Dokumentation. Für Betreiber heißt das: Nicht nur nach Versionen fragen, sondern nach Modellen. Welche Apps verwenden System.User-Spezialisierungen? Wo gibt es anonyme Rollen? Welche XPath-Regel gilt als Schutz, obwohl sie gegen eingebaute Plattformregeln nicht so zieht, wie der Schraubenschlüssel behauptet?
Low-Code ist trotzdem Code, nur mit Blechgriff
Die Blechpresse notiert das als bekannte Lehre mit neuem Rostrand: Low-Code nimmt Arbeit aus dem Quelltext, aber nicht aus dem Sicherheitsmodell. Rollen, Vererbung, Plattformobjekte und implizite Regeln bleiben echte Mechanik. Wenn die Dokumentation dort neblig wird, läuft keine hübsche Oberfläche, sondern eine Berechtigungspresse mit schlechter Sicht.
Der pragmatische Ablauf ist also nicht Panik, sondern Inventur: betroffene Mendix-Apps finden, System.User-Nutzung prüfen, anonyme Rollen gesondert anschauen, Zugriffstests machen, Dokumentation gegen die neue Siemens/Mendix-Lage lesen und die Einschränkungen dort setzen, wo die Plattform sie tatsächlich durchsetzt. Danach darf die Schraube wieder vorwärts drehen. Unter Aufsicht.