Daily-Briefing Datenschutz & IT-Sicherheit
Deutschland · Datenschutz · Datensicherheit · IT-Sicherheit · Urteile · Bußgelder · Cyber-Sicherheit
Worauf Sie heute achten sollten
- Wenn Sie ein Konto bei Revolut haben: Ihre Ausweiskopie, Ihr Verifizierungs-Selfie und Ihre Kontoauszüge könnten bei Kriminellen liegen — und niemand hat dafür in die Bank einbrechen müssen. Revolut hat am Samstag bestätigt, dass Unbekannte Kundendaten erhalten haben, weil sie ein Auskunftsersuchen von einer echten Behördendomain aus verschickt haben. Genau über diesen Kanal beantworten Banken Anfragen von Ermittlungsbehörden; die Adresse bestand die Prüfung, weil die Domain tatsächlich einer Behörde gehört. Übermittelt wurden je nach Fall Geburtsdatum, Anschrift, Telefonnummer, Kopien von Pass oder Führerschein, das Selfie aus der Identitätsprüfung sowie Kontoauszüge und Transaktionshistorien. Revolut hat betroffene Kunden direkt angeschrieben — wenn Sie eine solche Nachricht erhalten haben, ist sie echt, und Sie sollten in den nächsten Monaten mit besonders gut gemachten Betrugsversuchen rechnen, die Ihre echten Kontodaten zitieren. Wer keine Nachricht bekommen hat, ist nach jetzigem Stand nicht betroffen; Rückfragen gehören ausschließlich in die App, nicht auf eine Nummer aus einer eingehenden Mail.
- Wenn Sie Post vom Finanzamt erwarten: Die aktuelle ELSTER-Fälschung arbeitet mit einem angeblichen „Registerdatenabgleich“ und will Ihre Bankverbindung. Die Verbraucherzentrale warnt seit Freitag vor Mails mit dem Betreff „Elster Registerdatenabgleich – Steuerdaten prüfen“. Darin wird behauptet, Ihre hinterlegten Steuerdaten wichen von den amtlichen Registerangaben ab; Adresse, Kontaktdaten und Bankverbindung sollen über einen „gesicherten Zugang“ bestätigt werden, die Steuer-Identifikationsnummer soll man bereithalten. Das ist neu an der Masche: Sie fordert kein Geld, sondern gibt sich als Verwaltungsvorgang aus — und wirkt dadurch harmloser. Die Finanzverwaltung gleicht Registerdaten intern ab und bittet Sie dafür nie per Mail um Ihre Kontonummer. Wenn Sie unsicher sind, melden Sie sich direkt in Ihrem ELSTER-Konto an, ohne den Link zu benutzen.
- Wenn ein IT-Dienstleister per Fernwartung auf Ihren Rechner zugreift: Prüfen Sie, wer diese Verbindung aufgebaut hat. In der weit verbreiteten Fernwartungssoftware ScreenConnect steckt eine Lücke, über die während einer laufenden Sitzung Dateien auf Ihren Rechner übertragen und ausgeführt werden können, ohne dass die übliche Bestätigungsabfrage erscheint. Sicherheitsforscher haben drei Fälle dokumentiert, in denen manipulierte Fernwartungs-Clients eine Schadsoftware-Kette automatisch auf jeden neu verbundenen Rechner weitergereicht haben — also wurmartig. Der Einstieg lief jedes Mal über Menschen, nicht über Technik: ein angeblicher Support-Anruf, ein per Mail zugestelltes Installationsprogramm, ein gefälschtes Erstattungsformular eines Elektronikhändlers. Die Regel dagegen ist unbequem, aber wirksam: Eine Fernwartungssitzung beginnt nur, wenn Sie selbst den Dienstleister angerufen haben — nie umgekehrt.
- Wenn Sie Geräte oder Software kaufen: Seit Freitag müssen Hersteller Sicherheitslücken melden, die bereits ausgenutzt werden. Mit dem Cyber Resilience Act greift seit dem 11. September die erste echte Pflicht: Wer ein Produkt mit digitalen Elementen auf den EU-Markt bringt — vom Router über die Industriesteuerung bis zur Software —, muss eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden melden. Das gilt auch für Produkte, die längst verkauft sind. Für Sie als Käuferin oder Käufer ändert sich vorerst wenig Sichtbares; die eigentlichen Produktanforderungen greifen erst Ende 2027. Der Unterschied liegt darin, dass Behörden künftig früher erfahren, wenn etwas brennt — vorausgesetzt, die Hersteller halten sich daran. Eine Umfrage vom Freitag legt nahe, dass drei von zehn Unternehmen überhaupt einschätzen können, was die Verordnung für sie bedeutet.
Aktuelle Phishing- und Betrugswellen
Der bemerkenswerteste Betrugsfall des Wochenendes kam ohne eine einzige Phishing-Mail an Kunden aus. Bei Revolut haben Unbekannte keine Systeme angegriffen, sondern den Kanal benutzt, über den regulierte Unternehmen Auskunftsersuchen von Ermittlungsbehörden beantworten. Die Anfrage kam von einer E-Mail-Adresse auf einer Domain, die tatsächlich einer Behörde gehört — damit bestand sie jede formale Prüfung. Herausgegeben wurden Identitätsdaten, Ausweiskopien, Verifizierungs-Selfies und Kontobewegungen. Dieses Muster hat einen eigenen Namen, „Emergency Data Request“, und es zielt nicht auf die Technik, sondern auf einen Prozess, der bewusst schnell und formlos funktionieren soll. Für Kundinnen und Kunden folgt daraus eine unangenehme Einsicht: Die Sorgfalt der eigenen Bank bei Passwörtern und Zwei-Faktor-Anmeldung schützt nicht vor diesem Weg.
Bei den klassischen Wellen steht diese Woche eine ELSTER-Fälschung im Vordergrund, die sich anders tarnt als die Vorgänger. Statt einer angeblichen Nachzahlung behauptet sie einen bundeseinheitlichen „Registerdatenabgleich“, bei dem die hinterlegten Steuerdaten von den amtlichen Registerangaben abwichen. Bestätigt werden sollen Adresse, Kontaktdaten und Bankverbindung, bereitzuhalten sei die Steuer-Identifikationsnummer. Die Masche funktioniert, weil sie keine Drohung enthält und wie ein Verwaltungsvorgang wirkt — der Zeitdruck steckt allein in der genannten Frist. Wer den Reflex hat, auf amtliche Post schnell zu reagieren, ist hier genau die Zielgruppe. Der Prüfstein bleibt derselbe wie bei jeder Finanz-Mail: Die Steuerverwaltung fordert Bankverbindungen nie über einen Link an, und das eigene ELSTER-Konto erreicht man über die selbst eingetippte Adresse.
Die dritte Welle läuft über Fernwartung statt über den Posteingang und ist für Privatpersonen wie für kleine Betriebe relevant. Sicherheitsforscher von Huntress haben drei unabhängige Vorfälle untersucht, in denen manipulierte ScreenConnect-Clients auf den Rechnern der Opfer landeten. Der Einstieg war jedes Mal Social Engineering: ein Support-Betrug über die Windows-eigene Schnellhilfe, ein per Mail zugestelltes Installationsprogramm, ein gefälschtes Erstattungsformular eines Elektronikhändlers. Danach startete der Client eine Kette von vier Skripten, die erst prüfte, welcher Virenschutz installiert ist und wie viel Arbeitsspeicher zur Verfügung steht — Letzteres, um Analyseumgebungen zu erkennen —, und dann die passende Schadsoftware nachlud. Weil die manipulierten Clients dieselben Dateien automatisch an neu verbundene Endpunkte weiterreichen, verbreitet sich das Ganze über Fernwartungssitzungen weiter. Für Betroffene lautet die Empfehlung der Forscher, das Gerät neu aufzusetzen statt zu bereinigen.
Was war los?
Der Freitag hat eine Regel scharf gestellt, über die seit Jahren geredet wurde. Seit dem 11. September gilt die Meldepflicht des Cyber Resilience Act: Wer ein Produkt mit digitalen Elementen auf dem europäischen Markt bereitstellt, muss eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden melden, binnen 72 Stunden eine technische Bewertung nachreichen und einen Abschlussbericht liefern — bei Schwachstellen 14 Tage, nachdem eine Abhilfe verfügbar ist, bei schweren Vorfällen einen Monat nach der 72-Stunden-Meldung. Das gilt für Router und Industriesteuerungen genauso wie für Software, unabhängig vom Sitz des Herstellers und auch für Produkte, die längst im Umlauf sind. Die Plattform, über die gemeldet wird, ging am selben Tag in Betrieb; ihre Nutzungsbedingungen datieren auf den Tag davor.
Wie weit die Praxis davon entfernt ist, zeigt eine Umfrage des Branchenverbands Bitkom unter gut tausend Unternehmen. Nur 29 Prozent können einschätzen, was die Verordnung für das eigene Haus bedeutet. Weitere 38 Prozent haben vom Regelwerk gehört, wissen aber nicht, welche Folgen es hat. 28 Prozent kennen es gar nicht. Man muss dazu wissen, dass die Meldepflicht kein Formular ist, das man im Ernstfall schnell ausfüllt: Wer binnen 24 Stunden melden soll, muss vorher wissen, welche fremden Bestandteile in seinen Produkten stecken und wie er erfährt, dass einer davon angegriffen wird. Genau diese Bestandsführung ist die Arbeit, die viele noch vor sich haben.
Auf der technischen Seite prägen zwei Lücken den Tag, und beide haben Fristen, die heute ablaufen. In GitLab erlaubt eine Pfadmanipulation in der Commits-Schnittstelle, ohne Anmeldung beliebige Dateien vom Server zu lesen — Konfigurationen, Schlüssel, Zugangsdaten. Die Bewertung liegt beim Höchstwert 10,0, der Patch kam am 10. September, und rund zwanzig Stunden später sahen Sicherheitsforscher die ersten Angriffsversuche in freier Wildbahn. In ConnectWise ScreenConnect erlaubt eine fehlerhafte Rechteverwaltung im Client, während einer laufenden Fernwartungssitzung Dateien zu übertragen und auszuführen, ohne dass der Rechner des Nutzers nachfragt. Beide Lücken stehen seit Freitag im Pflichtkatalog der amerikanischen Cybersicherheitsbehörde, für beide endet die Behördenfrist heute.
Was sich rechtlich geändert hat
Die wichtigste Änderung ist keine Entscheidung, sondern ein Datum: Seit Freitag gilt die erste Pflicht aus dem Cyber Resilience Act. Für Verbraucherinnen und Verbraucher ist das mittelbar wirksam — es verkürzt im Idealfall die Zeitspanne zwischen dem Moment, in dem ein Hersteller von einem laufenden Angriff auf sein Produkt erfährt, und dem Moment, in dem Behörden reagieren können. Sichtbar wird davon zunächst nichts. Die eigentlichen Produktanforderungen — Sicherheit ab Werk, Updates über die erwartete Nutzungsdauer — gelten erst für Produkte, die ab dem 11. Dezember 2027 neu auf den Markt kommen.
Aus der Rechtsprechung kommt eine Entscheidung, die viele der laufenden Datenschutzklagen betrifft. Das Amtsgericht Heilbronn hat entschieden, dass eine rechtsschutzversicherte Partei ihre Pflichten gegenüber der Versicherung verletzt, wenn sie einer gerichtlichen Ladung zum persönlichen Erscheinen unentschuldigt fernbleibt. Der Kläger hatte wegen der Meta Business Tools 5.000 Euro Schadensersatz gefordert, war zum Termin nicht erschienen und hatte seinen Kontrollverlust nur mit Textbausteinen beschrieben. Das Gericht sprach ihm Deckungsschutz für die Berufung nur bis 500 Euro zu. Wer eine solche Klage führt, sollte daraus zwei Dinge mitnehmen: Angeordnete Termine sind keine Formsache, und ein Schaden, der über den Sockelbetrag hinausgeht, muss mit eigenen, konkreten Erlebnissen begründet werden. Das Urteil ist nicht rechtskräftig; die Berufung wurde zugelassen.
Aus Frankreich kommt schließlich ein Bußgeld, das für jede Personalabteilung lesenswert ist. Die CNIL hat gegen ein Beratungsunternehmen 300.000 Euro verhängt, weil es Löschanträge von Bewerbern und ehemaligen Beschäftigten nicht oder zu spät beantwortet hat. Bemerkenswert ist die Begründung: Auch wenn Daten tatsächlich gelöscht wurden, bleibt die Pflicht bestehen, die betroffene Person innerhalb eines Monats über das Ergebnis zu informieren. Beides sind getrennte Verstöße.
IT-Detailansicht für Fachpublikum
Der folgende Teil ordnet die Lage für Verantwortliche ein: zunächst die laufenden Schwerpunkte und eine Management Summary, dann die Handlungsempfehlungen des Tages und sechs Kapitel — Datenschutz, Datensicherheit, IT-Sicherheit, Urteile, Bußgelder und Cyber-Sicherheit —, gefolgt von einem Überblick zu den großen Sprachmodellen, dem Ausblick, der Methodik und dem Quellenverzeichnis. Alle Angaben sind mit Deep-Links auf die jeweilige Primärquelle belegt.
Top-Themen der Woche
1. Fristen, die heute ablaufen: GitLab und ScreenConnect
Zwei Produkte, die in fast jeder Dienstleisterlandschaft stecken — eine Entwicklungsplattform und eine Fernwartungslösung —, haben binnen einer Woche kritische Lücken bekommen, die beide bereits angegriffen werden. Gemeinsam ist ihnen, dass die Ausnutzung keine Anmeldung erfordert und dass der Schaden nicht am betroffenen System endet: Bei GitLab fließen Zugangsdaten und Schlüssel ab, bei ScreenConnect greift die Kompromittierung auf verbundene Kundensysteme über.
Letzte Entwicklung: CISA hat beide Lücken am 11. September in den Pflichtkatalog aufgenommen. Die Behördenfrist endet für GitLab (CVE-2026-85706, CVSS 10,0) und für ScreenConnect (CVE-2026-84869, CVSS 9,9) am heutigen 14. September; für ScreenConnect ist zusätzlich eine forensische Triage vorgeschrieben. Bei GitLab sahen Honeypots der Firma watchTowr rund zwanzig Stunden nach der Veröffentlichung des Patches die ersten Ausnutzungsversuche.
2. Der Cyber Resilience Act wird operativ
Aus einer Verordnung mit langen Übergangsfristen ist eine Pflicht mit Uhr geworden. Die 24-Stunden-Frühwarnung nach Artikel 14 gilt seit dem 11. September für alle Produkte mit digitalen Elementen auf dem Unionsmarkt, einschließlich Bestandsprodukten, und unabhängig vom Sitz des Herstellers.
Letzte Entwicklung: Die Single Reporting Platform der ENISA ist am Stichtag mit einer ersten Betriebsfähigkeit online gegangen; die Nutzungsbedingungen in der Fassung 1.0 datieren auf den 10. September. Damit ist der praktische Einwand der vergangenen Monate — die Plattform gibt es gar nicht — ausgeräumt. Der Umsetzungsstand in den Unternehmen bleibt der eigentliche Engpass: Nach der Bitkom-Erhebung können 29 Prozent einschätzen, was der CRA für sie bedeutet.
Management Summary
Der Tag wird von einem Vorfall bestimmt, der technisch unspektakulär und organisatorisch verheerend ist. Revolut hat bestätigt, dass Unbekannte an sensible Kundendaten gelangt sind, ohne ein einziges System anzugreifen: Sie schickten Auskunftsersuchen von einer E-Mail-Adresse auf einer legitimen Behördendomain über genau den Kanal, über den regulierte Unternehmen Ermittlungsanfragen beantworten. Herausgegeben wurden Identitäts- und Kontaktdaten, Kopien von Pässen und Führerscheinen, Verifizierungs-Selfies sowie Kontoauszüge und Transaktionshistorien einschließlich Bitcoin-Vorgängen. Revolut nennt weder die Behörde noch die Zahl der Betroffenen noch den Zeitraum und betont, Systeme und Kundengelder seien unberührt — was in der Sache stimmt und am Schaden nichts ändert. Der Angriffsweg ist seit Jahren unter dem Namen „Emergency Data Request“ bekannt und nutzt aus, dass dieser Prozess auf Geschwindigkeit ausgelegt ist. Für Verantwortliche folgt daraus eine unbequeme Prüffrage: Gibt es im eigenen Haus einen Weg, über den personenbezogene Daten auf Zuruf einer vermeintlichen Behörde herausgehen, und wird dabei die Identität des Anfragenden über einen zweiten Kanal verifiziert?
Regulatorisch ist der 11. September der wichtigere Einschnitt. Die Meldepflicht nach Artikel 14 des Cyber Resilience Act gilt seit Freitag, und die ENISA hat ihre Single Reporting Platform am selben Tag in Betrieb genommen — mit Nutzungsbedingungen, die einen Tag älter sind als der Stichtag. Damit steht die dreistufige Kaskade aus 24-Stunden-Frühwarnung, 72-Stunden-Meldung und Abschlussbericht in der Praxis. Sie trifft Hersteller von Produkten mit digitalen Elementen unabhängig von ihrem Sitz, erfasst auch bereits ausgelieferte Produkte und erstreckt sich nach Artikel 24 Absatz 3 auf Verwalter quelloffener Software, soweit diese an der Entwicklung solcher Produkte beteiligt sind. Die Bitkom-Erhebung unter 1.003 Unternehmen zeigt, wie groß die Lücke zwischen Rechtslage und Vorbereitung ist: 29 Prozent können die Bedeutung für das eigene Haus einschätzen, 28 Prozent kennen die Verordnung überhaupt nicht. Wer die 24-Stunden-Frist halten will, braucht keine Rechtsabteilung, sondern eine Stückliste seiner Software, einen automatisierten Abgleich gegen Schwachstellenkataloge und einen geprobten Meldeweg — Arbeit, die sich nicht im Ernstfall nachholen lässt.
Auf der Schwachstellenseite laufen heute zwei Behördenfristen ab, und beide Produkte sitzen an Stellen, an denen eine Kompromittierung weiterwandert. Die GitLab-Lücke CVE-2026-85706 erlaubt mit einer einzigen HTTP-Anfrage und ohne Anmeldung das Lesen beliebiger Dateien vom Server; einzige Voraussetzung ist, dass die Instanz mindestens ein öffentliches Projekt hostet. Betroffen sind die Fassungen 18.7 bis 19.3.1, korrigiert am 10. September in 19.1.8, 19.2.6 und 19.3.2. Dasselbe Sammelrelease schließt 18 weitere Lücken, darunter eine unsichere Deserialisierung im GraphQL-Serializer mit CVSS 9,9. Die ScreenConnect-Lücke CVE-2026-84869 sitzt im Client, nicht im Server, und hebelt die Bestätigungsabfrage bei Dateiübertragungen in laufenden Sitzungen aus. Huntress hat dazu drei unabhängige Vorfälle dokumentiert, in denen manipulierte Clients eine vierstufige VBScript-Kette automatisch an neu verbundene Endpunkte weiterreichten — wurmartiges Verhalten über Fernwartungsverbindungen, mit Dienstleistern als natürlichem Multiplikator.
Aufsichtsseitig ist die veröffentlichte Entscheidung der Woche die CNIL-Sanktion gegen das Beratungsunternehmen EXTIA über 300.000 Euro. Der Fall ist deshalb lehrreich, weil er keinen spektakulären Verstoß betrifft, sondern schlichte Bearbeitungsversäumnisse: Von 265 Löschanträgen des Jahres 2024 blieben zwölf komplett unbearbeitet, 166 Personen erfuhren nichts über den Ausgang, 27 wurden verspätet informiert. Die Behörde stellt klar, dass die tatsächliche Löschung — auch eine automatische — nicht von der Pflicht befreit, die betroffene Person fristgerecht zu unterrichten; beides sind eigenständige Verstöße. Ergänzend dazu markiert das Amtsgericht Heilbronn eine Grenze auf der Anspruchsseite: Wer wegen der Meta Business Tools klagt, aber nur formularmäßig einen Kontrollverlust behauptet und angeordnete Termine nicht wahrnimmt, verliert nicht nur den Prozess, sondern auch den Rechtsschutz für den Teil der Forderung, der 500 Euro übersteigt.
Die wichtigsten Punkte im Überblick
- Revolut: Herausgabe von Ausweiskopien, Selfies und Transaktionsdaten nach gefälschtem Behördenersuchen von einer echten Regierungsdomain; Zahl der Betroffenen und Zeitraum unbekannt.
- CRA: Meldepflicht nach Art. 14 seit 11.09.2026 in Kraft, ENISA-Plattform am selben Tag mit erster Betriebsfähigkeit online, Nutzungsbedingungen v1.0 vom 10.09.2026.
- Vorbereitungsstand: 29 Prozent von 1.003 befragten Unternehmen können die CRA-Folgen für ihr Haus einschätzen, 28 Prozent kennen die Verordnung nicht.
- GitLab CVE-2026-85706 (CVSS 10,0): unauthentifiziertes Lesen beliebiger Dateien, Fix seit 10.09.2026, Ausnutzung ab rund 20 Stunden danach, KEV-Frist heute.
- ScreenConnect CVE-2026-84869 (CVSS 9,9): Dateiübertragung und Ausführung ohne Host-Bestätigung, Fix 26.6.5, wurmartige Weitergabe über Sitzungen, KEV-Frist heute mit forensischer Triage.
- CISA-KEV vom 11.09.2026: fünf Einträge, zusätzlich JFrog Artifactory (Frist 25.09.) und MikroTik RouterOS (Frist war 13.09.); Katalog nun 1.709 Einträge.
- CNIL ./. EXTIA: 300.000 Euro für unbearbeitete und unbeantwortete Löschanträge; Löschung entbindet nicht von der Unterrichtungspflicht.
- AG Heilbronn 14 C 1593/26: Nichterscheinen trotz Ladung verletzt die Rettungsobliegenheit; Rechtsschutz für Meta-Klagen nur bis 500 Euro ohne individualisierten Vortrag.
Top-Risiken – Handlungsempfehlungen für heute
- Selbstverwaltete GitLab-Instanzen sofort auf 19.1.8, 19.2.6 oder 19.3.2 bringen und anschließend von einer Kompromittierung ausgehen: Runner-Token, CI-Variablen, Deploy-Keys, SSH-Schlüssel und Datenbankzugänge rotieren. Das Lesen einer einzigen Datei genügt, um Zugangsdaten abzuziehen — ein sauberer Patch allein stellt den Zustand vorher nicht wieder her.
- ScreenConnect: Server auf 26.6.5 oder neuer heben und anschließend die Clients erneuern. Der Fix sitzt im Client; Cloud-Instanzen laufen serverseitig bereits korrekt, die Endpunkte holen sich die Korrektur aber erst über eine Neuinstallation des Host-Clients beziehungsweise ein Update der Access-Agents. Bis dahin Dateiübertragung deaktivieren.
- ScreenConnect-Audit-Logs auf RunFiles- und RanFiles-Einträge mit Ausführung aus dem Kontext „Guest“ prüfen sowie auf einen Run-Key namens WindowsServiceHost, der auf eine VBS-Datei im AppData-Verzeichnis zeigt. Bestätigte Treffer bedeuten nach Einschätzung von Huntress Neuinstallation des Systems, keine Bereinigung.
- Den eigenen Auskunftsprozess für Behördenanfragen prüfen. Wer personenbezogene Daten auf behördliche Anfrage herausgibt, sollte die Identität des Anfragenden über einen zweiten, selbst gewählten Kanal bestätigen — Rückruf über die offizielle Telefonnummer der Behörde, nicht über Kontaktdaten aus der Anfrage. Eine korrekte Absenderdomain ist kein Nachweis.
- CRA-Meldefähigkeit herstellen, nicht nur planen: Zuständigkeit benennen, Konto auf der Single Reporting Platform anlegen und verifizieren lassen, Stückliste der ausgelieferten Software erzeugen, automatisierten Abgleich gegen KEV- und EUVD-Katalog einrichten und den Meldeweg einmal trocken durchspielen. Nicht verifizierte Konten sind in der Zahl der Meldungen begrenzt.
- MikroTik-RouterOS-Geräte gegenprüfen: Die Behördenfrist für die MikroTrick-Kette lief am 13. September ab. Betroffene Systeme sind auf 7.25 beta 3, 7.24.2, 7.23.4 oder 6.49.21 zu heben; Indikator für einen zurückliegenden Angriff ist ein angelegtes Konto namens „ops“.
- Beschäftigte auf die aktuelle ELSTER-Masche hinweisen. Der angebliche Registerdatenabgleich verlangt keine Zahlung, sondern Stammdaten und Bankverbindung — er passiert die üblichen Warnhinweise („fordert Geld“, „droht mit Sperrung“) deshalb unbeschadet.
1. Datenschutz
Das Kapitel wird heute von einem Vorfall geprägt, der die Grenzen technischer Schutzmaßnahmen zeigt, und von einer Pflicht, die seit Freitag läuft. Beides betrifft dieselbe Frage: Welche Prozesse geben Daten heraus, ohne dass jemand einbrechen muss.
1.1 Revolut gibt Kundendaten nach gefälschtem Behördenersuchen heraus
Zusammenfassung: Die britische Neobank Revolut hat am 12. September bestätigt, dass sie personenbezogene Kundendaten an einen unbefugten Dritten herausgegeben hat. Die Anfragen kamen von einer E-Mail-Adresse auf der Domain einer echten Behörde und liefen über den regulären Kanal, über den regulierte Unternehmen Auskunftsersuchen von Ermittlungsbehörden beantworten. Betroffen waren nach der Benachrichtigung, die Kunden erhalten haben, Geburtsdatum, Post- und E-Mail-Adressen sowie Telefonnummern, dazu Kopien von Identitätsdokumenten einschließlich Pässen und Führerscheinen; zusätzlich können Verifizierungs-Selfies, Kontoauszüge und Transaktionshistorien einschließlich Bitcoin-Vorgängen betroffen gewesen sein. Revolut hat die Adresse nach Erkennen des Betrugs gesperrt und die betreffende Behörde, Strafverfolgung, Datenschutzaufsicht und Finanzaufsicht informiert. Weder die Behörde noch die Zahl der Betroffenen noch der Zeitraum wurden offengelegt; das Unternehmen betont, Systeme und Kundengelder seien nicht betroffen.
Hintergrund & Einordnung: Der Angriffsweg ist als „Emergency Data Request“ seit Jahren dokumentiert und hat eine unangenehme Eigenschaft: Er greift nicht die Sicherheit an, sondern die Verfahrensregeln. Auskunftsersuchen von Strafverfolgungsbehörden müssen schnell beantwortet werden, oft ohne richterlichen Beschluss, und die Prüfung beschränkt sich in der Praxis häufig darauf, ob die Absenderdomain plausibel ist. Genau diese Prüfung hat hier funktioniert — und trotzdem versagt, weil die Domain tatsächlich einer Behörde gehörte. Ob das Konto kompromittiert oder die Domain anderweitig missbraucht wurde, ist offen. Der Ermittler ZachXBT, der die Kundenbenachrichtigung öffentlich gemacht hat, sieht Hinweise auf eine gezielte Auswahl vermögender Kunden; das würde zu einem Angriffsmuster passen, bei dem die erbeuteten Ausweisdokumente als Grundlage für Übernahmen von Konten bei anderen Anbietern dienen. Revolut hat nach eigenen Angaben mehr als 80 Millionen Kunden in über 30 Ländern.
Praxisfolgen / Handlungsempfehlung: Für europäische Verantwortliche ist der Fall unabhängig von der Branche verwertbar, weil jede Organisation, die Beschäftigten- oder Kundendaten führt, irgendwann behördliche Anfragen erhält. Drei Punkte sind zu prüfen. Erstens, ob die Identität des Anfragenden über einen selbst gewählten Rückkanal bestätigt wird — Rückruf über die offiziell veröffentlichte Nummer der Behörde, nicht über Kontaktdaten aus der Anfrage. Zweitens, ob die Herausgabe an eine Rechtsgrundlage gebunden ist, die dokumentiert wird, und ob sie auf das tatsächlich Verlangte begrenzt bleibt; die Bandbreite der hier herausgegebenen Daten — von Stammdaten bis zur vollständigen Transaktionshistorie — deutet auf eine Sammelauskunft hin. Drittens, wie lange Verifizierungsdokumente überhaupt vorgehalten werden: Selfies und Ausweisscans aus einer abgeschlossenen Identitätsprüfung sind Risiko ohne Nutzen, wenn sie nach der Prüfung nicht gelöscht werden. Betroffene Kundinnen und Kunden können ihre Ausweisdokumente nicht ändern — deshalb ist die realistische Schutzmaßnahme, mit gezielten Betrugsversuchen zu rechnen, die echte Kontodaten zitieren.
1.2 CRA-Meldepflicht in Kraft, ENISA-Plattform am Stichtag in Betrieb
Zusammenfassung: Seit dem 11. September 2026 gilt Artikel 14 der Verordnung (EU) 2024/2847. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in einer dreistufigen Kaskade melden: Frühwarnung binnen 24 Stunden nach Kenntniserlangung, technische Meldung mit erster Bewertung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme beziehungsweise binnen eines Monats nach der 72-Stunden-Meldung bei schweren Vorfällen. Gemeldet wird gleichzeitig an das koordinierende CSIRT und an die ENISA, und zwar einmalig über die Single Reporting Platform. Diese Plattform ist am 11. September mit einer ersten Betriebsfähigkeit unter portal.cra-srp.enisa.europa.eu online gegangen; die Nutzungsbedingungen in Fassung 1.0 datieren auf den 10. September, ein Factsheet liegt in neun Sprachen vor.
Hintergrund & Einordnung: Der Anwendungsbereich ist breiter, als der Begriff „Produkt“ nahelegt. Erfasst sind alle Produkte mit digitalen Elementen, die im Rahmen einer Geschäftstätigkeit auf dem Unionsmarkt bereitgestellt werden — vernetzte Hardware ebenso wie reine Software, einschließlich Datenfernverarbeitungslösungen. Der Sitz des Herstellers spielt keine Rolle, und die Pflicht gilt auch für Produkte, die längst ausgeliefert sind. Die Nutzungsbedingungen der Plattform benennen außerdem eine zweite Nutzergruppe, die in der öffentlichen Diskussion oft untergeht: Nach Artikel 24 Absatz 3 trifft die Meldepflicht des Artikels 14 Absatz 1 auch Verwalter quelloffener Software, soweit sie an der Entwicklung von Produkten mit digitalen Elementen beteiligt sind. Wer ein kommerziell genutztes Open-Source-Projekt betreut, sollte prüfen, ob er unter diese Definition fällt. Bis zuletzt war der Betrieb der Plattform der wunde Punkt der Regelung — im August hatte die ENISA lediglich Hinweise zur Schnittstelle für bevollmächtigte Vertreter veröffentlicht und dabei eine Obergrenze von zehn Meldungen für nicht verifizierte Konten genannt. Dieser Einwand ist erledigt; die Bewährungsprobe ist jetzt der erste reale Meldefall.
Praxisfolgen / Handlungsempfehlung: Die 24-Stunden-Frist ist keine Dokumentations-, sondern eine Erkennungsaufgabe. Sie beginnt mit der Kenntnis von der aktiven Ausnutzung — wer nicht weiß, welche Fremdbestandteile in seinen Produkten stecken, erlangt diese Kenntnis zu spät oder gar nicht. Konkret sind vier Dinge kurzfristig zu erledigen: eine benannte Zuständigkeit samt Vertretung, ein verifiziertes Konto auf der Plattform (die Verifizierung selbst kostet Zeit und lässt sich im Ernstfall nicht nachholen), eine fortgeschriebene Software-Stückliste für jedes ausgelieferte Produkt und ein automatisierter Abgleich dieser Stückliste gegen Ausnutzungskataloge wie KEV und EUVD. Der fünfte Punkt ist der, an dem die meisten scheitern: ein Probelauf. Eine Meldekette, die nie durchgespielt wurde, hält keine 24 Stunden. Zu beachten ist zudem, dass die CRA-Frist neben, nicht anstelle der DSGVO-Meldepflicht läuft — ein Vorfall kann beide auslösen, mit unterschiedlichen Fristen, Adressaten und Inhalten.
1.3 Bitkom: Sieben von zehn Unternehmen können den CRA nicht einordnen
Zusammenfassung: Zum Start der Meldepflicht hat der Branchenverband Bitkom eine repräsentative Erhebung veröffentlicht. Danach kennen 29 Prozent der Unternehmen in Deutschland die Bedeutung der Verordnung für das eigene Haus. Weitere 38 Prozent haben vom Regelwerk gehört, können dessen Folgen aber nicht einschätzen. Für 28 Prozent ist der Cyber Resilience Act vollständig unbekannt. Befragt wurden telefonisch 1.003 Unternehmen ab zehn Beschäftigten und mit mindestens einer Million Euro Jahresumsatz; die Erhebung lief von Kalenderwoche 16 bis 23 dieses Jahres.
Hintergrund & Einordnung: Der Erhebungszeitraum verdient Beachtung: Die Befragung endete Anfang Juni, gut drei Monate vor dem Stichtag. Ein Teil der Lücke dürfte sich seither geschlossen haben, weil die Fachpresse das Thema im Spätsommer aufgegriffen hat. Die Größenordnung bleibt trotzdem aussagekräftig, und sie deckt sich mit dem Eindruck aus der Beratungspraxis: Die Verordnung wird als Herstellerthema wahrgenommen, und viele Unternehmen sehen sich nicht als Hersteller. Das ist der eigentliche Irrtum. Wer eine Anwendung als Container-Image zum Selbstbetrieb an Kunden übergibt, stellt ein Produkt mit digitalen Elementen bereit — auch wenn das Kerngeschäft Dienstleistung heißt. Ein kompromittiertes Fremdpaket in einem ausgelieferten Image fällt in aller Regel unter den CRA.
Praxisfolgen / Handlungsempfehlung: Die erste Aufgabe ist keine technische, sondern eine Zuordnung: Prüfen, ob das eigene Haus für eines seiner Erzeugnisse Hersteller im Sinne der Verordnung ist. Dafür genügt die Frage, ob etwas Softwarehaltiges den Weg zum Kunden nimmt und dort betrieben wird. Fällt die Antwort positiv aus, sind Bestandsführung und Meldeweg aufzubauen, bevor die Produktanforderungen ab dem 11. Dezember 2027 greifen — die Meldepflicht ist die Vorstufe, an der sich zeigt, ob die Bestandsführung trägt. Wer hingegen nur fremde Produkte einsetzt, ist nicht meldepflichtig, sollte aber wissen, dass er künftig früher Herstellerinformationen erhalten dürfte, und seine eigenen Prozesse darauf einstellen.
2. Datensicherheit
Die beiden Vorfälle dieses Kapitels haben denselben Kern: Ein Zugang, der für einen legitimen Zweck offensteht, wird zum Datenabflusskanal. Einmal ist es eine Programmierschnittstelle, einmal eine Fernwartungsverbindung.
2.1 GitLab-Dateileselücke: Der eigentliche Schaden sind die Geheimnisse
Zusammenfassung: Über CVE-2026-85706 lässt sich mit einer einzigen HTTP-Anfrage und ohne Anmeldung eine beliebige Datei vom GitLab-Server lesen. Nach der Analyse von Kudelski Security genügt eine präparierte POST-Anfrage an den Endpunkt /api/v4/projects/{id}/repository/commits/ mit einer Pfadmanipulation im Parameter file.path. Die einzige Voraussetzung ist, dass die Instanz mindestens ein öffentliches Projekt hostet. Welche Daten abfließen, hängt von der Serverkonfiguration ab; in Betracht kommen Anwendungseinstellungen, Geheimnisse, Token, SSH-Schlüssel und Datenbankzugangsdaten — alles, worauf der GitLab-Prozess Lesezugriff hat.
Hintergrund & Einordnung: Eine Dateileselücke wirkt auf den ersten Blick harmloser als eine Codeausführung, ist in dieser Umgebung aber genauso folgenreich. GitLab-Instanzen sind Schlüsselbunde: Sie halten die Zugänge zu Produktionsumgebungen, Container-Registries, Cloud-Konten und Signaturschlüsseln, weil die Bereitstellungsketten von dort aus laufen. Wer eine Datei lesen kann, liest die Konfiguration — und hat damit Zugang zu Systemen, die mit GitLab selbst nichts zu tun haben. Genau deshalb ist die zeitliche Abfolge bemerkenswert: GitLab veröffentlichte die korrigierten Fassungen am 10. September, und das Honeypot-Netz von watchTowr registrierte rund zwanzig Stunden später die ersten Ausnutzungsversuche. Das ist der übliche Ablauf geworden — die Veröffentlichung des Patches ist zugleich die Veröffentlichung der Angriffsbeschreibung.
Praxisfolgen / Handlungsempfehlung: Patchen allein reicht nicht. Wer eine selbstverwaltete Instanz der Fassungen 18.7 bis 19.3.1 betreibt und nicht ausschließen kann, dass sie zwischen dem 10. und dem 14. September aus dem Internet erreichbar war, muss von einem Geheimnisabfluss ausgehen. Daraus folgt eine Rotationsliste: CI/CD-Variablen, Runner-Registrierungstoken, Deploy-Keys, persönliche und Projekt-Zugriffstoken, SSH-Host-Schlüssel, Datenbank-Zugangsdaten sowie alle in der Instanzkonfiguration hinterlegten Anbieter-Zugänge. Anschließend die Zugriffsprotokolle auf POST-Anfragen gegen den Commits-Endpunkt mit auffälligen Pfadangaben durchsuchen. GitLab.com und GitLab Dedicated sind nach Herstellerangaben nicht betroffen beziehungsweise bereits korrigiert.
2.2 Manipulierte ScreenConnect-Clients verbreiten sich über Fernwartungssitzungen
Zusammenfassung: Huntress hat Ende August drei kritische Vorfallsberichte für scheinbar unabhängige Organisationen erstellt, in denen manipulierte ScreenConnect-Instanzen auf Opfersystemen auftauchten. Der Erstzugang lief in allen drei Fällen über Social Engineering: ein Support-Betrug über die Windows-Schnellhilfe, ein per Phishing zugestellter MSI-Installer und ein gefälschtes Erstattungsformular eines Elektronikhändlers. Die manipulierten Clients starteten wiederholt wscript.exe, um die Dateien 1.vbs bis 4.vbs auszuführen. Das erste Skript legt in %TEMP%\value.txt einen dreistelligen Zustandswert an und prüft dafür, ob bereits ein ScreenConnect-Client installiert ist, welche Endpunktschutzlösung läuft und wie viel Arbeitsspeicher zur Verfügung steht; erkannt werden unter anderem Dienste von Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos und Malwarebytes. Systeme, auf denen nur der Windows-eigene Schutz läuft, erhalten eine andere Nutzlast.
Hintergrund & Einordnung: Die eigentliche Entdeckung ist die Verbreitungslogik. Die manipulierten Clients übertragen dieselben vier Skripte automatisch auf neu verbundene ScreenConnect-Endpunkte und führen sie dort aus — verbindet sich ein Host mit einem infizierten Client, kann er die Kette selbst empfangen und ausführen. Der Client merkt sich die jeweilige Verbindungskennung, um eine laufende Sitzung nicht erneut anzugreifen, verwirft sie aber beim Trennen, sodass eine Wiederverbindung die Infektion erneut auslöst. Für Dienstleister, die dieselbe Fernwartungsinstallation über viele Kundennetze hinweg einsetzen, ist das der denkbar schlechteste Ausbreitungsweg. Ein Detail am Rande verdient Beachtung: In einem der Skripte fand Huntress einen erklärenden Kommentar, der in Alltagssprache beschreibt, wie ein Schlüssel aus einer Konfigurationsdatei zu lesen ist — ein Muster, das für maschinell erzeugten Code spricht und sich in Schadsoftware zunehmend findet.
Praxisfolgen / Handlungsempfehlung: Zur Suche eignen sich die ScreenConnect-Audit-Protokolle: Einträge vom Typ RunFiles und RanFiles, in denen die genannten Skripte aus dem Kontext „Guest“ ausgeführt wurden, sind ein belastbares Signal. Als geteilter Persistenzindikator dient ein Run-Key namens WindowsServiceHost, der auf WindowsServiceHost.vbs im AppData-Verzeichnis des Nutzers zeigt; auf einigen betroffenen Systemen fanden sich zusätzlich andere Fernwartungswerkzeuge wie UltraViewer. An Infrastruktur wurden 45.13.237[.]190, 131.123.40[.]98:8041, 15.204.185[.]204 sowie borertors92.anondns[.]net beobachtet. Huntress empfiehlt bei bestätigtem Befall ausdrücklich eine Neuinstallation des Systems von vertrauenswürdigen Medien statt einer Bereinigung — angesichts der Tiefe und Verzweigung der Kette eine nachvollziehbare Einschätzung.
3. IT-Sicherheit
Die Patchlage des Tages besteht aus zwei Produkten mit ablaufenden Fristen und einem Katalogeintrag, der fünf Lücken auf einmal verbindlich macht.
3.1 CVE-2026-84869: Fix sitzt im Client, nicht im Server
Zusammenfassung: Die Lücke in ConnectWise ScreenConnect trägt CVSS 9,9 und besteht aus einer fehlerhaften Rechteverwaltung in Verbindung mit einer fehlenden Autorisierungsprüfung. Während einer aktiven Support- oder Zugriffssitzung können Dateien auf den Host übertragen und dort ausgeführt werden, ohne dass die Bestätigungsabfrage erscheint, die Bedienende erwarten — einschließlich Ausführungspfaden mit erhöhten Rechten. Betroffen ist ausschließlich der Client; ScreenConnect-Server sind nicht verwundbar. ConnectWise hat die Lücke am 8. September offengelegt und noch am selben Tag die Fassung 26.6.5 ausgeliefert. CISA nahm den Eintrag am 11. September in den Pflichtkatalog auf; die Frist für US-Bundesbehörden endet heute, verbunden mit der Anweisung zur forensischen Triage nach BOD 26-04.
Hintergrund & Einordnung: Dass der Fix im Client sitzt, ist die praktisch wichtigste Eigenschaft dieses Falls und zugleich die am leichtesten zu übersehende. Wer eine Cloud-Instanz betreibt, sieht serverseitig bereits die korrigierte Fassung und hält die Sache womöglich für erledigt — die Endpunkte laufen aber weiter mit dem verwundbaren Client, solange der nicht erneuert wurde. Für selbst betriebene Installationen gilt dasselbe in zwei Schritten: erst Server auf 26.6.5 oder neuer, dann Host-Clients neu installieren und Access-Agents aktualisieren. Bis das erledigt ist, empfiehlt der Hersteller, die Dateiübertragung zu deaktivieren. Die Dringlichkeit ergibt sich aus der Zielgruppe: Tausende Dienstleister betreuen mit ScreenConnect fremde Netze, was jede Kompromittierung sofort zu einem Lieferkettenrisiko macht.
Praxisfolgen / Handlungsempfehlung: Die Reihenfolge ist Server, dann Clients, dann Suche. Erst nach dem vollständigen Client-Austausch ergibt eine Bestandsaufnahme Sinn — vorher kann eine Bereinigung durch die nächste Sitzung rückgängig gemacht werden. Für die Suche gelten die Indikatoren aus dem vorigen Kapitel. Wer ScreenConnect nicht betreibt, aber Dienstleister mit Fernwartungszugang in seine Netze lässt, sollte heute nachfragen, welche Fassung dort läuft und wann die Clients erneuert wurden; die Frage ist berechtigt und kostet den Dienstleister zwei Sätze.
3.2 GitLab-Sammelrelease: 18 Lücken, darunter eine Deserialisierung mit 9,9
Zusammenfassung: Das Sicherheitsrelease vom 10. September schließt insgesamt 18 Lücken in GitLab CE und EE. Die Fassungen 19.1.8, 19.2.6 und 19.3.2 korrigieren neben der Dateileselücke CVE-2026-85706 (CVSS 10,0) unter anderem CVE-2026-87719 mit CVSS 9,9: eine unsichere Deserialisierung im Serializer für GraphQL-Subscriptions, über die ein angemeldeter Nutzer mit Zugriff auf die Chat-Funktion durch ein präpariertes Subscription-Argument an Konfigurationsdaten der erweiterten Suche und an sensible Zugangsdaten gelangen kann. Betroffen sind die Fassungen 18.7 bis 19.3.1. GitLab empfiehlt ein sofortiges Update; über 20.000 selbstverwaltete Instanzen gelten weiterhin als erreichbar.
Hintergrund & Einordnung: Der zweite Befund ist der unauffälligere und für viele Installationen der gefährlichere. Eine Lücke, die eine Anmeldung voraussetzt, wird in der Priorisierung oft nach hinten geschoben — in einer Entwicklungsumgebung mit hunderten Konten und offener Registrierung für Projektbeteiligte ist „angemeldet“ aber keine nennenswerte Hürde. Hinzu kommt, dass beide Lücken an Schnittstellen sitzen, die typischerweise nicht durch eine Web Application Firewall gefiltert werden, weil sie legitimen Automatisierungsverkehr tragen. Die Reihe der GitLab-Lücken der vergangenen Monate — zuletzt eine Code-Injektion über GraphQL, die ebenfalls nahezu sofort angegriffen wurde — legt nahe, dass die API-Oberfläche derzeit systematisch untersucht wird.
Praxisfolgen / Handlungsempfehlung: Beim Update nicht auf den nächsten Wartungstermin warten, sondern den Sprung auf die jeweilige Korrekturfassung des eigenen Zweigs vollziehen — 19.1.8, 19.2.6 oder 19.3.2. Anschließend prüfen, ob die Instanz überhaupt aus dem Internet erreichbar sein muss: Für viele Installationen ist eine Beschränkung auf das Firmennetz oder ein vorgelagerter Zugang die wirksamere Maßnahme als jeder einzelne Patch. Wer die Chat-Funktion nicht benötigt, sollte sie abschalten und damit die Angriffsfläche für CVE-2026-87719 entfernen.
3.3 CISA-KEV vom 11. September: fünf Einträge, drei Fristen
Zusammenfassung: Die amerikanische Cybersicherheitsbehörde hat am 11. September fünf Einträge aufgenommen. Neben ScreenConnect (CVE-2026-84869, CVSS 9,9, Frist 14.09.) betrifft das zwei Lücken in JFrog Artifactory — CVE-2026-42016 (CVSS 8,1, fehlerhafte Autorisierung mit Rechteausweitung) und CVE-2026-42018 (CVSS 7,5, unzureichende Authentifizierung, die unauthentifizierten Aufrufern ein internes Anonymous-Token zurückgibt), beide mit Frist 25. September — sowie zwei Lücken in MikroTik RouterOS: CVE-2026-67277 (CVSS 8,8) und CVE-2026-86060 (CVSS 9,2), verkettet in der als „MikroTrick“ bekannten Angriffssequenz, mit Frist 13. September. Die Katalogfassung 2026.09.11 umfasst damit 1.709 Einträge. Die GitLab-Lücke CVE-2026-85706 kam im selben Zeitraum mit Frist 14. September hinzu.
Hintergrund & Einordnung: Die beiden Artifactory-Lücken sind keine Neuentdeckung, sondern die Bestätigung einer Kette, die Sicherheitsforscher von Wiz bereits beschrieben hatten: Sie lassen sich mit der bekannten Authentifizierungsumgehung CVE-2026-82329 verbinden, um sich von außen bis zu Administratorrechten durchzuarbeiten. Die Aufnahme in den Katalog bedeutet, dass die Ausnutzung in freier Wildbahn belegt ist — für Betreiber ist das der Punkt, an dem aus „sollte gepatcht werden“ ein „ist wahrscheinlich bereits versucht worden“ wird. Bei MikroTik ist die Frist bereits abgelaufen; die Kette erlaubt bei erreichbarem SSH-Dienst die Übernahme ohne gültige Zugangsdaten.
Praxisfolgen / Handlungsempfehlung: Der Katalog eignet sich auch für Organisationen ohne US-Bezug als Priorisierungsliste, weil die Aufnahme an den Nachweis tatsächlicher Ausnutzung gebunden ist. Artifactory-Instanzen sind zu aktualisieren und die Anonymous-Zugriffseinstellung zu prüfen; die Rückgabe eines internen Tokens an nicht angemeldete Aufrufer wirkt auch dann, wenn der anonyme Zugang vermeintlich deaktiviert ist. Für RouterOS gelten die Fassungen 7.25 beta 3, 7.24.2, 7.23.4 und 6.49.21 als korrigiert; als Hinweis auf einen zurückliegenden Angriff dient ein neu angelegtes Konto namens „ops“ sowie Protokolleinträge der Form „login failure for user -2″.
4. Urteile
Die Entscheidung dieses Kapitels betrifft die Kehrseite der Massenklagen wegen Datenschutzverstößen: Was passiert, wenn der Kläger die eigenen Mitwirkungspflichten nicht erfüllt — und wer die Kosten dafür trägt.
4.1 Wer zum angeordneten Termin nicht erscheint, verliert den Rechtsschutz für den Mehrbetrag
Sachverhalt: Ein Mann hatte vor dem Landgericht Heilbronn gegen den Betreiber der Meta Business Tools geklagt und 5.000 Euro immateriellen Schadensersatz wegen des Kontrollverlusts über seine Daten verlangt. Das Landgericht wies die Klage vollständig ab — unter anderem, weil der Kläger trotz gerichtlich angeordneten persönlichen Erscheinens nicht zum Termin erschienen war und seinen Schaden in den Schriftsätzen nur formularmäßig beschrieben hatte. Gegen dieses Urteil legte er Berufung beim Oberlandesgericht Stuttgart ein und beantragte bei seiner Rechtsschutzversicherung Deckungsschutz. Die Versicherung lehnte ab. Der Kläger erhob daraufhin Feststellungsklage gegen das Schadensabwicklungsunternehmen seines Versicherers.
Entscheidung: Das Amtsgericht Heilbronn gab der Klage teilweise statt. Es stellte fest, dass Deckungsschutz für das Berufungsverfahren nur bezogen auf einen immateriellen Schadensersatzanspruch von 500 Euro besteht; im Übrigen wies es die Klage ab. Von den Kosten trägt der Kläger 90 Prozent, die Versicherung 10 Prozent. Die Berufung wurde zugelassen; das Urteil ist nicht rechtskräftig.
Begründungs-Kernpunkte: Das Gericht trennt zwei Fragen sauber voneinander. Zur Erfolgsaussicht nach § 3a ARB legt es einen an § 114 ZPO angelehnten Maßstab an und stellt auf die Bewilligungsreife der Deckungsanfrage ab — den Zeitpunkt, zu dem der Versicherung alle Informationen vorlagen, hier Dezember 2024. Zu diesem Zeitpunkt war die Rechtslage zum Schadensersatz wegen der Meta Business Tools noch offen, zusätzlich hatte eine kurz zuvor ergangene Leitentscheidung des Bundesgerichtshofs zu einem Scraping-Fall die Darlegungslast neu geprägt. Ein Anspruch von 5.000 Euro war daher vertretbar, die Erfolgsaussicht zu bejahen. Die zweite Frage entscheidet den Fall: Das unentschuldigte Fernbleiben trotz Anordnung nach § 141 ZPO wertet das Gericht als Verletzung der Rettungsobliegenheit nach § 82 Abs. 1 VVG — ein persönliches Erscheinen gehöre im Rechtsschutzprozess zu den Rettungspflichten, ein fehlendes Verschulden habe der Kläger nicht dargelegt. Nach § 82 Abs. 4 Satz 1 VVG trägt der Versicherungsnehmer die Beweislast dafür, dass die Obliegenheitsverletzung die Leistungspflicht nicht erhöht hat. Dieser Gegenbeweis gelang nur bis 500 Euro: Insoweit folgt das Gericht dem Oberlandesgericht Stuttgart (Urteil vom 29.04.2026, 4 U 353/24), wonach ein nicht weiter individualisierter Vortrag zum Kontrollverlust durch die Meta Business Tools keinen darüber hinausgehenden immateriellen Schadensersatz rechtfertigt.
Praxisfolgen: Die Entscheidung betrifft eine große Zahl laufender Verfahren, weil die Konstellation — Massenklage, standardisierter Schriftsatz, Kläger erscheint nicht — typisch ist. Für Betroffene ergeben sich zwei Konsequenzen. Erstens ist eine Ladung zum persönlichen Erscheinen keine Formalie, sondern der prozessuale Ort, an dem sich individueller Vortrag überhaupt erst herstellen lässt; wer fernbleibt, riskiert nicht nur den Prozess, sondern die Deckung für den Teil der Forderung, der den Sockelbetrag übersteigt. Zweitens verlangt ein Anspruch oberhalb von 500 Euro konkrete, eigene Schilderungen — zielgerichtete Werbeansprache nach dem Datenabfluss, auffällige Kontaktversuche Dritter, nachvollziehbare Belastungen —, die zeitnah dokumentiert sein sollten. Für Versicherer bestätigt das Urteil, dass sie die Deckung nicht pauschal wegen fehlender Erfolgsaussicht verweigern können, wenn die Rechtslage zum maßgeblichen Zeitpunkt offen war; der Hebel liegt in der Obliegenheitsverletzung, nicht in der Erfolgsprognose. Zu beachten bleibt, dass die obergerichtliche Linie uneinheitlich ist: Das OLG Hamm hat die Datenerhebung durch die Meta Business Tools für rechtswidrig erklärt, das OLG Stuttgart hat in einem anderen Verfahren 1.200 Euro zugesprochen. Die 500-Euro-Grenze ist daher kein Fixpunkt, sondern die Untergrenze für Vortrag ohne Substanz.
5. Bußgelder
Die im Berichtszeitraum veröffentlichte Entscheidung stammt aus Frankreich und betrifft keinen technischen Vorfall, sondern die Bearbeitung von Betroffenenanträgen — der Bereich, in dem Aufsichtsbehörden derzeit am zuverlässigsten fündig werden.
5.1 CNIL ./. EXTIA: 300.000 Euro, weil Löschanträge unbeantwortet blieben
Behörde: Commission Nationale de l’Informatique et des Libertés (Frankreich) · Adressat: EXTIA (Beratungsunternehmen, rund 2.000 Beschäftigte) · Höhe: 300.000 Euro
Verstoß / Rechtsgrundlage: Art. 12 und Art. 17 DSGVO — Modalitäten für die Ausübung der Betroffenenrechte und Recht auf Löschung.
Begründung: Die CNIL hatte 2024 mehrere Beschwerden ehemaliger Beschäftigter und abgelehnter Bewerber erhalten, die Schwierigkeiten bei der Ausübung ihres Löschrechts schilderten. Im April 2025 führte die Behörde eine Kontrolle durch, eingebettet in die vom Europäischen Datenschutzausschuss 2025 angestoßene koordinierte Aktion zum Recht auf Löschung. Von den 265 Löschanträgen, die das Unternehmen im Jahr 2024 erhalten hatte — überwiegend von Bewerbern —, waren mehr als drei Viertel nicht oder nicht zufriedenstellend bearbeitet worden. Im Einzelnen: Zwölf Anträge blieben vollständig unbearbeitet, 166 Personen wurden über den Ausgang ihres Antrags nicht informiert, 27 erhielten die Information erst nach Ablauf der Monatsfrist, teils mit Verzögerungen von mehreren Monaten. Bei der Bemessung berücksichtigte die Sanktionskammer die Missachtung wesentlicher Grundsätze des Betroffenenrechts, die Zahl der betroffenen Personen und den Umstand, dass das Unternehmen bereits zweimal an seine Pflichten erinnert worden war. Eine ursprünglich vorgesehene Anordnung entfiel, nachdem das Unternehmen die Herstellung des rechtmäßigen Zustands nachgewiesen hatte; ein zunächst erhobener Transparenzvorwurf nach Art. 13 DSGVO wurde im Verfahren fallengelassen. Die Veröffentlichung wurde angeordnet, der Name wird nach zwei Jahren anonymisiert.
Praxisfolgen: Die zentrale Aussage ist arbeitsökonomisch unbequem und rechtlich eindeutig: Die tatsächliche Löschung der Daten — auch durch einen automatischen Prozess — befreit nicht von der Pflicht, die betroffene Person innerhalb eines Monats über das Ergebnis ihres Antrags zu unterrichten. Nichtbearbeitung und Nichtunterrichtung sind zwei eigenständige Verstöße, die kumulativ geahndet werden können. Für Personalabteilungen ergibt sich daraus eine konkrete Prüfliste: Gibt es ein Eingangsregister für Betroffenenanträge, das auch Anfragen erfasst, die nicht über das dafür vorgesehene Formular kommen? Löst der Eingang eine Fristüberwachung aus? Wird die Antwort dokumentiert, und zwar auch dann, wenn die Daten ohnehin nach Ablauf der Aufbewahrungsfrist entfernt wurden? Bewerberdaten sind dabei der kritische Bestand, weil sie in großer Zahl anfallen, selten einem gepflegten Verzeichnis unterliegen und von Personen stammen, die zum Unternehmen keine fortdauernde Beziehung haben — und die deshalb eher den Weg zur Aufsichtsbehörde wählen. Der Hinweis auf zwei vorangegangene Ermahnungen zeigt außerdem, wie die CNIL die Wiederholung gewichtet.
6. Cyber-Sicherheit
Zwei Beiträge aus der Fachliteratur ordnen ein, was die Lage dieses Tages hervorgebracht hat: die technische Antwort auf die neue Meldepflicht und die Frage, was leistungsfähige Sprachmodelle an der Bedrohungslage tatsächlich verändern.
6.1 Die Build-Pipeline als Voraussetzung der Meldefähigkeit
Zusammenfassung: Der Beitrag beschreibt, was technisch nötig ist, um die 24-Stunden-Frist einhalten zu können, und setzt dabei am wunden Punkt moderner Softwareentwicklung an: Eine Node.js-Anwendung bezieht ihre Funktion aus einigen hundert bis weit über tausend npm-Paketen, von denen das Entwicklungsteam nur einen Bruchteil bewusst ausgewählt hat. Jedes dieser Pakete darf bei der Installation eigene Skripte ausführen — bei npm bis Version 11 standardmäßig und ungefragt. Als Antwort schlägt der Beitrag eine Kette vor: eine automatisierte Build-Pipeline, die für jedes Artefakt eine Software-Stückliste erzeugt, Signaturen über Sigstore anbringt und die Stücklisten in einer Bestandsplattform wie Dependency-Track führt, die laufend gegen Schwachstellen- und Ausnutzungskataloge abgleicht — darunter KEV und die europäische EUVD. Ergänzend werden Karenzzeiten für neu veröffentlichte npm-Pakete und Allowlists für Installationsskripte empfohlen.
Hintergrund & Einordnung: Die nüchterne Einschätzung des Beitrags ist die eigentliche Botschaft: Der technische Aufbau der Pipeline ist in wenigen Tagen erledigt; das eigentliche Projekt sind Bestandsführung, ein eingespielter Meldeprozess und ein Probelauf vor dem Ernstfall. Das deckt sich mit dem, was die Bitkom-Zahlen nahelegen — die Hürde ist nicht die Werkzeugauswahl, sondern die organisatorische Verankerung. Offen bleiben nach Darstellung des Autors die Randbedingungen: Tooling und die Verbreitung von VEX-Dokumenten, mit denen sich die Nicht-Betroffenheit von gemeldeten Schwachstellen maschinenlesbar erklären lässt, hinken hinterher. Wer diesen Aufbau jetzt macht, erledigt nebenbei einen Teil der Produktanforderungen, die ab Dezember 2027 gelten.
Praxisfolgen / Handlungsempfehlung: Für Häuser, die Software an Kunden übergeben, ist die Reihenfolge klar: zuerst wissen, was ausgeliefert wurde (Stückliste je Artefakt und Version, aufbewahrt, nicht nur erzeugt), dann wissen, wann etwas davon angegriffen wird (automatischer Abgleich statt manueller Sichtung), dann den Meldeweg üben. Die Karenzzeit für neue Paketversionen ist dabei die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung: Die meisten Kompromittierungen von npm-Paketen werden innerhalb weniger Tage entdeckt — wer neue Versionen erst nach einer Wartezeit übernimmt, fängt den Großteil ab, ohne Prozesse umzubauen.
6.2 Whitepaper: KI als Verstärker vorhandener Sicherheitsschulden
Zusammenfassung: Das Whitepaper der heise-Redaktion ordnet die Veränderungen ein, die leistungsfähige Sprachmodelle in der IT-Sicherheit auslösen. Kernthese: KI ist weder Ursache noch Lösung der aktuellen Lage, sondern ein Verstärker — für bestehende Sicherheitsschulden, für Angriffs- wie Verteidigungsfähigkeiten und für organisatorische Versäumnisse. Als Treiber benennt der Text die über Jahrzehnte angehäuften Schwachstellen in Soft- und Hardware: Sie zu finden und auszunutzen erforderte bislang hohen Aufwand und seltene, teure Fachkenntnis — kein verlässlicher Schutz, aber eine Hürde. Leistungsfähige Modelle senken diese Hürde, beschleunigen das Tempo und ermöglichen eine bislang unbekannte Skalierung. Als neue Angriffsflächen nennt das Papier Prompt Injection, autonome Agentensysteme, die folgenschwere Fehlentscheidungen treffen, bevor jemand eingreifen kann, sowie Datenabflüsse und Compliance-Verstöße durch nicht genehmigte KI-Nutzung.
Hintergrund & Einordnung: Der Rückblick des Papiers auf das erste Halbjahr 2026 liest sich als Chronik eines Kontrollproblems: Anthropics auf Schwachstellensuche spezialisiertes Modell erwies sich als so wirksam, dass der Zugriff zunächst auf wenige Unternehmen beschränkt blieb; Testende berichteten von einer Lawine gefundener Lücken. Im Juni untersagte die US-Regierung die weltweite Freigabe mit dem Argument, die Modelle bedrohten trotz eingebauter Sperren die nationale Sicherheit, und sperrte sie per Exportkontrolle für Nutzer ohne US-Staatsbürgerschaft — worauf der Anbieter beide Modelle vom Markt nahm und damit auch der NSA den Zugriff entzog; Ende Juni wurde eines davon wieder freigegeben. Für Sicherheitsverantwortliche steckt darin eine Lieferkettenfrage, die in keiner Risikomatrix steht: Ein Modell, auf dem eigene Erkennungs- oder Analyseprozesse aufsetzen, kann binnen Tagen aus politischen Gründen nicht mehr verfügbar sein.
Praxisfolgen / Handlungsempfehlung: Aus der Verstärker-These folgt eine unromantische Priorisierung: Wer seine Grundhygiene nicht im Griff hat — Bestandsführung, Patchgeschwindigkeit, Rechtevergabe —, verbessert seine Lage nicht dadurch, dass er KI-gestützte Erkennung einkauft; er verschiebt nur die Reaktionszeit auf einen Prozess, der ohnehin zu spät greift. Drei Maßnahmen sind unabhängig von der Modellwahl sinnvoll: die Nutzung generativer Werkzeuge im Haus erfassen, bevor sie zur Schatten-IT wird; für jeden Agenten, der Systemzugriff bekommt, eine Begrenzung der Rechte und eine Protokollierung vorsehen, die Nachvollziehbarkeit auch bei maschineller Geschwindigkeit erhält; und für Werkzeuge, die auf externe Modelle angewiesen sind, einen Rückfallweg definieren. Das Papier ist eine Einordnung für Entscheider, keine technische Anleitung — als Argumentationsgrundlage gegenüber der Geschäftsführung taugt es gut.
KI & große Sprachmodelle
Die Woche war bei den großen Anbietern ruhig; die Bewegung fand am Rand statt. Nach Anbietern geordnet:
- Anthropic: Claude Fable 5.1 ist seit dem 1. September ohne Vorschauphase auf allen Plattformen allgemein verfügbar und bleibt das Spitzenmodell für Programmierarbeit und langlaufende Agentenaufgaben; darunter steht Claude Opus 5 vom 24. Juli. Neue Ankündigungen gab es in der vergangenen Woche nicht.
- OpenAI: GPT-6 Astra ist seit dem 8. September allgemein verfügbar, nachdem es am 3. September zunächst für ausgewählte Organisationen freigeschaltet worden war. Die GPT-5.6-Stufen bleiben im Angebot. Sicherheitsrelevant bleibt die Einstufung des Modells auf der höchsten Stufe für Cyberfähigkeiten.
- Google: Gemini 3.8 Flash hat am 2. September den stabilen Status erreicht und ist damit die aktuelle Arbeitsversion für agentische Abläufe zu niedrigeren Kosten als die Spitzenmodelle.
- DeepSeek: Am 10. September erschien DeepSeek-V4.1-Flash — nach den Modell-Trackern die einzige Neuveröffentlichung eines größeren Anbieters in den sieben Tagen bis zum heutigen Montag.
- Sakana AI: Fugu Ultra v2.0 wurde am 11. September veröffentlicht.
- Mistral, Meta, xAI, Alibaba: keine Neuveröffentlichungen in der Berichtswoche. Aktueller Stand bleiben Mistral Medium 3.5 (28. April), Muse Spark 1.3 (2. September), Grok 4.6 (12. August) und Qwen3.8-Max (3. August).
Die Versions- und Datumsangaben dieses Abschnitts stammen aus öffentlichen Release-Trackern (llm-stats.com) und sind nicht durchgängig gegen Herstellerankündigungen abgeglichen; sie sind als Orientierung zu lesen, nicht als Beschaffungsgrundlage.
Sicherheitsrelevant war diese Woche weniger ein Release als eine Beobachtung: Der in einem der ScreenConnect-Skripte gefundene Erklärkommentar (siehe Kapitel 2) reiht sich in eine Serie von Funden ein, in denen sich maschinell erzeugter Code an seiner Selbstdokumentation erkennen lässt. Für die Erkennungsseite ist das eine Chance — Schadsoftware, die ihre Absichten in Alltagssprache kommentiert, liefert Signaturen, die es vorher nicht gab.
Ausblick / Termine
- Heute, 14.09.2026: Ende der CISA-Fristen für GitLab (CVE-2026-85706) und ConnectWise ScreenConnect (CVE-2026-84869); bei ScreenConnect zusätzlich forensische Triage nach BOD 26-04.
- 15.09.2026: Der in der laufenden easybank-Phishing-Welle genannte Termin für die angebliche Umstellung der Zwei-Faktor-Anmeldung — mit einer weiteren Zustellwelle ist zu rechnen.
- 25.09.2026: Ende der CISA-Frist für die JFrog-Artifactory-Lücken CVE-2026-42016 und CVE-2026-42018.
- 19.10.2026: Ablauf der Microsoft Windows Production PCA 2011, mit der der Windows-Bootloader signiert wird — Firmware- und Zertifikatsstand vorher prüfen.
- 11.12.2027: Beginn der allgemeinen Produktanforderungen des Cyber Resilience Act für Produkte, die ab diesem Datum neu auf den Unionsmarkt kommen.
Methodik
Stichtag dieser Ausgabe ist Montag, der 14. September 2026; berücksichtigt wurden Meldungen ab dem 10. September, für Gerichtsentscheidungen ein längerer Zeitraum ab Veröffentlichung der schriftlichen Entscheidung. Grundlage sind Primärquellen — Behörden- und Herstellerveröffentlichungen, Entscheidungen der Aufsichtsbehörden, Analysen der beteiligten Sicherheitsforscher — ergänzt um Fachmedien, wo die Primärquelle nicht öffentlich vorliegt. Jede Meldung ist über einen Deep-Link auf den konkreten Beitrag belegt. Drei Einträge des Quellenverzeichnisses sind bewusst keine Deep-Links, weil sie als laufend gepflegte Werkzeuge und nicht als Beleg einer einzelnen Meldung dienen: der KEV-Katalog der CISA, der Modell-Tracker und der Phishing-Radar der Verbraucherzentrale, die für ihre Einzelwarnungen keine dauerhaften Adressen vergibt. Zwei Einschränkungen sind offenzulegen: Der Volltext des Urteils des Amtsgerichts Heilbronn ist nicht frei zugänglich, weshalb sich die Darstellung auf eine ausführliche Fachbesprechung mit wörtlichen Zitaten aus den Entscheidungsgründen stützt. Eine im Umlauf befindliche Meldung zu einer Erpressungskampagne gegen mehrere europäische Unternehmen wurde nicht aufgenommen, weil die Quellseite weder über automatisierten Abruf noch über einen Browser zugänglich war und die Angaben damit nicht überprüfbar blieben. Dieses Briefing ersetzt keine Rechts- oder Sicherheitsberatung im Einzelfall.
Quellenverzeichnis
- TechCrunch: Revolut confirms customer data breach through fake government requests (12.09.2026)
- Borns IT- und Windows-Blog: Datenleck – Revolut gibt sensible Nutzerdaten an Angreifer (13.09.2026)
- ENISA: Single Reporting Platform (SRP)
- heise online: Gilt ab heute – CRA setzt 24-Stunden-Frist für Sicherheitsmeldungen (11.09.2026)
- BSI: Cyber Resilience Act
- Bitkom: Cyber Resilience Act – Nur 3 von 10 Unternehmen sind vorbereitet (11.09.2026)
- heise online (Ratgeber): Cyber Resilience Act – Pipeline für die CRA-Meldepflicht (08.09.2026)
- The Hacker News: GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure (11.09.2026)
- Kudelski Security: Critical GitLab Path Traversal Vulnerability Allows Unauthenticated Arbitrary File Read
- Horizon3: CVE-2026-85706 – GitLab Path Traversal
- Huntress: Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity
- The Hacker News: Rogue ScreenConnect Clients Spread Four-Stage VBScript Chain to Newly Connected Hosts (07.09.2026)
- Help Net Security: Attackers spread malware through ScreenConnect file transfers (07.09.2026)
- The Hacker News: CISA Adds 5 Actively Exploited Artifactory, ScreenConnect, and RouterOS Flaws to KEV (12.09.2026)
- CISA: Known Exploited Vulnerabilities Catalog
- CNIL: Non-respect des droits des personnes – sanction de 300 000 euros à l’encontre de la société EXTIA (09.09.2026)
- EDSA: Failure to respect the rights of individuals – The CNIL fined EXTIA 300 000 EUR
- internetrechtsiegen.de: Deckungsschutz für Berufung – Obliegenheitsverletzung kürzt auf 500 Euro (AG Heilbronn, 14 C 1593/26)
- Verbraucherzentrale: Phishing-Radar – Aktuelle Warnungen
- llm-stats.com: AI Updates – LLM Release Tracker
- CERT.at: Auslaufende Secure-Boot-Zertifikate – was ist, was kommt (17.06.2026)
