Power-Pages-Datenleck: Was Ihr Kundenportal jetzt braucht

Eine Erpressergruppe hat nach eigenen Angaben Daten von 13 Organisationen erbeutet – nicht durch eine Sicherheitslücke in der Software, sondern durch eine Einstellung, die in jedem Low-Code-Portal falsch gesetzt sein kann. Wer selbst ein Kundenportal betreibt oder eines plant, sollte den Vorfall als Anlass nehmen, die eigene Konfiguration zu prüfen – unabhängig davon, welche Plattform dahintersteckt.

Was passiert ist

Die Gruppe ExfilSquad trat laut der Analyse von Fortra Intelligence and Research Experts (öffnet in neuem Tab) am 26. Juli 2026 erstmals mit einer eigenen Leak-Seite im Darknet auf und behauptete, Daten von 15 Organisationen erbeutet zu haben. Nach anfänglicher Skepsis veröffentlichte die Gruppe am 28. Juli und am 7. August Datenproben, die Fortra analysierte. Am 7. August stellte ExfilSquad vollständige Datensätze zu 13 der ursprünglich genannten Organisationen als Torrents bereit – laut Fortras Zeitachse insgesamt 382,64 Gigabyte und rund 27 Millionen Datensätze.

Cybersecurity Dive berichtet (öffnet in neuem Tab), dass zu den genannten Betroffenen unter anderem die Stadt Atlanta (rund 3 Millionen Datensätze), der Versicherer Allstate (657.000 Datensätze), das britische Bildungsministerium (600.000 Datensätze) und Frontier Airlines (2,4 Millionen Datensätze) zählen. Auch Microsoft selbst wird mit rund 8 Millionen Datensätzen als Betroffener genannt. Fortra fand keine Hinweise auf eine ausgenutzte Softwareschwachstelle, eine Verschlüsselung von Systemen oder eine seitliche Ausbreitung im Netzwerk, wie sie für klassische Ransomware-Angriffe typisch ist. Die Daten stammen den Analysten zufolge konsistent aus Exporten der Microsoft-Dataverse-Plattform, die hinter Dynamics-365-CRM- und -ERP-Umgebungen liegt.

Der eigentliche Fehler: eine Berechtigung, kein Bug

Als wahrscheinlichsten Zugangsweg identifiziert Fortra fehlkonfigurierte Power-Pages-Portale. Power Pages ist Microsofts Low-Code-Plattform, mit der Unternehmen öffentlich erreichbare Websites bauen, über die Kunden, Beschäftigte oder Partner Daten aus Dataverse einsehen oder eingeben können – klassische Anwendungsfälle sind Bestellstatus-Portale, Bewerberportale oder Serviceanfragen.

Der Mechanismus dahinter ist in der Sicherheitsdokumentation von Microsoft (öffnet in neuem Tab) klar beschrieben: Wird einer Dataverse-Tabelle die Rolle „Anonyme Benutzer" zugewiesen, kann jeder Besucher der Website die darin gespeicherten Daten lesen – auch über die Portal-API direkt, ohne die eigentliche Weboberfläche zu benutzen. Microsoft warnt in derselben Dokumentation ausdrücklich davor, diese Rolle auf öffentlich sichtbaren Seiten zu verwenden. Fortra identifizierte im Rahmen der eigenen Recherche mehr als 10.000 öffentlich erreichbare Power-Pages-Instanzen und geht davon aus, dass automatisiertes Scannen nach genau dieser Fehlkonfiguration – unter anderem mit dem frei verfügbaren Werkzeug „Power Pwn" – der naheliegende Weg zu den betroffenen Portalen war.

Der Unterschied zu einer klassischen Sicherheitslücke ist wichtig: Es gab kein Update zu installieren, keinen Patch, den jemand verpasst hat. Die Software funktionierte exakt wie konfiguriert – nur eben öffentlich lesbar, wo das nicht beabsichtigt war.

Warum das nicht nur ein Power-Pages-Problem ist

Wer selbst kein Power-Pages-Portal betreibt, ist deshalb nicht automatisch aus dem Schneider. Das Muster – ein Self-Service-Portal, das Kunden oder Mitarbeitenden Zugriff auf interne Geschäftsdaten gibt, mit einer Berechtigungsstufe, die weiter reicht als beabsichtigt – lässt sich auf jede Low-Code-Plattform und jedes selbst entwickelte Kundenportal übertragen. Wir haben an anderer Stelle beschrieben, worauf es beim Aufbau eines B2B-Kundenportals ankommt und wann No-Code-Ansätze und individuelle Entwicklung jeweils die passende Wahl sind – in beiden Fällen gilt: Je schneller ein Portal mit vorgefertigten Bausteinen entsteht, desto leichter übersieht man eine einzelne, aber folgenreiche Berechtigungseinstellung.

Drei Fragen lassen sich aus dem Vorfall ableiten, die für jedes bestehende Kundenportal gelten, unabhängig von der eingesetzten Technik:

