Erneuerbare Energien

Fremde Wechselrichterdaten waren für ein Konto sichtbar – die iSolarCloud-Lücke ist behoben

Die iSolarCloud-Lücke erlaubte einem Konto den Empfang fremder Wechselrichterdaten. Sie ist laut DIVD und Sungrow seit Juni 2025 behoben.

Von Wolfgang

29. Aug. 20266 Min. Lesezeit

Fremde Wechselrichterdaten waren für ein Konto sichtbar – die iSolarCloud-Lücke ist behoben

Die iSolarCloud-Lücke erlaubte einem Konto den Empfang fremder Wechselrichterdaten. Sie ist laut DIVD und Sungrow seit Juni 2025 behoben.

Ein angemeldetes Konto konnte Daten anderer Wechselrichter empfangen. Das ist der Kern einer inzwischen behobenen Schwachstelle im Sungrow-Portal iSolarCloud. Der Befund betrifft keinen aktuellen Angriff und auch keine nachgewiesene Fernsteuerung von Anlagen. Er zeigt aber, wie sehr der sichere Betrieb einer PV-Anlage inzwischen von Cloud-Zugängen und sauber gesetzten Berechtigungen abhängt.

Der niederländische Sicherheitsforschungsverband DIVD hat am 19. August 2026 technische Details zu CVE-2025-29756 veröffentlicht. Nach dessen Untersuchung konnte ein iSolarCloud-Konto vor der Behebung MQTT-Nachrichten anderer angeschlossener Sungrow-Wechselrichter abonnieren, empfangen und entschlüsseln. MQTT ist ein leichtgewichtiges Nachrichtenprotokoll, das Geräte und Cloud-Dienste miteinander verbindet. Genau dort fehlte die ausreichende Trennung zwischen den Konten.

TechZeitGeist-Status

Reifegrad des Befunds
Historische, koordinierte Sicherheitslücke; technische Details wurden im August 2026 offengelegt.
Beleglage
DIVD-Dokumentation, CVE- und Fallseite, NVD-Registry sowie Sungrows Sicherheitsinformation.
Praxisrelevanz
Betroffen war der Cloud-Pfad eines Solarportals, nicht der Wechselrichter als isoliertes Gerät.
Offener Kernpunkt
Für welche heutigen Produkt- und Kontokonfigurationen die Zugriffstrennung konkret dokumentiert ist, geht aus dem Dossier nicht hervor.
Nächster Nachweis
Eine aktuelle, nachvollziehbar dokumentierte Prüfung der Zugriffsrechte für Portal, App und betroffene Konfigurationen.

Die Lücke war geschlossen, bevor die Details veröffentlicht wurden

Die zeitliche Reihenfolge ist wichtig. DIVD und Sungrow ordnen die technische Behebung dem Juni 2025 zu. Die DIVD-Fallchronik nennt den 6. Juni, die CVE-Abgrenzung und Sungrows Hinweis verweisen auf den 7. Juni. Deshalb bleibt die belastbare Formulierung: Die Lücke wurde im Juni 2025 behoben. Die Veröffentlichung vom 19. August 2026 machte den historischen Befund öffentlich; sie ist nicht das Datum eines neuen Patches.

Auch die stärkste Gegenposition gehört dazu: In den vorliegenden Quellen ist keine Ausnutzung in freier Wildbahn dokumentiert. DIVD und Sungrow schreiben zudem, dass keine allgemeine Kundenaktion nötig sei. Das ist eine koordinierte und eine Herstellerangabe, kein unabhängiges Audit jeder installierten Anlage, App oder Kontokonfiguration. Es gibt aber keinen Anlass, aus der Offenlegung einen aktuellen Notfall für alle Sungrow-Besitzer zu machen.

Der Fehler lag bei den Berechtigungen, nicht bei der Verschlüsselung

Der technische Ablauf lässt sich ohne Exploit-Anleitung auf fünf Schritte reduzieren. Das iSolarCloud-Webportal rief über eine Schnittstelle den MQTT-Endpunkt und Zugangsdaten ab. Diese Informationen wurden im JavaScript des Browsers verarbeitet. Laut DIVD ließen sich dabei Zugangsdaten und ein RSA-Schlüssel im Browser-Kontext sichtbar machen.

Das bedeutet nicht, dass jemand einen Verschlüsselungsalgorithmus gebrochen hätte. Ein Client muss Schlüsselmaterial verarbeiten können, wenn er verschlüsselte Nachrichten lesen soll. Entscheidend war etwas anderes: Der MQTT-Broker begrenzte die abonnierbaren Topics nicht ausreichend auf das jeweilige Konto. Topics sind die Adressen oder Themenkanäle, über die MQTT-Nachrichten verteilt werden. Ein angemeldetes Konto konnte dadurch Nachrichten anderer angeschlossener Wechselrichter empfangen und entschlüsseln.

Originalgrafik zeigt die historische Zugriffskette von Webportal und API über Browser und MQTT-Broker bis zu fremden Wechselrichterdaten
Die Prozessgrafik trennt Browser-Kontext, Broker-Autorisierung, fremde Daten und die nicht verifizierte Steuerungshypothese. – durch KI erzeugt

