[English]Sicherheitsforscher von Check Point haben eine schwerwiegende Sicherheitslücke im KI-Entwickler-Tool Cursor gefunden. Die von Check Point als MCPoison bezeichnete Schwachstelle (CVE-2025-54136) ermöglicht Angreifern über das MCP-System von Cursor, schädlichen Code in die Projekte der Nutzer einzuschleusen. Das ist ein Paradebeispiel für neuartige Lieferketten-Angriffe in KI-gestützten Entwickler-Umgebungen.

Check Point Research (CPR) hat eine kritische Schwachstelle im KI-basierten Coding-Tool Cursor entdeckt, die es Hackern erlaubt, dauerhaft Remote-Code auszuführen. CPR kam der Schwachstelle (CVE-2025-54136) bei der Untersuchung von Sicherheitsmodellen innerhalb von MCP-Systemen KI-unterstützter Coding-Tools auf die Schliche. Die Sicherheitslücke betrifft das Model Context Protocol (MCP) von Cursor und kann zur wiederholten Einschleusung von schädlichem Code missbraucht werden. 

Was ist Cursor?

Bei Cursor handelt es sich um eine IDE (Integrierte Entwicklungsumgebung), die eines der am schnellsten wachsenden KI-gestützten Coding-Tools ist. Cursor kombiniert die lokale Code-Bearbeitung mit leistungsstarken LLM-Integrationen, um Teams beim Schreiben, Debuggen und Durchsuchen von Code zu helfen. Aufgrund seiner Flexibilität wird Cursor zunehmend von Startups, Forschergruppen und einzelnen Entwicklern eingesetzt, die KI-Tools direkt in ihre Entwicklung integrieren möchten.

Die zunehmende Beliebtheit hat CPR veranlasst, sich das Sicherheitsmodell hinter diesen Tools genauer anzuschauen. In das Blickfeld der Untersuchung geriet das MCP-System von Cursor. Dabei handelt es sich um Konfigurationsdateien, die Cursor mitteilen, wie bestimmte Aufgaben zu automatisieren sind. Entwickler können über diese Funktion verschiedene Tools, Skripte oder KI-gesteuerte Workflows direkt in ihre Programmierumgebung einbinden.

CPR untersuchte, ob Cursor Code-Änderungen innerhalb von MCP angemessen berücksichtigt. Bei der kollaborativen Entwicklung kommen Bearbeitungen häufig vor und jede Lücke in der Validierung kann zu Befehlsinjektionen, Code-Ausführung oder dauerhaften Kompromittierungen führen.

Wie die Sicherheitslücke funktioniert

Wenn ein Benutzer ein Projekt öffnet, das eine MCP-Konfiguration enthält, zeigt Cursor eine einmalige Genehmigungsaufforderung an, in der gefragt wird, ob der Nutzer der Konfiguration vertraut. Doch hier liegt das Problem: Sobald ein MCP genehmigt ist, wird er von Cursor nie wieder überprüft, selbst wenn die darin enthaltenen Befehle später stillschweigend geändert werden.

Das bedeutet, dass ein Angreifer, der mit demselben gemeinsamen Repository arbeitet, eine sicher erscheinende MCP-Konfiguration zu einem Projekt hinzufügen und dann darauf warten kann, dass jemand anderes aus dem Team sie abruft. Diese Konfiguration kann er später für bösartige Zwecke nutzen, zum Beispiel, um ein Skript zu starten, eine Hintertür zu öffnen oder Daten an einen externen Server zu senden. Jedes Mal, wenn das Opfer das Projekt in Cursor öffnet, wird der neue Befehl automatisch ausgeführt, ohne eine neue Eingabeaufforderung oder Warnung auftauchen zu lassen.

CheckPoint hat die technischen Einzelheiten und ein Demo-Video des Angriffs in diesem Artikel veröffentlicht. 

Warum die Sicherheitslücke gefährlich ist

CPR fand genau das: eine schwerwiegende Schwachstelle im MCP-System von Cursor, die eine dauerhafte Remotecode-Ausführung (RCE) ermöglicht. Sobald ein Benutzer eine MCP-Konfiguration genehmigt hat, kann ein Angreifer deren Verhalten unbemerkt ändern. Von diesem Moment an können bösartige Befehle jedes Mal ausgeführt werden, wenn das jeweilige Projekt ohne weitere Aufforderungen oder Benachrichtigungen geöffnet wird. Ein Angreifer kann in diesem Fall:

• eine harmlos aussehende MCP-Konfiguration zu einem freigegebenen Repository hinzufügen.
• warten, bis das Opfer den Code abruft und ihn einmal in Cursor IDE freigibt.
• die MCP-Konfiguration durch eine bösartige Nutzlast ersetzen.
• jedes Mal, wenn das Opfer Cursor öffnet, unbemerkt und dauerhaft Code ausführen.

In gemeinsam genutzten Programmierumgebungen verwandelt die Schwachstelle einen vertrauenswürdigen MCP in einen versteckten, kontinuierlichen Angriffspunkt. Für Unternehmen, die sich auf KI-Tools wie Cursor verlassen, hat dies schwerwiegende Folgen: unbemerkter, ständiger Zugriff auf Entwicklerrechner, Anmeldedaten und Code-Fundamente, ausgelöst durch eine einzige Genehmigung.

Auswirkungen in der realen Welt

Da in vielen Unternehmen Projekte über Repositories gemeinsam genutzt und synchronisiert werden, bietet diese Schwachstelle Angreifern eine ideale Möglichkeit, langfristig und unbemerkt Fuß zu fassen.

• Das macht die Schwachstelle gefährlich: Es gibt ein stilles Fortbestehen von bösartigem Code- Jedes Mal, wenn ein Nutzer das Projekt öffnet, wird (bösartiger) Code ausgeführt, ohne eine Benachrichtigung der Benutzer oder das Erfordern weiterer Genehmigungen. Das bedeutet, dass Angreifer auf unbestimmte Zeit Zugriff auf das Projekt erhalten können.
• Große Angriffsfläche: Jeder Entwickler mit Schreibzugriff auf ein gemeinsam genutztes Repository kann diese vertrauenswürdige MCP-Konfiguration einspeisen und ändern, wodurch ganze Teams und Organisationen gefährdet werden.
• Risiken der Privilegien-Eskalation: Auf den Rechnern von Entwicklern sind häufig sensible Anmeldedaten, Cloud-Zugangsschlüssel oder andere sensible Informationen lokal gespeichert. Ein Angreifer, der diese Schwachstelle ausnutzt, kann den Zugriff auf Unternehmensnetzwerke erweitern.
• Offenlegung von Daten und Code: Neben der direkten Ausführung von Code könnten Angreifer unbemerkt Quellcode, geistiges Eigentum oder interne Kommunikation ausspähen.
• Vertrauen in KI-Tools wird untergraben: Da KI-Tools wie Cursor immer stärker in die Software-Entwicklung integriert werden, muss ihr Sicherheitsmodell hieb- und stichfest sein. Diese Schwachstelle verdeutlicht die Gefahren von blindem Vertrauen in automatisierte Arbeitsabläufe.