• Ist wirklich nur sichtbar, was sichtbar sein soll? Nicht die Marketing-Startseite ist das Risiko, sondern die Tabellen und API-Endpunkte dahinter. Ein Portal sollte regelmäßig als nicht angemeldeter Besucher getestet werden – genau die Prüfung, die laut Fortra bei den betroffenen Organisationen unterblieben ist.
• Wer kennt den aktuellen Berechtigungsstand? Bei gewachsenen Portalen mit mehreren Rollen und Jahren an Änderungen verliert oft niemand mehr den vollständigen Überblick, welche Rolle auf welche Tabelle zugreifen darf.
• Was passiert bei einem Alarm? Fortra empfiehlt als Sofortmaßnahme für Betroffene, anonymen Zugriff auf Geschäftsdaten umgehend zu sperren, betroffene Zugangsdaten und API-Schlüssel auszutauschen und angebundene Dienste wie Power Automate, SharePoint oder Zahlungssysteme auf mögliche Mitbetroffenheit zu prüfen. Diese Liste lässt sich vorbereiten, bevor sie gebraucht wird.

Warum solche Fehlkonfigurationen jetzt schneller gefunden werden

Der Vorfall reiht sich in eine breitere Einschätzung der deutschen Sicherheitsbehörden ein. Anfang August 2026 teilte das Bundesamt für Verfassungsschutz dem Handelsblatt mit, dass Angriffe im großen Stil einfacher möglich würden und die Einstiegshürden durch den Einsatz von KI sänken (öffnet in neuem Tab). Auch das BSI rechnet laut derselben Quelle mit wachsendem Missbrauch: Die Modelle führender Anbieter hätten im vergangenen Jahr großes Potenzial beim automatisierten Auffinden von Schwachstellen gezeigt. Beide Behörden betonen zugleich, dass es sich nicht um eine neue, unabwehrbare Angriffsart handelt, sondern um eine Verschiebung im Kräfteverhältnis – mehr automatisiertes Scannen, nicht zwangsläufig raffiniertere Einzelangriffe.

Für ein Kundenportal bedeutet das praktisch: Eine öffentlich erreichbare, aber falsch konfigurierte Schnittstelle wird heute mit höherer Wahrscheinlichkeit automatisiert gefunden als noch vor zwei Jahren – unabhängig davon, ob ein Angreifer gezielt nach genau diesem Unternehmen sucht. Genau das illustriert der Power-Pages-Fall: Die über 10.000 von Fortra gefundenen offenen Instanzen wurden nicht einzeln recherchiert, sondern systematisch durchsucht.

Was sich daraus für die eigene Prüfung ableiten lässt

Ein vollständiges Sicherheitsaudit ersetzt dieser Beitrag nicht – dafür haben wir eine eigene Praxis-Checkliste für IT-Sicherheitsaudits im Mittelstand veröffentlicht. Speziell für Portale mit Kunden- oder Partnerzugriff sind aus dem aktuellen Vorfall aber drei sofort umsetzbare Schritte abzuleiten:

Erstens: jedes öffentlich erreichbare Portal einmal als anonymer, nicht angemeldeter Besucher aufrufen und testen, ob über die reguläre Oberfläche oder über direkte API-Aufrufe Daten sichtbar werden, die nicht für die Öffentlichkeit bestimmt sind. Zweitens: für jedes Portal dokumentieren, wer es betreibt, mit welchem Backend es verbunden ist und welche Rolle auf welche Datentabelle zugreifen darf – Fortra nennt genau diese fehlende Übersicht als typisches Muster bei den betroffenen Organisationen. Drittens: die Prüfung nicht als einmalige Aktion behandeln, sondern als wiederkehrenden Punkt bei jeder größeren Änderung am Portal, da sich Berechtigungen bei Erweiterungen erfahrungsgemäß leise verschieben.

Make-or-Buy ändert das Risiko, hebt es aber nicht auf

Ein naheliegender Reflex nach einem solchen Vorfall ist die Frage, ob eine Low-Code-Plattform wie Power Pages grundsätzlich riskanter ist als eine individuell entwickelte Lösung. Die Antwort ist differenzierter: Low-Code-Plattformen bündeln Berechtigungslogik in vorgefertigten Bausteinen, die schnell einsatzbereit sind, aber genau dadurch weniger offensichtlich machen, welche Voreinstellung was freigibt – die Rolle „Anonyme Benutzer" ist laut Microsofts eigener Dokumentation nur einen Klick von der produktiven Tabelle entfernt. Bei individuell entwickelter Software liegt die Berechtigungslogik dagegen vollständig in der Verantwortung des eigenen Entwicklungsteams; dort passieren andere Fehler, etwa fehlende Autorisierungsprüfungen in einer selbst geschriebenen API-Route, die im Code leicht übersehen werden. Keine der beiden Architekturen ist von Haus aus sicherer – entscheidend ist, ob jemand im Unternehmen die Berechtigungsstruktur tatsächlich versteht und regelmäßig prüft, unabhängig davon, ob sie in einer Low-Code-Oberfläche oder in eigenem Code steht.

Für Unternehmen, die aktuell zwischen einer Low-Code-Plattform und einer Eigenentwicklung für ihr Kundenportal abwägen, ist der Vorfall deshalb kein Argument gegen Low-Code an sich, sondern ein Argument dafür, die Sicherheitsprüfung als festen Bestandteil der Entscheidung mitzudenken – bei welcher Option auch immer am Ende ein Portal live geht.

Wenn Sie ein bestehendes Kundenportal betreiben oder eines planen und sich nicht sicher sind, ob die Berechtigungsstruktur trägt, sprechen wir gern unverbindlich darüber, wie sich das im eigenen Setup konkret prüfen lässt.