uniVersa: OpenAI-Crawler erbeutet Kundendaten über offenen Server

Veröffentlicht am 28.07.2026

Ein einzelner falsch konfigurierter Server, wenige Stunden ohne Zugriffsschutz im offenen Internet – und schon greift ein automatischer KI-Crawler tausende Kundendatensätze ab. Genau das ist Anfang Juli bei den uniVersa-Versicherungen passiert. Betroffen sind Namen, Adressen, Versicherungsnummern, Tarifinformationen und bei einem Teil der Kunden sogar Bankverbindungen (IBAN und BIC). Der Fall zeigt eindrücklich, wie schnell aus einer Routine-Umstellung in der IT eine meldepflichtige Datenpanne wird – ganz ohne Hackerangriff.

Was ist passiert?

Am 7. Juli 2026 führten die uniVersa-Versicherungen (bestehend aus uniVersa Lebensversicherung a. G., uniVersa Krankenversicherung a. G. und uniVersa Allgemeine Versicherung AG mit Sitz in Nürnberg) eine IT-Umstellung durch. Dabei geriet ein Server, der eigentlich nur für den automatisierten Datenaustausch mit Vertriebspartnern gedacht war, durch einen Konfigurationsfehler versehentlich ohne jeden Zugriffsschutz ins öffentliche Internet.

In genau diesem kurzen Zeitfenster von wenigen Stunden entdeckte der Web-Crawler GPTBot des US-Unternehmens OpenAI den frei zugänglichen Server und rief die dort liegenden Daten ab. Ein Web-Crawler ist ein automatisches Programm, das das Internet durchsucht und Inhalte einsammelt – GPTBot sammelt öffentlich erreichbare Webinhalte für das Training von KI-Modellen.

Es handelte sich also nicht um einen gezielten Cyberangriff, sondern um eine klassische Fehlkonfiguration (englisch „Misconfiguration“). Der Server war schlicht ohne Passwort, ohne Zugriffsbeschränkung auf bestimmte IP-Adressen und ohne Firewall-Regel erreichbar. Der GPTBot musste keine Sicherheitslücke ausnutzen – die Tür stand einfach offen.

Entdeckt wurde der Vorfall durch interne Sicherheitskontrollen bei uniVersa selbst. Der öffentliche Zugang wurde umgehend gesperrt, externe IT-Forensiker (Spezialisten für die Aufklärung von IT-Sicherheitsvorfällen) wurden eingeschaltet, und uniVersa kontaktierte OpenAI mit der Forderung, die abgerufenen Daten zu löschen und nicht zu verwenden.

Welche Daten sind betroffen?

Laut uniVersa lagen auf dem Server strukturierte Kundenstamm- und Vertragsdaten. Konkret betroffen waren:

• Allgemeine personenbezogene Daten: Name, Anschrift, Geburtsdatum, Geschlecht, Beruf, Telefonnummer, E-Mail-Adresse
• Vertragsdaten: Versicherungsnummer, Tarif, Versicherungssumme
• Bankverbindungsdaten (bei einem Teil der Kunden): IBAN und BIC
• Bei Kfz-Versicherungen: Fahrzeugdaten wie Kennzeichen und Herstellernummer
• Bei Schadenversicherungen: Schadennummer, Schadenursache, Schadenhöhe

Eine Unternehmenssprecherin von uniVersa erklärte gegenüber heise online:

„Auf dem betroffenen Server lagen allgemeine personenbezogene Daten etwa Namen und Anschriften sowie Vertragsdaten wie Versicherungsnummern und Tarifinformationen. Bei einigen Kunden sind auch Bankverbindungsdaten (IBAN und BIC) betroffen. Nicht betroffen waren besonders sensible Informationen wie Gesundheits-, Login- oder Kreditkartendaten und die zentralen Verwaltungs- und Datensysteme sowie das Kundenportal.“

Das ist die gute Nachricht: Gesundheitsdaten, Login-Zugangsdaten und Kreditkartendaten waren nicht betroffen. Auch die zentralen Verwaltungssysteme und das Kundenportal blieben unberührt. Die genaue Anzahl der betroffenen Kunden hat uniVersa bislang nicht öffentlich genannt – die Bayerische Datenschutzaufsicht (BayLDA) verwies auf laufende Untersuchungen.