Für Unternehmen, die sich auf Cursor und ähnliche KI-gestützte IDEs verlassen, ist das Verständnis und die Behebung dieser Schwachstelle entscheidend für den Schutz ihrer Entwicklungsumgebungen und sensiblen Ressourcen.

Um Schwachstelle in KI-gestützten Entwicklungsumgebungen zu entschärfen, empfiehlt CPR:

• MCP-Konfigurationsdateien als Angriffsfläche behandeln: Genau wie der Quellcode sollten auch Automatisierungsskripte und MCP-Konfigurationsdefinitionen sorgfältig geprüft, auditiert und über Versionen kontrolliert werden.
• Implizites Vertrauen in KI-gesteuerte Automatisierungen vermeiden: Auch dann, wenn ein MCP oder ein Vorschlag harmlos aussieht, sollten Nutzer sicherstellen, dass alle Team-Mitglieder verstehen, was dieser tut, bevor man ihn genehmigt.
• Schreibrechte in kollaborativen Umgebungen einschränken: Sicherheitsverantwortliche sollten kontrollieren, wer vertrauenswürdige Konfigurationsdateien ändern darf, insbesondere in gemeinsam genutzten Repositories.

„KI-gestützte Entwickler-Tools verändern die Software-Entwicklung, schaffen aber auch neue Angriffsflächen, die das Vertrauen der Entwickler ausnutzen wollen”, so Oded Vanunu, Chief Technologist & Head of Product Vulnerability Research bei Check Point Software Technologies: „MCPoison zeigt, wie einfach Automatisierung und Komfort für heimliche, langfristige Ausbeutung in kollaborativen Programmierumgebungen missbraucht werden können.”

Verantwortungsvolle Offenlegung und Entschärfung

Nach der Entdeckung dieser Schwachstelle hat Check Point Research das Cursor-Entwickler-Team am 16. Juli 2025 verantwortungsbewusst über das Problem informiert. Cursor veröffentlichte am 30. Juli 2025 einen Fix.

Weitere Informationen finden sich im Beitrag Cursor IDE: Persistent Code Execution via MCP Trust Bypass im CPR-Blog.

Mal ein Thema abseits der IT, was aber Berührungspunkte mit der IT bekommt. Derzeit träumen in den USA ja die KI-Anbieter davon, den von den Modellen erzeugten Stromhunger mittels Atomkraftwerken zu stillen. Neue Reaktortypen sollen her. Dabei ist gänzlich ungeklärt, was mit Reaktorabfällen passiert. Gerade hat man auf dem Gelände einer stillgelegten Atomanlage, die als Abfalllager für radioaktive Abfälle dient, radioaktive Wespennester gefunden.

Ich bin auf Mastodon durch Zufall auf die betreffende Information gestoßen. Slashdot hat die Zusammenfassung des Sachverhalts in diesem Artikel gepostet.

Radioaktive Wespennester auf Gelände von Atomanlage

Die Washington Post berichtete Anfang Juli 2025, dass Anfang Juli 2025 auf dem Gelände einer aufgegebenen, weitläufigen Atomanlage aus der Zeit des Kalten Krieges in South Carolina ein “radioaktives” Wespennest gefunden wurde. Das Wespennest weist eine Strahlenbelastung auf, die zehnmal so hoch wie nach den US-Bundesvorschriften zulässig ist.

Letzten Freitag (1. August 2025) gaben Bundesbeamte den Fund von mindestens drei weitere kontaminierte Wespennester auf dem Gelände bekannt. Das 310 Quadratmeilen (ca. 500 Quadratkilometer) große Gelände der Savannah River Site wird heute teilweise als Lagerstätte für radioaktive Flüssigabfälle genutzt. Das Gelände ist mehr als viermal so groß ist wie der US District of Columbia mit der Hauptstadt Washington.

Keine unmittelbare Gefahr

Laut Behörden droht keine akute Gefahr, die Funde stellten keinen Grund zur Beunruhigung dar. Laut Experten deute die Entdeckung von Radioaktivität in Wildtieren in der Nähe von Nuklearanlagen nicht unbedingt auf die Wahrscheinlichkeit eines größeren Lecks hin.

Es gibt wohl eine Presseerklärung von Edwin Deshong, Leiter des Amtes für Umweltmanagement der Savannah River Site. Diese besagt, dass die Wespennester „sehr geringe radioaktive Kontamination” aufwiesen. Dies stelle keine Gesundheitsrisiken für die Arbeiter der Anlage, die Anwohner oder die Umwelt darstellten.

In dieser Erklärung heißt es, dass die 43 aktiven unterirdischen Abfalltanks der Savannah River Site mehr als 34 Millionen Gallonen (163 Millionen Liter) radioaktiver Flüssigabfälle enthalten. Die ältesten Tanks wiesen zuvor „kleine Haarrisse” auf, die zu geringfügigen Leckagen führten, wie das Savannah River Site auf seiner Website mitteilt.

Das Tanklager befindet sich weit innerhalb der Grenzen des Geländes, und Wespen fliegen in der Regel nur wenige hundert Meter von ihren Nestern entfernt. Es bestehe keine Gefahr, dass die radioaktiven Wespen sich außerhalb der Anlage aufhalten, heißt es in einer Erklärung von Savannah River Mission Completion. Diese ist nun für die Überwachung des Geländes zuständig. Gefundene Wespen hätten deutlich niedrigere Strahlungswerte als ihre Nester aufgewiesen.

Also: Gehen Sie weiter, es gibt nichts zu sehen. Tanks lecken zwar ein wenig, aber das Gelände ist so weitläufig, dass niemand gefährdet ist, auch nicht durch radioaktive Wespen. Ob da Grundwasserflüsse durch radioaktive Flüssigkeiten gefährdet werden, wird nicht mitgeteilt. Irgendwann wird man das Gelände sanieren müssen, denn man geht davon aus, dass dort Bereiche radioaktiv kontaminiert sind.

Genau solche Vorfälle, und alles das, was die Öffentlichkeit nicht erfährt oder nicht wahrnimmt, hat mich zur Meinung gebracht, dass der Beschluss zum Atomausstieg nicht die schlechteste Entscheidung war. Positiv: Bundesumweltminister Schneider hat kürzlich in einem Interview mit dem Deutschlandfunk gesagt, dass es in Deutschland beim Atomausstieg bleibe. Die Zeit hatte die DPA-Meldung aufgegriffen.

Heute noch ein Sammelbeitrag zu Sicherheitsmeldungen, die mir die letzten Tage untergekommen sind, aber aus Mangel an Zeit nicht in separaten Artikeln aufgegriffen wurden. Der reine Wahnsinn, was wieder an Schwachstellen, Cybervorfällen und neuen Erkenntnissen los ist.

ShinyHunters Salesforce-Hacks (Qantas, Allianz Life,  LVMH)

