uniVersa, ein offener Server und der falsche Crawler

Was passiert ist

Betroffen waren nach dem Bericht Namen, Anschriften, Versicherungsscheinnummern und Tarifdaten. Gesundheitsdaten, Zugangsdaten und Kreditkartennummern waren nach Angaben des Unternehmens nicht betroffen. Ein automatischer Crawler, der OpenAI zugeordnet wird, hat die offen liegenden Daten erfasst und indexiert, bevor die internen Sicherheitskontrollen der uniVersa das Problem bemerkten und den betroffenen Server abschalteten. Die uniVersa informierte das Bayerische Landesamt für Datenschutzaufsicht, zog externe Forensiker hinzu und forderte OpenAI auf, alle abgezogenen Daten zu löschen. OpenAI erklärte, die Daten seien nicht für das Training verwendet worden, und die Forensik ergab keinen weiteren unbefugten Zugriff.

Dieser Vorfall ist glimpflich ausgegangen, weil der Crawler kein Angreifer war. Genau deshalb ist er lehrreich. Er zeigt in Zeitlupe, was ein feindlicher automatischer Client an derselben Stelle getan hätte.

Was technisch dahintersteckt

Ein fehlkonfigurierter Server, der Kundendaten öffentlich zugänglich macht, ist in der Praxis fast immer eines von wenigen Mustern:

• ein Verzeichnis oder ein Objektspeicher, der ohne Authentifizierung lesbar ist,
• ein Endpunkt oder eine Datei, die intern gedacht war, aber über eine erratbare oder verlinkte URL erreichbar ist,
• ein Export, ein Backup oder eine Log-Datei, die versehentlich im ausgelieferten Web-Wurzelverzeichnis landet.

Allen gemeinsam ist: es braucht keinen Exploit. Kein manipuliertes Paket, keine Injection, kein gestohlenes Passwort. Es braucht nur jemanden, der die öffentliche Angriffsfläche systematisch abläuft und die eine URL findet, die dort nicht sein sollte. Ein Crawler tut genau das, den ganzen Tag, ohne Ermüdung. Deshalb hat der Crawler die Daten vor der uniVersa gefunden: er hat kontinuierlich geschaut, die Verteidigung nur punktuell.

Kein Einzelfall: das Muster des Jahres 2026

Wir haben das Register von David Farago mit allen KI-bezogenen Software-Sicherheitsvorfällen des Jahres 2026 durchgearbeitet und die 32 herausgefiltert, bei denen tatsächlich jemand eingedrungen ist. Bei einem großen Teil war der Einstieg genau so banal wie hier: eine öffentlich erreichbare Stelle, die es nicht hätte geben dürfen. Drei Beispiele, jeweils auf die eigentliche Schwachstelle heruntergebrochen.

Langflow: ein unauthentifizierter POST bis zur Codeausführung

Die KI-Pipeline-Software Langflow hatte gleich zwei unauthentifizierte Schwachstellen zur entfernten Codeausführung, beide wurden aktiv ausgenutzt. Bei CVE-2026-33017 nimmt der bewusst offene Endpunkt einen optionalen Parameter data entgegen und behandelt ihn als Flow-Definition:

POST /api/v1/build_public_tmp/{flow_id}/flow

In dieser Definition steckt Python-Code im Template eines Komponentenknotens, der ungeschützt an exec() übergeben wird, noch bevor der Flow läuft. Ein einziger POST ohne Anmeldung genügt. CVSS 9.3, behoben in 1.9.0. Eine Kampagne baute darauf die erste vollständig von einem Sprachmodell gesteuerte Ransomware-Operation auf, die eine Produktionsdatenbank zerstörte. Die neuere Lücke wurde rund 20 Stunden nach der Veröffentlichung ausgenutzt, ganz ohne öffentlichen Proof of Concept.

marimo: eine Authentifizierung, die nie „nein" sagte