Hat OpenAI die Daten verwendet?

Nach eigenen Angaben nein. Am 25. Juli 2026 bestätigte OpenAI gegenüber uniVersa, dass die vom Crawler abgerufenen Daten nicht für das Training von KI-Modellen genutzt wurden. uniVersa teilte gegenüber dem Fachmagazin AssCompact mit:

„OpenAI hat nach unserer unverzüglichen Kontaktaufnahme bereits bestätigt, dass die von ihrem automatisierten Web-Crawler abgerufenen Daten nicht für Trainings ihrer KI-Modelle genutzt wurden und stellt sicher, dass dies auch in Zukunft nicht passiert.“

OpenAI selbst betonte, nicht für die Sicherheitslücke bei uniVersa verantwortlich zu sein – der Crawler habe lediglich einen offen zugänglichen Server erfasst. Ein vollständiges Ausschließen einer späteren, indirekten Nutzung ist aus Sicherheitsperspektive dennoch nicht mit letzter Gewissheit möglich, weshalb betroffene Kunden wachsam bleiben sollten.

So prüfen Sie, ob Sie betroffen sind

Wenn Sie Kunde bei einer der uniVersa-Gesellschaften sind, gehen Sie folgende Schritte durch:

1. Prüfen Sie Ihre Post. uniVersa versendet seit dem 20. Juli 2026 schriftliche Informationsschreiben an betroffene Kunden. Haben Sie ein solches Schreiben erhalten, sind Ihre Daten mit hoher Wahrscheinlichkeit betroffen.
2. Fragen Sie aktiv nach. Kontaktieren Sie den uniVersa-Kundenservice und stellen Sie einen Auskunftsantrag nach Art. 15 DSGVO – dieser Artikel gibt Ihnen das Recht zu erfahren, ob und welche Ihrer Daten betroffen sind.
3. Kontrollieren Sie Ihre Kontobewegungen. Prüfen Sie Kontoauszüge und Lastschriften auf ungewöhnliche Abbuchungen – besonders, wenn Ihre IBAN/BIC betroffen sein könnte.
4. Seien Sie wachsam bei Kontaktversuchen. Achten Sie auf ungewöhnliche E-Mails (Phishing), Anrufe (Vishing) oder Briefe, die sich auf Ihre Versicherungsverträge beziehen.

Das müssen Sie als Betroffener jetzt tun

Der Präsident der Bayerischen Datenschutzaufsicht, Michael Will, gibt betroffenen Personen eine klare Empfehlung:

„Potenziell Betroffene sollten unter anderem Passwörter ändern, Konto- und Kreditkartenbewegungen kontrollieren sowie bei ungewöhnlichen E-Mails, Anrufen oder Briefen besonders vorsichtig sein. Bei Verdacht auf Betrug empfiehlt die Behörde, Anzeige zu erstatten.“

Konkret:

1. Behalten Sie Ihre Kontoauszüge über die nächsten Monate im Auge.
2. Reagieren Sie besonders skeptisch auf Nachrichten, die sich auf Ihre Versicherung beziehen und Sie zur Preisgabe weiterer Daten oder zu Zahlungen auffordern. Angreifer könnten mit Versicherungsnummern und Tarifdaten sehr glaubwürdige Betrugsszenarien konstruieren.
3. Informieren Sie im Zweifel Ihre Bank über das potenzielle Risiko im Zusammenhang mit Ihrer IBAN.
4. Bei konkretem Verdacht auf Missbrauch: Erstatten Sie Anzeige bei der Polizei.

Der technische Hintergrund – verständlich erklärt

Der Kern des Problems war eine fehlende Zugriffsabsicherung. Server, die Daten mit Partnern austauschen, sollten niemals direkt aus dem offenen Internet erreichbar sein. Üblicherweise werden sie über ein VPN (verschlüsselter Zugang, nur für berechtigte Nutzer), über IP-Whitelisting (Zugriff nur von zuvor festgelegten Adressen) oder über eine separate, abgeschottete Netzwerkzone (DMZ) geschützt.