In den letzten Wochen wurden ja einige Cyber-Vorfälle bei diversen Firmen wie Qantas, Allianz Life,  LVMH bekannt. Ich hatte z.B. im Beitrag Allianz Life Hack, Mehrheit der 1,6 Mio. Kunden betroffen über einen Datenabfluss berichtet, wo bei ein Dienstleister involviert war. Die Kollegen von Bleeping Computer berichten in diesem Artikel, dass die Gruppe ShinyHunter hinter diesen Hacks stehen und diese über Systeme des Anbieters Salesforce ausführen konnten.

Die Salesforce, Inc. mit Sitz in San Francisco ist ein börsennotiertes US-amerikanisches Softwareunternehmen, das Cloud-Computing-Produkte für Unternehmen anbietet. Das Unternehmen gilt als der weltgrößte Cloud-Softwareanbieter für Unternehmen. Auf der Unternehmensseite heißt es “Mit Salesforce, dem weltweit führenden CRM mit KI, können Unternehmen CRM, KI, Daten und Trust auf einer einheitlichen Einstein 1 Platform zusammenführen”. Und ich hatte im Juni 2025 berichtet, dass es Angriffe auf Salesforce-Instanzen per Vishing gebe (Hackergruppe UNC6040 greift Salesforce-Instanzen per Vishing an).