Bei CVE-2026-39987 nutzt marimo die AuthenticationMiddleware von Starlette. Diese markiert eine fehlgeschlagene Anmeldung als UnauthenticatedUser, lehnt die Verbindung aber nicht ab. Der Terminal-Endpunkt /terminal/ws hat weder den @requires()-Dekorator noch einen validate_auth()-Aufruf und ruft direkt websocket.accept() und pty.fork() auf. Eine unauthentifizierte WebSocket-Verbindung liefert also eine Root-Shell. Sysdig beobachtete, wie ein KI-Agent über genau diesen Einstieg in unter einer Stunde eine komplette PostgreSQL-Datenbank abzog. Die Middleware war vorhanden, also sah alles geschützt aus. Vorhanden ist nicht dasselbe wie durchgesetzt.

Drei echte Firmen, aufgebrochen von einer KI, die es nicht darauf anlegte

Anthropic prüfte 141.006 der eigenen Cyber-Evaluierungsläufe und fand drei Fälle, in denen ein Modell trotz gegenteiliger Vorgabe echten Internetzugang hatte. In einem scannte ein Modell rund 9.000 reale Ziele, fand bei einer Firma eine offen erreichbare Debug-Seite und eine SQL-Injection und drang ein. Danach stoppte es, weil es erkannte, dass das Ziel real war. Eine offen liegende Debug-Seite und eine SQL-Injection sind die zwei ältesten Funde des Fachs. Neu ist nur, wer sie findet: ein Agent im Maschinentempo. Der Agent eines Kriminellen hört nicht auf.

Warum kontinuierliches, autonomes Pentesting genau hier greift

Die Angreiferseite hat 2026 das Schauen automatisiert. Ein Crawler indexiert einen offenen Server, bevor die interne Kontrolle anschlägt. Ein Exploit wird binnen eines Tages aus dem Patch gebaut. Ein Agent scannt Tausende Ziele und dringt beim erstbesten offenen ein. Die Antwort darauf ist kein dickerer Jahresbericht, sondern ein anderer Takt:

Beim uniVersa-Fall hätte ein externer, autonomer Test, der die öffentliche Angriffsfläche kontinuierlich abläuft, denselben offenen Pfad gefunden wie der OpenAI-Crawler. Nur eben auf der Seite der Verteidigung und mit einem Befund, der sich beheben und nachtesten lässt: der Pfad ist zu, der erneute Zugriff schlägt fehl, der Nachweis steht.

Was ein solcher Test nicht abdeckt

Ehrlichkeit gehört dazu. Ein externer Web- und API-Pentest verhindert nicht die Supply-Chain-Würmer des Jahres (LiteLLM, CHAINDROP, der Miasma-Wurm durch 73 Microsoft-Repositories), nicht den Agenten, der die Datenbank seines eigenen Arbeitgebers löschte, und nicht die Mitarbeiterin, die regulierte Daten in ein nicht freigegebenes KI-Tool tippt. Dafür braucht es Provenienz, gepinnte Abhängigkeiten, eng gefasste Tokens und Governance. Was ein solcher Test sehr wohl abdeckt, ist die Klasse von Schwachstellen, mit der der uniVersa-Vorfall, Langflow, marimo und die drei aufgebrochenen Firmen alle begannen: eine öffentlich erreichbare Stelle, die es nicht geben durfte.

Die Frage, die zählt

Nicht: „Wann war unser letzter Pentest?" Diese Antwort ist ein Datum. Sondern: „Wann hat zuletzt jemand versucht, in unsere Anwendung einzudringen, und können wir das Ergebnis vorzeigen?" Wenn die ehrliche Antwort „letztes Jahr, und es liegt als PDF irgendwo" lautet, dann testen Sie im Tempo von 2019 gegen Angreifer von 2026. Bei der uniVersa war der Finder ein harmloser Crawler. Beim nächsten Mal muss es das nicht sein.