Im uniVersa-Fall fehlten diese Schutzmechanismen für einige Stunden. Der GPTBot respektiert zwar grundsätzlich die Datei robots.txt – eine Textdatei, mit der Website-Betreiber Crawlern mitteilen, welche Bereiche sie nicht durchsuchen sollen –, doch hier existierte keine solche Sperre. Wichtig zu verstehen: robots.txt ist ein höfliches Verbotsschild, kein Schloss. Der eigentliche Schutz muss auf Netzwerkebene erfolgen.

Für den Vorfall wurde übrigens keine CVE-Nummer (eine standardisierte Kennung für Software-Schwachstellen) vergeben – schlicht, weil es keine Software-Lücke gab, sondern einen menschlichen Konfigurationsfehler. Solche Fehlkonfigurationen von Servern und Cloud-Speichern gehören laut dem renommierten Verizon Data Breach Investigations Report regelmäßig zu den Top-5-Ursachen für Datenschutzverletzungen.

Die DSGVO-Einordnung: Auch ohne Hacker haftet man

Der Fall ist ein Lehrstück in Sachen Datenschutz-Grundverordnung. Rechtsanwältin Nursel Orhan bringt den entscheidenden Punkt auf den Punkt:

„Ein Datenleck stellt regelmäßig eine Pflichtverletzung der verantwortlichen Stelle dar. Verantwortliche müssen personenbezogene Daten durch geeignete technische und organisatorische Maßnahmen schützen (Art. 32 DSGVO). Auf ein Verschulden oder einen gezielten kriminellen Angriff kommt es für einen Anspruch nach Art. 82 DSGVO nicht an: Auch eine versehentliche Offenlegung kann Ansprüche auslösen.“

Konkret greifen hier mehrere DSGVO-Pflichten:

• Art. 33 – Meldepflicht: Eine Datenpanne muss der Aufsichtsbehörde möglichst binnen 72 Stunden gemeldet werden. uniVersa hat gemeldet, die BayLDA bestätigte den Eingang.
• Art. 34 – Benachrichtigung Betroffener: Bei hohem Risiko (hier: Bank- und Vertragsdaten) müssen die Betroffenen direkt informiert werden – das geschieht seit dem 20. Juli 2026.
• Art. 32 – Technische und organisatorische Maßnahmen: Die fehlende Serverabsicherung verstößt gegen die Pflicht, angemessene Schutzmaßnahmen zu treffen.
• Art. 82 – Schadensersatz: Betroffene können immaterielle Schäden geltend machen. Der Bundesgerichtshof hat mit Urteil vom 18. November 2024 (Az. VI ZR 10/24) entschieden, dass bereits der bloße Kontrollverlust über die eigenen Daten einen ersatzfähigen immateriellen Schaden begründen kann.

Interessanterweise veröffentlichte der Europäische Datenschutzausschuss (EDPB) exakt am Tag des Vorfalls, dem 7. Juli 2026, seine „Guidelines 03/2026 on web scraping in the context of generative AI“ – erstmals verbindliche Anforderungen an Betreiber von KI-Crawlern. BayLDA-Präsident Will betonte mit Blick darauf:

„Vor einem Datenabruf mittels Web-Crawling müssen Verantwortliche unter anderem technische und organisatorische Filtermechanismen implementieren, um nicht erforderliche Datenkategorien von vornherein auszuscheiden und strukturell sensible Quellen gar nicht erst in die Sammlung einzubeziehen.“

Was KMU und Website-Betreiber daraus lernen müssen

Dieser Fall betrifft nicht nur Versicherungskonzerne. Jeder, der personenbezogene Daten verarbeitet, unterliegt denselben Pflichten – und jede Fehlkonfiguration kann meldepflichtig sein. Diese Schritte sollten Sie umsetzen:

1. Change-Management etablieren: Führen Sie bei jeder IT-Umstellung oder Migration eine verpflichtende Sicherheitsprüfung durch, die explizit Zugriffsrechte und Erreichbarkeit aller Server kontrolliert – vor und nach der Änderung.
2. Netzwerksegmentierung: Server für den Datenaustausch mit Partnern dürfen nie direkt aus dem Internet erreichbar sein. Sichern Sie sie über VPN, IP-Whitelisting oder eine DMZ ab.
3. Authentifizierung erzwingen: Für jeden Server mit personenbezogenen Daten gehören starke Authentifizierung (API-Keys, OAuth 2.0, Zertifikate) und rollenbasierte Zugriffskontrollen (RBAC) zum Standard.
4. KI-Crawler blockieren: Pflegen Sie eine aktuelle robots.txt und blockieren Sie bekannte KI-Crawler (etwa „User-agent: GPTBot / Disallow: /“). Denken Sie daran: Das schützt nur öffentliche Webserver, nicht interne Systeme.
5. Monitoring einrichten: Überwachen Sie ungewöhnliche Zugriffsmengen und unbekannte User-Agents in Echtzeit (etwa über eine Web Application Firewall oder ein SIEM-System, das Sicherheitsereignisse zentral auswertet).
6. Datenschutz-Folgenabschätzung (DSFA): Führen Sie vor IT-Umstellungen mit Personenbezug eine DSFA nach Art. 35 DSGVO durch.
7. Incident-Response-Plan: Halten Sie einen dokumentierten Reaktionsplan bereit, der die 72-Stunden-Meldefrist berücksichtigt und Zuständigkeiten klar regelt.
8. Regelmäßige Scans: Prüfen Sie Ihre eigenen IP-Bereiche mit Tools wie Shodan, Censys oder nmap auf versehentlich offene Endpunkte – besonders nach Migrationen.

Die Zahlen zeigen den Trend

Datenpannen nehmen zu. 2025 wurden den deutschen Datenschutzbehörden 10.259 Datenpannen gemeldet – ein deutlicher Anstieg gegenüber 8.623 im Jahr 2024. Bayern, Sitz der uniVersa, verzeichnete mit 1.500 gemeldeten Pannen den zweithöchsten Wert aller Bundesländer.

Dass die DSGVO Zähne hat, zeigen die Bußgeldzahlen: 2025 wurden in Deutschland 249 Bußgelder mit einer Gesamtsumme von rund 46,9 Mio. Euro verhängt. Das höchste einzelne Bußgeld traf mit 45 Mio. Euro die Vodafone – wegen unzureichender Authentifizierungsprozesse. Und dass auch verspätete Meldungen sanktioniert werden, zeigte bereits 2020 ein Bußgeld von 450.000 Euro gegen Twitter/X. Der theoretische Rahmen ist beträchtlich: Bußgelder können bis zu 20 Mio. Euro oder 4 % des weltweiten Jahresumsatzes betragen.

Fazit

Der uniVersa-Vorfall ist kein spektakulärer Hackerangriff, sondern das Ergebnis eines menschlichen Fehlers während einer IT-Umstellung – und genau das macht ihn so lehrreich. Es brauchte keine kriminelle Energie, nur eine offene Tür und einen automatischen Crawler, der zufällig vorbeikam.

Für betroffene uniVersa-Kunden gilt: Prüfen Sie Ihre Post, kontrollieren Sie Ihre Kontobewegungen und bleiben Sie wachsam bei verdächtigen Kontaktversuchen. Ein akuter Missbrauch ist bislang nicht bekannt, und OpenAI hat die Nicht-Nutzung der Daten zugesichert – dennoch ist gesunde Skepsis angebracht.

Für Unternehmen und Website-Betreiber ist die Botschaft unmissverständlich: Sicherheit ist kein einmaliges Projekt, sondern muss bei jeder Änderung mitgedacht werden. Ein sauberer Change-Management-Prozess, konsequente Netzwerksegmentierung und regelmäßige externe Scans hätten diesen Vorfall verhindert. Wer personenbezogene Daten verarbeitet, haftet – auch ohne Vorsatz, auch ohne Angriff. Die BayLDA-Untersuchung ist noch nicht abgeschlossen; die endgültige Bewertung steht damit noch aus.