Gehe ich in den Artikel von Bleeping Computer, finden sich genau diese toxischen Kombinationen: ShinyHunters hat wohl das SalesForce CRM gehackt und hatte so Zugriff auf die Daten und IT-Systeme. Gegenüber Bleeping Computer bestätigte ein Allianz-Sprecher “Am 16. Juli 2025 verschaffte sich ein böswilliger Angreifer Zugang zu einem cloudbasierten CRM-System eines Drittanbieters, das von der Allianz Life Insurance Company of North America (Allianz Life) genutzt wird.” Konnte ja auch keiner ahnen, dass Angreifer auch noch böswillig handeln und auf dieses SalesForce zielen. Bei Quantas wird SalesForce zwar nicht genannt, aber der Name wird in Berichten gehandelt. Früher gab es den doofen Spruch “Ist Software, da kannst Du nix machen” – heute gilt “Ist SalesForce, kann man nix machen” (ok, man könnte noch ein bisschen Cloud und AI drunter mischen, dann ist es belegt, den armen Anwender trifft keine Schuld. Womit auch das geklärt wäre.

Tea-App Datenabfluss und Sicherheitslücken

Zum 27. Juli 2025 berichtete Norddeutsch im Diskussionsbereich von einem Datenverlust bei der tea-App. Die App nutzt höchst sensible Daten. Dating-Partner werden mit folgenden Technologien durchleuchtet:

• Background checks
• Catfish image search
• Sex offender search
• Phone number lookup
• Criminal record search

Die App bzw. der Anbieter versprach “sicheres” Dating für Frauen (die konnten Männer bewerten), mit Chat, Images, etc. Tea gibt an, mehr als 4 Millionen Nutzer (Frauen) zu haben.

Gut, wenn die Hormone beteiligt sind, lockt das große Geld und der Verstand ist nicht immer dabei. Ganz schlecht ist es, wenn auch noch Sicherheit versprochen wird. Es passierte das, was passieren musste. Es gab am 25. Juli 2025 einen unbefugten Zugriff auf eine ältere Datenbank, in der Daten bis 2024 gespeichert waren. Dabei wurden 72.000 Fotos, Selfies oder 12.000 IDs, 59.000 Posts, Kommentare oder Direktnachrichten abgezogen wurden (die Webseite von Tea legt den Vorfall offen).

Die Kollegen von Bleeping Computer berichten, dass ein anonymer Nutzer auf 4chan berichtete, dass  Tea einen ungesicherten Firebase-Speicherbucket verwendet habe, um von Mitgliedern hochgeladene Führerscheine und Selfies zu speichern. Die Dokumente dienten zum überprüfen, ob es sich um Frauen handelt. Auf dem Speicherbucket wurden auch Fotos und Bilder, die in Kommentaren geteilt wurden, abgelegt. Auch 9to5mac berichtete über den Vorfall.

Ingram Micro Hack: SafePay droht mit Datenleck

Anfang Juli 2025 berichtete ich im Beitrag Ingram Micro hat Ransomware-Infektion erlitten, dass der Distributor von IT-Waren (Lizenzen, Hardware) Opfer einer Ransomware-Infektion wurde. Die Ransomware-Gruppe SafePay war wohl verantwortlich und droht nun mit der Veröffentlichung von 3,5 TB an Daten von Ingram Micro. Die Details haben die Kollegen von Bleeping Computer zusammen getragen.

wird fortgesetzt

Ähnliche Artikel:
Allianz Life Hack, Mehrheit der 1,6 Mio. Kunden betroffen
Allianz droht Milliarden-Risiko wegen “mangelhafter” IT durch BAFIN-Auflagen
Hackergruppe UNC6040 greift Salesforce-Instanzen per Vishing an
Datenleck bei Louis Vuitton Malletier (2. Juli 2025)

[English]Kleiner Sammelbeitrag rund um BIOS- und UEFI-Updates auf Mainboard. Auf Boards mit AMD-Chips gibt es einen TPM-Bug, der weitgehend ungefixt bleibt, weil es keine Updates der Board-Hersteller gibt. Und GIGABYTE hat BIOS-Updates veröffentlicht, um Schwachstellen zu beheben.

Kein Update: AMD TPM-Bug bleibt ungefixt

In der AMD-Community gibt es seit Februar 2023 den Beitrag Baffling Windows 11 TPM Bug Is Wreaking Havoc On Some AMD Ryzen Systems zu einem TPM-Problem. Windows kann dann fTPM auf den betreffenden Plattformen nicht erkennen. Die betreffende TPM-Prüfung endet dann mit dem Fehlercode 0x80070490. Der Community-Beitrag enthält eine umfangreiche Aufbereitung und verlinkt auch Quellen von Betroffenen.

Der Bug scheint aber Besitzer von AMD-Systemen seit 2022 zu nerven. AMD hat nun Anfang Juli 2025 diesen Supportbeitrag reagiert (ist z.B. hier und hier aufgefallen). Im Beitrag gibt AMD an, dass man dieses Problem mit TPM-Firmware-Updates bereits gelöst haben. Betroffen waren bzw. sind Systeme mit Desktop- und Notebook-Prozessoren der Serien Ryzen™ 1000 – Ryzen 5000. Den Motherboard-Herstellern wurden von AMD bereits im Jahr 2022 entsprechende Fixes zur Verfügung gestellt.

Wenn der Bug also aktuell noch auftritt, heißt dies, dass die betreffenden Firmware-Updates für das Mainboard nicht eingespielt wurden. Der Ratschlag ist, sich beim Hersteller des Motherboard nach entsprechenden Firmware-Updates, die den Bug beheben, zu erkundigen. AMD merkt aber auch an, dass einige Motherboard-Hersteller sich dafür entschieden haben, diese TPM-Firmware-Updates nicht weiterzuverbreiten.

GIGABYTE BIOS-Update fixt Schwachstellen

Shawn Brink weist in nachfolgendem Tweet darauf hin, dass Hersteller GIGABYTE BIOS-Updates für seine Mainboards veröffentlicht hat, die mehrere Schwachstellen im System Management Mode (SMM), die in einigen älteren GIGABYTE/AORUS Consumer-Motherboards verwendet werden, schließen.

GIGA-BYTE Technology Co., Ltd. hat mehrere Schwachstellen in den System Management Mode (SMM)-Modulen identifiziert, die in verschiedenen älteren GIGABYTE/AORUS Consumer-Motherboards verwendet werden. Diese Schwachstellen bestehen nur auf älteren Intel-Plattformen, auf denen die betroffenen SMM-Module implementiert sind. Neuere Plattformen sind nicht betroffen.

Die erfolgreiche Ausnutzung dieser Schwachstellen kann es einem Angreifer mit lokalem Zugriff ermöglichen, seine Privilegien zu erhöhen oder beliebigen Code innerhalb der hochprivilegierten SMM-Umgebung auszuführen. Die Details hat er im ElevenForum beschrieben.

Besitzer von Solaranlagen mit SMA Sunny Tripower Smart Energy Hybrid Wechselrichter steht Ärger ins Haus, wenn diese den Heimspeicher BMZ Hyperion 7.5 (inklusive der Varianten von IBC Solar und AXITEC) verwenden. SMA hat die Firmware-Update für betroffene Anlagen gesperrt, weil es einen Inkompatibilität gibt. Der Sunny Tripower Smart Energy könnte mit der neuen Firmware (Version 3.06.18.R) die Batterie mit nur drei Modulen weder laden noch entladen, heißt es.

Sunny Tripower Smart Energy

Der Sunny Tripower Smart Energy ist ein 3-phasige Hybrid-Wechselrichter für Eigenheime, der von SMA für Solaranlagen vermarktet wird.

Anwender sollen mit dem Sunny Tripower Smart Energy Wechselrichter einfach und komfortabel Solarstrom erzeugen, nutzen und speichern können. Das System wird als sich jederzeit zu erweitern beworben und soll auch Elektromobilität oder Wärmepumpen einbinden.

Die integrierte Ersatzstromfunktion sichert die Stromversorgung des Haushalts auch beim Netzausfall. Solaranlagen im Eigenheim werden so zu ganzheitlichen und intelligenten Energiesystemen mit bis zu 100 Prozent solarer Eigenversorgung, heißt es in der Werbung.

Ich habe das Gerät selbst im Einsatz – es ist kompakt und speist auch einen Batteriepack mit überschüssigem Solarstrom. Die “Stromversorgung bei Netzausfall” bedeutet aber konkret, dass ich drei Stromkreise vorgeben musste, wo die betreffende Notstromeinspeisung erfolgt. Ein gesamtes Haus mit Notstrom zu versorgen, erfordert – jenseits der Batteriekapazität auch einen sehr teure Funktion zur Netztrennung.

Heimspeicher BMZ Hyperion 7.5

Der Sunny Tripower Smart Energy kann mit einem Heimspeicher BMZ Hyperion 7.5 (inklusive der Varianten von IBC Solar und AXITEC) kombiniert werden, um überschüssigen Solarstrom zu speichern.

Der BMZ Hyperion 7.5 lässt sich dabei mit Lithium-Ionen Modulen schrittweise erweitern. Die Minimalkonfiguration mit drei Modulen hat einen nutzbaren Energieinhalt von 7,5 kWh, welcher bei Bedarf in 2,5 kWh Abstufungen auf maximal 15 kWh erweitert werden kann.

Ich erinnere mich noch, dass es bei Beauftragung der Solaranlage in 2022 hieß, dass die Lieferung und Inbetriebnahme vor Herbst 2023 nicht erfolgen könne, weil der BMZ Hyperion 7.5 von SMA auf Kompatibilität abgenommen werden müsse.

Inkompatibilität mit Heimspeicher festgestellt

Nun informiert SMA Betreiber von Anlagen mit dem Sunny Tripower Smart Energy, bei denen ein Heimspeicher BMZ Hyperion 7.5 (inklusive der Varianten von IBC Solar und AXITEC) im Einsatz ist, über eine Firmware-Update-Sperre.

In einer Meldung, die mir zugegangen ist, heißt es, dass diese Systemkonfiguration für den SMA-Wechselrichter nicht freigegeben  ist (siehe Zugelassene Batterien). SMA gibt an, dass diese Kombination im Rahmen der Erhöhung der Reglerstabilität für weitere Firmwareupdates gesperrt werden musste. Der Sunny Tripower Smart Energy könnte mit der neuen Firmware (Version 3.06.18.R) die Batterie mit nur drei Modulen weder laden noch entladen.

SMA erklärt den Hintergrund so: Laut Datenblatt des Sunny Tripower Smart Energy liegt der freigegebene Spannungsbereich auf der Batterieseite bei 150 V bis 600 V. Die Batterien des BMZ Hyperion 7.5 stellen eine zu geringe Spannung zur Verfügung (min. 134 V), was zu einem nicht spezifikationskonformen Betrieb führt. Dieser kann zu Instabilitäten und langfristig zu Schäden am Wechselrichter und an der Batterie führen.

Um den Weiterbetrieb der betroffenen Anlage dennoch zu ermöglichen, wurde die Seriennummer des Wechselrichters auf eine Sperrliste für alle weiteren Firmware-Updates gesetzt. Das Firmware-Update (Version 3.06.18.R) wird für diese Anlage daher nicht ausgerollt.

Künftige Updates – etwa zur Fehlerbehebung, für die Sicherheit oder zur Erweiterung von Funktionen – stehen damit nicht mehr zur Verfügung. Damit die Anlage dauerhaft sicher genutzt werden kann, ist eine Erweiterung auf mindestens vier Batteriemodule notwendig, schreibt SMA. Aktuell klärt mein Solateur, wie diese Kuh vom Eis geholt werden kann – das sind die Überraschungen der negativen Art, die niemand brauchen kann – schöner Scheibenkleister.

In einem zum 4. Juli 2025 veröffentlichten Urteil hat das LG Leipzig entschieden, dass ein Facebook-Nutzer gegen Meta einen Anspruch auf Schadensersatz in Höhe von 5.000 EURO aus Art. 82 DGSVO wegen Verwendung der Meta Business Tools hat.

Der Fall ist mir die Tage bereits (hier mit Quelle Bild) untergekommen, was mir aber absolut zu dünn war – und ich hatte noch keine juristischen Details.

Urteil 05 O 2351/23 des LG Leipzig gegen Meta

In der gegen Meta Platforms Ireland betriebenen Klage eines Nutzers hat die für Datenschutzrecht zuständige 5. Zivilkammer des Landgerichts Leipzig mit Urteil 05 O 2351/23 vom 4. Juli 2025 einem Nutzer von Facebook eine Entschädigung wegen Datenschutzverstößen von 5.000 Euro zugesprochen.

Worum geht es?

Meta hat als Betreiberin der sozialen Netzwerke Instagram und Facebook Business Tools entwickelt, die von zahlreichen Betreibern auf ihren Webseiten und Apps eingebunden werden und die Daten der Nutzer von Instagram und Facebook an Meta senden. Konkret geht es um die Meta-Pixel, die die Seitenbetreiber in ihre Seiten einbauen (das könnte sogar ein Like-Button sein, wer auch ohne Anklicken die Information an Meta sendet, dass ein Nutzer die Seite besucht hat).

Das Meta-Pixel (früher Facebook-Pixel) ist ein Code, den Webseitenbetreiber auf ihrer Website einfügen, um für  Meta-Werbetreibende das Verhalten von Nutzern zu verfolgen und die Wirksamkeit von Facebook- und Instagram-Anzeigen zu messen. Das Pixel ermöglicht das Tracking von Aktionen wie Seitenaufrufen, Warenkorb-Hinzufügungen oder Käufen und soll helfen, Anzeigen besser auf bestimmte Zielgruppen auszurichten und den Erfolg von Kampagnen zu analysieren.

Warum das problematisch ist

Der Einbau der betreffenden “Meta-Pixel” ist problematisch, der Seitenbetreiber muss sich eine DSGVO-Einwilligung der Seitenbesucher einholen. Hier in den Blogs auf borncity.com habe ich – wegen der problematischen Konstruktion – von jeher auf die Einbindung von Meta-Pixeln verzichtet.

Der Hintergrund ist, dass jeder Nutzer für Meta zu jeder Zeit durch diese Pixel individuell erkennbar, sobald er sich auf den Dritt-Webseiten bewegt oder eine App benutzt hat, auch wenn er sich nicht über den Account von Instagram und Facebook angemeldet hat. Die Daten sendet Meta Ireland ausnahmslos weltweit in Drittstaaten, insbesondere in die USA. Dort werden die Daten in für den Nutzer unbekanntem Maß ausgewertet.

LG Leipzig sieht massiven DSGVO-Verstoß

Das Landgericht Leipzig sieht in den Meta Business Tools einen massiven Verstoß gegen  den europarechtlichen Datenschutz durch Meta. Da Meta die personenbezogenen Daten zu einem Profiling der Nutzer von Facebook verarbeitet. Zudem fahre Meta mit dem Geschäftsmodell der personalisierten Werbung Milliardengewinne ein.

Daher hat die für Datenschutzrecht zuständige 5. Zivilkammer des Landgerichts Leipzig mit Urteil vom 4. Juli 2025 dem klagenden Facebook-Nutzer eine Entschädigung wegen Datenschutzverstößen von 5.000 Euro zugesprochen. Das Gericht hält laut seiner Pressemitteilung die hohe Entschädigungssumme für gerechtfertigt.

Gericht stützt sich auf Europarecht

Das Gericht hat den Anspruch auf Ersatz des immateriellen Schadens ausschließlich auf Art. 82 der Datenschutz-Grundverordnung (DSGVO) gestützt, damit auf Europarecht und nicht (wie andere Gerichte in vergleichbaren Fällen) auf das nationale Recht bei Persönlichkeitsrechtsverletzungen, heißt es in der Presseerklärung.

Das Landgericht Leipzig hat sich dabei auf Feststellungen des Europäischen Gerichtshofs (EuGH) in einem Verfahren gegen Meta gestützt, in dem es ebenfalls um die Zulässigkeit der Business Tools ging. Da die Verarbeitung personenbezogener Daten besonders umfangreich ist – sie betrifft potenziell unbegrenzte Datenmengen und hat nahezu die vollständige Überwachung des Online-Verhaltens des Nutzers zur Folge – führt nach dem EuGH zu einem Gefühl, dass das gesamte Privatleben kontinuierlich überwacht wird.

Bemerkenswerte Vorgehensweise

Das Landgericht Leipzig hat auf eine informatorische Anhörung des Klägers – so wie die meisten anderen Gerichte bislang – verzichtet. Bei einer Anhörung des Klägers wären keine weiteren Erkenntnisse zu erwarten gewesen, der über die Mitteilung des im Allgemeinen eher diffusen Gefühls des Datenverlusts und der Verunsicherung hinausgeht, argumentieren die Richter.  Denn es sei ja gerade das Problem der Klagepartei und auch des Gerichts, festzustellen, was konkret Meta mit den Daten macht und noch vorhat.

Das Gericht stellt deshalb für eine Mindestentschädigung von 5.000 Euro auf die allgemeine Betroffenheit des aufmerksamen und verständigen »Durchschnitts«-Betroffenen im Sinne der DSGVO ab.

Urteil mit Signalwirkung?

Die Kammer ist sich, laut eigener Aussage, der Folgen ihrer Entscheidung bewusst. Auch wenn sie dazu führen könnte, dass viele Facebook-Nutzer Klage erheben, ohne einen individuellen Schaden explizit darzulegen, widerspricht dies nicht den gesetzgeberischen Zielen der DSGVO, gerade auch mittels Private Enforcement den Datenschutz vor Zivilgerichten und damit jenseits rein behördlicher Maßnahmen effektiv durchzusetzen.

Beck Aktuell geht in dieser Mitteilung auf diesen Sachverhalt ein, ohne aber wirklich viel Neues gegenüber obigen Verlautbarungen zu liefern. Aus meiner (nicht juristischen) Sichtweise folgende Einschätzung: Vom Ablauf müsste das oben genannte Urteil des LG Leipzig rechtskräftig sein – damit der Kläger seinen Schadensersatz bekommt. Meta kann (und wird) Berufung vor dem OLG Leipzig einlegen.

Falls jemand ebenfalls auf einen “Meta-Schadensersatz von 5.000 Euro” spekuliert, müsste er separat gegen Meta klagen (eine Sammelklage ohne ein rechtskräftiges Urteil in der Sache sehe ich derzeit noch nicht). Ob jedes Landgericht genau so argumentiert oder auf das LG-Urteil auf Leipzig abstellt, ist auch offen. Rechtsanwalt Solmecke von WBS geht in diesem Artikel auf das Thema ein. Die sehen wohl bereits ein Geschäftsmodell, welches dieses Urteil eröffnet. Aber nur zur Einordnung: Der oben erwähnte Kläger erhielt in erster Instanz einen Schadensersatzanspruch in Höhe von 5.000 Euro zugesprochen. WBS “kauft den Anspruch für 50 Euro” ab und würde das Prozessrisiko tragen.

Nachfolgend ist noch die Pressemitteilung vom 4.7.2025 des LG Leipzig zum Urteil mit dem Aktenzeichen 05 O 2351/23 im Volltext zu finden (falls diese später gelöscht wird).

Landgericht Leipzig spricht Facebook-Nutzer eine Entschädigung von 5.000 Euro wegen Datenschutzverstößen durch die Business Tools von Meta zu

In der gegen Meta Platforms Ireland betriebenen Klage hat die für Datenschutzrecht zuständige 5. Zivilkammer des Landgerichts Leipzig mit Urteil vom 4. Juli 2025 einem Nutzer von Facebook eine Entschädigung wegen Datenschutzverstößen von 5.000 Euro zugesprochen.

Damit, dass Meta mit seinen Business Tools massiv gegen europarechtlichen Datenschutz verstößt, die personenbezogenen Daten zu einem Profiling der Nutzer von Facebook verarbeitet und Meta mit dem Geschäftsmodell der personalisierten Werbung Milliardengewinne einfährt, hat das Gericht die hohe Entschädigungssumme gerechtfertigt.

Meta, Betreiberin der sozialen Netzwerke Instagram und Facebook, hat Business Tools entwickelt, die von zahlreichen Betreibern auf ihren Webseiten und Apps eingebunden werden und die Daten der Nutzer von Instagram und Facebook an Meta senden. Jeder Nutzer ist für Meta zu jeder Zeit individuell erkennbar, sobald er sich auf den Dritt-Webseiten bewegt oder eine App benutzt hat, auch wenn er sich nicht über den Account von Instagram und Facebook angemeldet hat. Die Daten sendet Meta Ireland ausnahmslos weltweit in Drittstaaten, insbesondere in die USA. Dort wertet sie die Daten in für den Nutzer unbekanntem Maß aus.

Das Gericht hat den Anspruch auf Ersatz des immateriellen Schadens ausschließlich auf Art. 82 der Datenschutz-Grundverordnung (DSGVO) gestützt, damit auf Europarecht und nicht (wie andere Gerichte in vergleichbaren Fällen) auf das nationale Recht bei Persönlichkeitsrechtsverletzungen. Das Landgericht Leipzig hat sich dabei auf Feststellungen des Europäischen Gerichtshofs (EuGH) in einem Verfahren gegen Meta gestützt, in dem es ebenfalls um die Zulässigkeit der Business Tools ging. Da die Verarbeitung personenbezogener Daten besonders umfangreich ist – sie betrifft potenziell unbegrenzte Datenmengen und hat nahezu die vollständige Überwachung des Online-Verhaltens des Nutzers zur Folge – führt nach dem EuGH zu einem Gefühl, dass das gesamte Privatleben kontinuierlich überwacht wird.

Die Höhe des europarechtsautonom auszulegenden Schmerzensgeldes nach Art. 82 DSGVO muss, so das Landgericht Leipzig, über die in der nationalen Rechtsprechungspraxis etablierten Schmerzensgeldbeträge hinausgehen. Bei der Schadensschätzung wurde an den Wert der personenbezogenen Daten zu Zwecken personalisierter Werbung für Meta angeknüpft. Nach dem Bundeskartellamt (Beschl. v. 2.5.2022, Az. B 6-27/21) verfügt Meta im Bereich der sozialen Medien über eines der führenden Werbeangebote. Im Jahr 2021 erzielte Meta bereits 115 Mrd. USD Werbeeinnahmen bei einem Gesamtumsatz von 118 Mrd. USD, sodass die Werbeeinnahmen 97 % vom Umsatz ausmachen. Der finanzielle Wert eines einzigen Nutzerprofils, in dem sämtliche Daten über die Person gespeichert sind, ist auf datenverarbeitenden Märkte enorm. Dass der hohe Wert von Daten auch der Wahrnehmung in der Gesellschaft entspricht, sieht das Gericht durch diverse Studien bestätigt.

Auf eine informatorische Anhörung des Klägers – so wie die meisten anderen Gerichte bislang – hat das Landgericht Leipzig verzichtet. Bei einer Anhörung des Klägers wären keine weiteren Erkenntnisse zu erwarten gewesen, der über die Mitteilung des im Allgemeinen eher diffusen Gefühls des Datenverlusts und der Verunsicherung hinausgeht. Denn es ist ja gerade das Problem der Klagepartei und auch des Gerichts, festzustellen, was konkret Meta mit den Daten macht und noch vorhat. Das Gericht stellt deshalb für eine Mindestentschädigung von 5.000 Euro auf die allgemeine Betroffenheit des aufmerksamen und verständigen »Durchschnitts«-Betroffenen im Sinne der DSGVO ab.

Die Kammer ist sich der Folgen ihrer Entscheidung bewusst. Auch wenn sie dazu führen könnte, dass viele Facebook-Nutzer Klage erheben, ohne einen individuellen Schaden explizit darzulegen, widerspricht dies nicht den gesetzgeberischen Zielen der DSGVO, gerade auch mittels Private Enforcement den Datenschutz vor Zivilgerichten und damit jenseits rein behördlicher Maßnahmen effektiv durchzusetzen.

Unschöne Geschichte, die sich gerade bei mailbox.org abzuspielen scheint. Nutzer die einen catch-all-Alias für ihr Postfach eingerichtet haben, haben einige Zeit plötzlich E-Mails anderer Benutzer aus E-Mail-Postfächern fremder Domänen zugestellt erhalten. Der Fehler ist inzwischen wohl behoben.

Was ist mailbox.org?

mailbox.org ist ein kostenpflichtiger, deutscher E-Mail-Dienst des Berliner Unternehmens Heinlein Hosting GmbH, der seit Februar 2014 online ist. Der Dienst versucht, sich mit besonderem Augenmerk auf Datenschutz, Datensicherheit und Werbefreiheit von anderen Anbietern abzugrenzen.

Eigene Domain mit Catch-All

Der E-Mail-Dienst mailbox.org ermöglicht Kunden mit eigener Domain einen Catch-All-Alias einzurichten. Der Hintergrund ist, dass an diesem Catch-All-Alias alle E-Mails landen, die an die betreffende Domain gesendet werden. Hätte ich beispielsweise ein Konto bei diesem Dienst, könnte ich borncity.com als Domain für den E-Mail-Empfang zuweisen und mit Einrichtung eines Catch-All-Alias alle Mails an diese Domain abgreifen.

Im betreffenden Support-Beitrag von mailbox.org heißt es dazu: “Wenn Sie bei mailbox.org Ihre eigene Domain für E-Mails verwenden, steht es Ihnen auch frei, einen so genannten Catch-All zu verwenden. Mit so einem “Allesfänger” (engl. “catch-all”) erhalten sie einfach alle E-Mails dieser Domain, auch solche, für die keine E-Mail-Adresse oder kein spezieller Alias angelegt wurde. Dafür dient ein spezieller Catch-All-Alias.” Im Support-Beitrag werden die Schritte zum Einrichten eines solchen Mechanismus im Detail beschrieben.

Problem: E-Mails fremder Domains im Postfach

Es war nur ein kurzer Kommentar von Tomas Jakobs im Diskussionsbereich des Blogs, der auf eine Forendiskussion E-Mails fremder Domain-User im Postfach bei mailbox.org zum Problem verlinkte (danke dafür).

Im Forenthread hat sich ein Nutzer gemeldet und schreibt, dass seit dem 18. Juli 2025, ca. 17 Uhr CEST, an seinem Postfach mit Catch-All-Alias plötzlich E-Mails fremder Benutzer eintreffen, die einen alias@domain.tld registriert haben.

Ein zweiter Nutzer schrieb, dass er das Problem bei sich in seinem Catch-All-E-Mail-Konto ebenfalls nachvollziehen könne. Aktuell scheint nur die Möglichkeit zu bestehen, den Catch-all-Alias beim Postfach zu entfernen.

Es gibt die Spekulation, dass der im Forenbeitrag hier beschriebene Fehler bzw. dessen Reparatur etwas an der Mailzustellung bei mailbox.org verändert hat.

Anbieter bestätigt Vorfall

In diesem Forenbeitrag informiert das Support-Team über einen sicherheitsrelevanten Vorfall, der in obigem Forenthread beschrieben wurde. Der Suppport schreibt, dass man durch Hinweise aus der Community eine Konfigurationsabweichung auf den eigenen Mail-Servern identifiziert habe.

Diese Abweichung ermöglichte unter bestimmten Umständen (bei Nutzung einer Catch-All-Adresse) – trotz aktivierter Zwei-Faktor-Authentifizierung (2FA) in Keycloak – die Authentifizierung mit dem Hauptpasswort.

Betroffen war laut Support potentiell eine dreistellige Zahl an Privatkunden, die sowohl 2FA in Keycloak aktiviert als auch eine Catch-All-Adresse nutzen. Die  festgestellte Konfigurationsabweichung der E-Mail-Server bestand seitdem die jeweiligen Benutzer auf den Login 2.0 umgestellt wurden und einen Catch-All für Ihre Domain eingerichtet hatten.

Im verlinkten Forenbeitrag informiert das mailbox.org-Supportteam, was man inzwischen unternommen habe. So sei der Fehler umgehend behoben worden. Die betroffenen Kunden werden individuell informiert und erhalten bei Bedarf Unterstützung. Weiterhin sei der Vorfall an unseren Chief Security Officer gemeldet worden. Ob eine DSGVO-Meldung bei der zuständigen Datenschutzbehörde erfolgt ist, ist offen. Der Vorfall ist eine arg unschöne Geschichte – imho.

Das von Sparkasse beim Online-Banking eingesetzte S-PushTAN-Verfahren ist für die Absicherung von Transaktionen unzureichend. Das hat das OLG-Dresden in einem Urteil festgestellt und einem Phishing-Opfer, welches grob fahrlässig handelte, einen Teil-Schadensersatz zugesprochen.

Das S-PushTAN-Verfahren der Sparkassen

Das S-PushTAN-Verfahren wird beim Online-Banking mit der S-PushTAN-App der Sparkassen zur Absicherung von Transaktionen bei Aufträgen verwendet.

Gemäß obigem Screenshot von der Seite des Sparkassenverband wird dieses Verfahren als Non-Plus-Ultra mit hoher Sicherheit beim mobilen Banking mit jedem Endgerät gepriesen. Man kann auch Internet-Kartenzahlungen und telefonische Identifikationen durchführen.

Der Pferdefuß, warum ich persönlich das nicht nutze: Man hat keine Zweifaktor-Absicherung über zwei Geräte, weil alles in der S-PushTAN-App der Sparkasse erfolgt. Ich nutze daher weiterhin einen separaten TAN-Generator zum Online-Banking. Aber viele Banken segeln mit ihren Banking-Apps auf dieser Schiene.

Der Sachverhalt: Grob fahrlässiges Kundenverhalten

Ein Sparkassen-Kunde war auf einen Phishing-Mail hereingefallen, die ihm suggerierte, dass das Online-Banking aktualisiert werde und dafür Anpassungen notwendig seien. Das Opfer glaubte, die Mail sei vom “Kundenservice” seiner Sparkasse und folgte dem in der Phishing-Mail angegebenen URL.

Phishing-Mail und Freigabe von Aufträgen

Auf einer Fake-Seite, die ein Sparkassen-Login vorgaukelte, gab er die Zugangsdaten für sein Online-Konto bei der Sparkasse an. Die Betrüger fischten diese Zugangsdaten ab. Drei Tage nach dem Besuch der Fake-Anmeldeseite erhielt das Opfer einen ersten Anruf, in denen er vermeintlich Aufträge seiner Sparkasse bestätigen musste. Die Beschreibung bei Beck, die das OLG-Urteil wiedergibt, enthält die Information, dass das Opfer durch die Anrufer genötigt wurde, zwei Aufträge zu bestätigen. Mit diesem Vorgang erhöhten die Täter das Tageslimit für Überweisungen und transferierten 24.422 Euro auf ein unbekanntes Konto. Gleichzeitig wurden die Zugangsdaten für das Online-Banking geändert.

Einen Tag später gab es einen angekündigter weiteren Anruf, bei dem das Opfer wieder zwei Aufträge per S-PushTAN bestätigen musste. Erneut wurde das Tagelimit erhöht und die Täter konnten erneut 24.422 Euro auf ein unbekanntes Konto transferieren.

Wiederholt grob fahrlässiges Verhalten des Kunden

Hier wurde gleich mehrere Male vom Kunden grob fahrlässig gehandelt. Die Kommunikation zwischen Sparkasse und Kunde läuft immer über das Postfach seines Kundenkontos (jedenfalls kenne ich das nicht anders). Er hätte niemals über den Anmeldelink einer Mail auf die “Sparkassen-Seite” gehen dürfen. Dann zum Zugriff auf das Postfach des Kundenkontos muss man in der Sparkassen-App oder beim Online-Banking im Browser angemeldet sein.

Ein Bankmitarbeiter wird meiner Kenntnis nach auch niemals Transaktionen des Kunden auf die oben beschriebene Weise durchführen. Weiterhin ist anzuführen, dass das Opfer nach dem ersten Anruf nicht versuchte, seine Konten per Online-Banking zu überprüfen. Dann wären die geänderten Zugangsdaten und der für das Opfer gesperrte Online-Zugang aufgefallen.

Als letztes geht mir noch der Gedanke: Da hat jemand viel Asche auf seinem Konto liegen gehabt, dass die Betrüger fast 50.000 Euro abbuchen konnten. Und mit der Assoziation “viel Asche” geht mir noch “da kann der Kunde eigentlich nicht so naiv sein” durch den Kopf. Aber wie warb bereits Toyota: “Nichts ist unmöglich”.

Betrug fliegt auf, Kunde will Geld von der Sparkasse

Etwa zwei Wochen später habe das Opfer, ein Mann, bemerkt, dass er sich nicht mehr  in seiner S-PushTAN-App der Sparkasse einloggen konnte. Er kontaktierte seine Sparkasse, und wurde von dieser über die Kontobewegungen informierte.

Das Opfer wollte sein Geld von der Sparkasse zurück und argumentierte, er habe die Zahlungen nicht autorisiert. Er habe auch nicht grob fahrlässig gehandelt, jedenfalls hafte er der Sparkasse nicht, weil sie beim Einloggen in das Online-Banking keine starke Kundenauthentifizierung verlange.

Juristischer Weg bis zum OLG Dresden

So aus dem hohlen Bauch ging mir der Gedanke: “Da hilft nur lernen durch Schmerzen” durch den Kopf. Denn das Opfer hat mehrfach nicht nur arg blauäugig, sondern auch grob fahrlässig gehandelt. Das Landgericht Chemnitz wies die Klage auf Erstattung des Schaden denn auch ab. Das Opfer legte über seinen Anwalt Berufung gegen dieses Urteil ein, so dass das Verfahren vor dem Oberlandesgericht in Dresden landete.

S-Push-TAN-Verfahren nicht sicher

Der Leserschaft dieses Blogs ist klar, dass das S-PushTAN-Verfahren mit einer App, in der Banking-Vorgänge angestoßen und gleichzeitig autorisiert werden, nicht wirklich als sicher zu erachten ist, da der zweite Faktor fehlt.

S-Push-TAN-Verfahren keine starke Kundenauthentifizierung

Nun bin ich kein Jurist – und dort kommt es oft auf Feinheiten an. Vor dem OLG Dresden konnte der Kläger dann einen Teilerfolg verbuchen. Die Richter urteilten am 05.06.2025 (Az. 8 U 1482/24), dass die betreffende Sparkasse trotz grober Fahrlässigkeit des Kunden beim Phishing-Angriff haften muss. Die Begründung: Das Gericht sah eine Mitverantwortung der Bank, da diese beim Login ins Online-Banking keine starke Kundenauthentifizierung implementiert hatte und somit gegen europäische Sicherheitsanforderungen verstieß.

Laut Beck nimmt das OLG Dresden an, dass der Mann die Zahlungen nicht autorisiert hat, sodass er zunächst gemäß § 675u S. 2 BGB einen Anspruch auf Erstattung des vollen, von seinem Konto überwiesenen Betrags habe. Die Richter erkennen zwar an, dass die Sparkasse die Authentifizierung des Klägers durch technische Protokolle nachgewiesen  habe (§ 675w Abs. 1 S. 1 BGB). Und dann kommt der juristische Knackpunkt: Einen etwaigen daraus folgenden Anscheinsbeweis für die Autorisierung habe der Mann aber mit der Schilderung des Phishing-Angriffs erschüttert. Sicherheitsmängel im Online-Banking der Bank müssten dafür vom Kläger nicht dargelegt werden.

Dass der Kläger den Schaden nur teilweise von der Sparkasse ersetzt bekommen soll, begründen die Richter mit dem grob fahrlässigen Verhalten und Verletzung der Sorgfaltspflichten des Klägers. Die sprachlichen Fehler in der angeblich von seiner Sparkasse stammenden E-Mail und der weitere Ablauf (Verifizierung, Anrufe, mehrfache Freigaben in der S-PushTAN-App) hätten den Kläger argwöhnisch machen müssen.

Die Richter argumentieren, dass Phishing bekannt und in den Medien ein präsentes Thema sei. Zudem habe die Sparkasse in ihren Sicherheitshinweisen vor solchen Phishing-Angriffen gewarnt. Außerdem müsse es im Allgemeinen jedem einleuchten, dass eine App zur Freigabe von Zahlungen nicht für eine angebliche Aktualisierung genutzt werden dürfe.

Das OLG lastet der Sparkasse wegen des Fehlens der aufsichtsrechtlich – auch beim Online-Zugriff – vorgeschriebenen starken Kundenauthentifizierung ein Mitverschulden von 20% an. Die Sparkasse muss ihrem Kunden daher 9.768,80 Euro des entstandenen Schadens ersetzen. Eine Revision des Urteils hat das OLG nicht zugelassen.

Spannend wird es, die Folgen zu beobachten

Aus meiner Sicht drängt sich nun die Frage nach den Folgen dieses Urteils auf. Werden die Banken ihr Online-Banking entsprechend umstellen und auf S-PushTAN oder gleichwertige Verfahren in ihren Online-Banking-Apps verzichten? Man wird es abwarten müssen – es ist eine Einzelfall-Entscheidung und mit einem “Schaden für die Sparkasse” unter 10.000 Euro eigentlich “Peanuts” (um mit Deutsche Bank Vorstand Hilmar Kopper zu sprechen).

Das Urteil des OLG-Dresden kommt übrigens nicht aus dem “luftleeren Raum”. Als ich hier erstmals über das Urteil las, ging mir “da war doch mal was” durch den Kopf. Wie so oft wusste mein Blog bei einer kurzen Suche Rat. Im Oktober 2023 hatte ich das Thema schon mal im Blog-Beitrag Gericht stuft Push-TAN-Verfahren der Banken als unsicher ein aufgegriffen. Dort hatte ich die Fallstricke des Push-TAN-Verfahrens der Banken und ein Urteil  der 6. Zivilkammer des LG Heilbronn vom 16.05.2023 (AZ Bm 6 O 10/23) aufgegriffen. Die Kammer hatte das Push-TAN-Verfahren wegen fehlende Zweifaktor-Authentifizierung als unsicher eingestuft.

Da sich seit diesem Urteil nichts getan hat, sagt mein Bauchgefühl, dass auch das OLG Dresden mit seinem Urteil keine Schockwellen durch die deutschen Banken-Lande geschickt hat. Allerding: Die Zahl der Phishing-Opfer mit entsprechenden Schäden steigt – die Zahl der Fälle, wo Banken dann, trotz fahrlässigem Verhalten ihrer Kunden, haften müssen, könnte steigen.

Das Urteil ist übrigens kein Freibrief für Bankkunden, unachtsam bezüglich Phishing zu werden. Bei jedem Schadensfall wird ein Opfer, zumindest nach meiner Einschätzung nach, klagen müssen.

Für die Betriebswirtschaftler in den Zentralen der Sparkassen ist es dann ein Rechenbeispiel: Wie viele Schäden muss ich im Jahr begleichen, und wie viele Kunden gehen mir als Bank verloren, wenn mein Online-Banking nicht genau so attraktiv wie der Ansatz der vielen Online- und Neobanken ist?

Ähnliche Artikel
Postbank: App und/oder SealOne statt chipTAN – Teil 1
Volks- und Raiffeisenbanken stellen SMS-TAN-Verfahren zum 30.9.2022 ein – Teil 2
Sparkassen und Volksbanken: Ende des [alten] chipTAN-Verfahrens – Teil 3
Online-Banking und Apps: Was die Kunden wünschen – Teil 4
Online-Banking und die Sicherheit von Banking-Apps – Teil 5
Online-Banking und Absicherung per chipTAN USB – Teil 6
Online-Banking: mTAN und Banking-Apps unsicher

Der Fail der Banken beim Online-Banking – Teil 1
Fail der Ing beim Online-Banking – Teil 2

Gericht stuft Push-TAN-Verfahren der Banken als unsicher ein
Datenleck bei Postbank und Deutscher Bank; ING und Comdirect
MOVEit-Datenleck: Neben Postbank/Deutscher Bank auch ING und Comdirect betroffen

Gehärteter Online-Banking-Browser S-Protect, ein Totalausfall?
Nachlese: Gehärteter Online-Banking-Browser S-Protect, neue Version, neue Erkenntnisse
Online-Banking: mTAN über SS7/UMTS gehackt, Konten abgeräumt
Vorsicht vor App-TANs beim Online-Banking