Die redaktionelle Prozessmatrix macht den Unterschied sichtbar: Browser und API lieferten die nötigen Zugangsinformationen, der Broker trennte die Datenkanäle nicht sauber genug, und erst daraus entstand der Zugriff auf fremde Metadaten. Die mögliche Steuerung fremder Wechselrichter ist davon getrennt zu betrachten. DIVD vermutete, dass ähnlich geschützte Steuerbefehle ebenfalls andere Geräte erreichen könnten, testete das aber ausdrücklich nicht, um Schäden oder Nebenwirkungen zu vermeiden. Von einer bestätigten Fernsteuerung kann deshalb keine Rede sein.

400 MW in 20 Sekunden sind keine Schadenssumme

DIVD summierte in einer 20-Sekunden-Beobachtung die Produktionsleistung der empfangenen MQTT-Nachrichten auf mehr als 400 MW. Die Zahl zeigt, dass in solchen Datenströmen relevante Informationen zusammenlaufen können. Sie sagt jedoch nicht, wie viele Anlagen insgesamt betroffen waren, ob Anlagen abgeschaltet wurden oder ob es eine Netzstörung gab. Für diese Aussagen fehlt im Dossier jeder Nachweis.

Auch die technischen Bewertungen sind differenzierter, als eine einzelne Zahl nahelegt. DIVD bewertet den dokumentierten Read-only-Fall als CNA mit einem CVSS-Wert von 8,3. Die NVD weist diesen CNA-Wert aus, hat für CVSS 4.0 aber keine eigene NVD-Bewertung bereitgestellt. DIVD nennt 9,0 für einen hypothetischen Befehlsfall, Sungrow zeigt 8,4. CVSS beschreibt technische Auswirkungen unter bestimmten Annahmen; es ist keine Wahrscheinlichkeit für einen Angriff auf eine konkrete Anlage und keine Messung des heutigen Risikos.

Warum der Fall über ein einzelnes Portal hinausweist

Wechselrichter sind längst nicht mehr nur Leistungselektronik am Hausanschluss. Die Internationale Energieagentur beschreibt sie als Steuer- und Kommunikationspunkte in PV-, Batterie- und modernen Windanlagen. Mit Apps, Fernwartung und Cloud-Portalen wächst damit eine zweite Betriebsebene: Wer sieht Daten, wer darf Einstellungen ändern, wie werden Updates verteilt und wie wird ein Sicherheitsvorfall erklärt?

Der Cyber Resilience Act der EU setzt für Produkte mit digitalen Elementen einen Rahmen für sichere Entwicklung, Wartung und Updates. Laut EU-Kommission gelten Meldepflichten ab dem 11. September 2026, die Hauptpflichten ab dem 11. Dezember 2027. Das ändert den historischen Patchstatus bei iSolarCloud nicht und ersetzt keine Einzelfallprüfung. Es macht aber deutlich, warum Sicherheitsfragen über den gesamten Produktlebenszyklus gehören.

Originalgrafik trennt die Behebung im Juni 2025 von der DIVD-Offenlegung im August 2026 sowie die 20-Sekunden-Messung
Die Evidenzgrafik hält Patchzeitpunkt, spätere Offenlegung, 400-MW-Beobachtung und offene Steuerungsfrage auseinander. – durch KI erzeugt

Worauf Betreiber bei Cloud-Anlagen achten können

Für private Besitzer, Installateure und kleinere Gewerbebetriebe folgt daraus keine Aufforderung, Anlagen pauschal abzuschalten oder zurückzusetzen. Sinnvoll ist eine nüchterne Bestandsaufnahme: Portal-, App- und Firmwarestand dokumentieren, nicht benötigte Kontozugänge vermeiden und festlegen, wer Updates sowie Fernzugriffe verantwortet. Bei gewerblich betriebenen Anlagen gehört auch ein klarer Kontaktweg zum Hersteller oder Dienstleister dazu.

Die NIST-Leitlinien für kleine Solarwechselrichter richten sich ebenfalls an Eigentümer, Installateure und kleine Unternehmen. Sie sind US-amerikanische technische Orientierung, kein Sungrow-Audit und kein EU-Recht. Ihr praktischer Gedanke passt dennoch: Sicherheitszustand und Zuständigkeit sollten sich im Betrieb nachvollziehen lassen, statt erst nach einer Offenlegung gesucht zu werden.

Der offene Punkt liegt in der heutigen Nachweisbarkeit

Die DIVD-Offenlegung beschreibt eine konkrete historische Zugriffslücke und die Quellen nennen ihre Behebung. Offen bleibt, wie Betreiber heute für ihre jeweilige Portal-, App- und Firmwarekonfiguration nachvollziehen können, dass Zugriffsrechte sauber getrennt sind. Eine aktuelle unabhängige oder herstellerseitig nachvollziehbar dokumentierte Prüfung wäre dafür aussagekräftiger als eine allgemeine Entwarnung.

Der Fall ist deshalb weder eine Blackout-Geschichte noch ein Grund, die Cloud-Anbindung jeder Solaranlage zu verteufeln. Er erinnert daran, dass Datenzugriff, mögliche Steuerbarkeit und ein tatsächlicher Schaden unterschiedliche Dinge sind. Bei vernetzten Energieanlagen gehört die Frage nach Berechtigungen und Updates inzwischen zur normalen Betriebsqualität.

Quellen und weiterführende Informationen

Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-08-29.