Du teilst einen Link zu einem KI-Chat. Er taucht nicht in Suchmaschinen auf, die Adresse enthält eine zufällige Zeichenfolge – also sieht es so aus, als könnte kein Fremder sie finden. Trotzdem entdecken Sicherheitsforscher mehr als 6.800 solcher Adressen mit einer einzigen Suche in DNS-Daten. Ohne die Zeichenfolgen zu erraten, ohne einen Server zu hacken und ohne ein Konto bei dem Dienst. Genau das war das Problem bei der Freigabefunktion von Meta Muse.

Am 18. Oktober 2026 veröffentlichte das Team von Claroc seinen Bericht „GhostShares“. Am 20. Oktober folgte eine wichtige Ergänzung: Meta hatte die Freigabe von Unterhaltungen vorerst gestoppt. Diese Geschichte handelt zwar von KI, doch die eigentliche Schwachstelle hat weder mit Halluzinationen noch mit Prompt Injection zu tun. Es geht um den Aufbau von Webadressen und um einen fatalen Denkfehler: Ein schwer zu erratender Link ist noch lange keine echte Zugriffsbeschränkung.

Mehr als 6.800 Adressen, aber nicht 6.800 bestätigte Datenlecks

Muse, der persönliche KI-Agent von Meta, startete am 8. September 2026. Nutzer konnten damit unter anderem Inhalte erstellen und Ergebnisse aus einer Unterhaltung teilen. Wer den Agenten um einen Link bat, erhielt eine Freigabeadresse. Jeder, der diese Adresse kannte, konnte die entsprechende Seite ohne Anmeldung öffnen.

WebsiteGarage / Leistungen

Entdecke unsere Leistungen.

Die Forschenden von Claroc durchsuchten eine kommerzielle Passive-DNS-Datenbank, in der zuvor beobachtete Domainnamen erfasst werden. Nachdem sie zufällige Treffer aus automatisierten Scans herausgefiltert hatten, blieben mehr als 6.800 Hostnamen, die zu geteilten Muse-Inhalten gehörten. Jeder Hostname stand für eine eigene Freigabeseite. Das Team öffnete davon nur einige Hundert. Die meisten enthielten harmlose oder alltägliche Inhalte, manche jedoch Informationen, die man kaum auf einer frei zugänglichen Website erwarten würde.

Der Unterschied ist entscheidend: 6.800 bezeichnet die gefundenen Adressen, nicht 6.800 vertrauliche Dokumente, Betroffene oder bestätigte Datenschutzverletzungen. Auch ist nicht bekannt, wie viele Muse-Freigaben außerhalb dieser Datenbank existierten. Und nur weil eine Adresse in Passive-DNS-Daten auftaucht, heißt das nicht, dass jemand den Inhalt bereits missbraucht hat.

Claroc beschrieb sechs Kategorien besonders sensibler Inhalte. Darunter waren eine interne Umsatzanalyse für den Geschäftsführer eines Unternehmens, ein Kreditantrag für einen kleinen Betrieb, ein Plan für einen Immobilienverkauf, eine Notiz zu einer Bankwarnung mit einem Teil einer Kontonummer und ein Jahresurlaubsplan von Beschäftigten. Eine weitere Seite betraf die vertrauliche Vorbereitung auf ein hochrangiges Bewerbungsgespräch bei einem Unternehmen, das an fortgeschrittener KI arbeitet.

Dabei geht es nicht nur um Beträge oder Namen. Manchmal ist schon die Information brisant, dass bestimmte Personen ein nicht öffentliches Treffen planen, selbst wenn der Rest des Dokuments überwiegend aus öffentlich bekannten Fakten besteht. Solches Wissen kann Identitätsbetrug, das Vortäuschen einer Beteiligung an dem Gespräch oder besonders glaubwürdige Phishing-Angriffe erleichtern.

Die Autoren veröffentlichten bewusst keine echten Adressen, Dokumenttitel oder Angaben, mit denen sich Betroffene identifizieren ließen. Das werden wir ebenfalls nicht tun. Wer auf eine Datenschutzlücke aufmerksam macht, muss nicht auch noch zur Verbreitung fremder vertraulicher Informationen beitragen.

Dazu kurz die technische Grundlage: DNS sorgt dafür, dass dein Browser den Server zu einem Namen wie www.example.com findet. Bei einer DNS-Abfrage wird der Hostname übermittelt, nicht der Inhalt der Website und auch nicht der gesamte URL-Pfad.

Bei Muse wurden der Titel einer geteilten Unterhaltung und eine zufällige Zeichenfolge Teil des Hostnamens unter einer Domain, über die die freigegebenen Inhalte bereitgestellt wurden. Vereinfacht sah das so aus: privat-zufaeligezeichenfolge.example.com. Das ist eine frei erfundene Beispieladresse, kein Link zu einem echten Chat. Der Name verriet bereits etwas über den möglichen Inhalt. Und ausgerechnet die zufällige Kennung stand in dem Teil der Adresse, der bei DNS-Abfragen sichtbar wird.

Wenn jemand eine solche Freigabeseite öffnete, musste sein Gerät den Hostnamen per DNS auflösen. Manche Dienste erfassen beobachtete DNS-Antworten und machen diese Daten später durchsuchbar. Das nennt man Passive DNS. Das bedeutet nicht, dass sämtliche DNS-Anfragen aller Internetnutzer in einer einzigen weltweiten Datenbank landen. Es reicht, wenn ein Anbieter den betreffenden Hostnamen beobachtet und seine Daten durchsuchen lässt.

Wer die entsprechende Passive-DNS-Datenbank durchsuchte, fand den vollständigen Hostnamen einschließlich der zufälligen Kennung. Niemand musste sie knacken oder erraten. Anschließend konnten die Forschenden die zugehörige Freigabeseite ohne Anmeldung aufrufen. Eine zufällige Zeichenfolge schützt nur, solange sie tatsächlich unbekannt bleibt.

Warum half robots.txt nicht?

Muse versuchte mit einer robots.txt-Datei zu verhindern, dass Suchmaschinen die geteilten Inhalte indexieren. Das ist sinnvoll, um das Crawling und die Indexierung zu steuern. Eine Zugangssperre ist es aber nicht. robots.txt prüft nicht, wer eine Seite aufruft, und verhindert auch keinen Zugriff, wenn jemand die Adresse bereits kennt.

Claroc musste dafür nicht einmal bei Google nach Muse-Unterhaltungen suchen. Die Forschenden nutzten DNS-Daten, die mit der Indexierung von Websites nichts zu tun haben. Außerdem fanden sie bei urlscan.io mehr als 75 gespeicherte Scans von Muse-Freigabeseiten. Auch über solche Dienste können öffentlich erreichbare Adressen leichter auffindbar werden.

Für noindex gilt im Grunde dasselbe: Die Anweisung kann verhindern, dass eine Suchmaschine eine Seite in den Ergebnissen anzeigt. Sie verhindert aber nicht, dass jemand die Inhalte direkt öffnet. Google Search Central unterscheidet ausdrücklich zwischen der Steuerung der Indexierung und dem Schutz vertraulicher Inhalte. Soll etwas nur für berechtigte Personen zugänglich sein, braucht es eine echte Zugriffskontrolle und keine Bitte an Suchmaschinen-Bots.

Ein Sicherheitsvorfall, aber kein Einbruch in Metas Systeme

Die Nutzer hatten die Freigabefunktion selbst verwendet, und Muse erstellte daraufhin eine öffentlich zugängliche Seite. Das Problem war, dass sich diese Seiten viel leichter in großer Zahl aufspüren ließen, als die scheinbar unvorhersehbaren Adressen vermuten ließen. Laut Bericht war es weder nötig, eine Anmeldung zu umgehen noch eine Serverlücke auszunutzen oder ein Konto zu übernehmen.

Damit wurden tatsächlich einzelne Informationen offengelegt, zugleich sind die Erkenntnisse klar begrenzt. Die Forschenden konnten vertrauliche Inhalte im normalen Browser öffnen, ohne den Link vom ursprünglichen Nutzer erhalten zu haben und ohne sich anzumelden. Es gibt aber keine Belege dafür, dass Kriminelle diese Adressen genutzt oder mit den Daten Betrug begangen haben. Von einer nachgewiesenen Datendiebstahlkampagne kann deshalb keine Rede sein.

Die Chronologie: Meldung, Veröffentlichung und Metas Reaktion

  • 7. bis 8. Oktober 2026: Claroc prüfte die Erreichbarkeit und die Inhalte der untersuchten Freigabeseiten.
  • 8. Oktober: Die Forschenden meldeten das Problem über Metas Programm zur Meldung von Sicherheitslücken.
  • 18. Oktober: Der erste GhostShares-Bericht wurde veröffentlicht.
  • 20. Oktober: Nach einer Anfrage von Ars Technica erklärte Meta, die Freigabefunktion vorübergehend auszusetzen und zu prüfen, wie die Links auffindbar werden konnten. Claroc testete am selben Tag 40 zuvor erreichbare Seiten erneut. Keine davon ließ sich noch öffnen.

Gegenüber Ars Technica bestätigte Meta, die Funktion während der Prüfung des gemeldeten Problems ausgesetzt zu haben. Stand 21. Oktober lag damit weder ein vollständiger Ursachenbericht vor noch war ein dauerhaft überarbeitetes Freigabeverfahren angekündigt. Der Test mit 40 Links zeigt, dass die von Meta bereitgestellten Seiten in diesen Fällen nicht mehr erreichbar waren. Er belegt nicht, dass sämtliche Spuren der Adressen verschwunden sind.

Die Hostnamen und damit auch darin enthaltene Gesprächsthemen blieben in historischen Passive-DNS-Daten bestehen. Auch das sollte man sich merken: Wer den Zugriff auf Inhalte sperrt, holt damit nicht automatisch alle zuvor veröffentlichten Informationen zurück.

Das betrifft längst nicht nur KI-Assistenten. Ähnliche Freigaben gibt es für Projektvorschauen, Rechnungen, PDF-Angebote, Cloud-Dateien, Staging-Websites und Unterlagen für Kunden. Bevor du eine solche Adresse als sicher betrachtest, solltest du ein paar konkrete Fragen stellen.

  • Wer kann die Seite öffnen? Muss man angemeldet sein, eine Berechtigung für das Dokument besitzen oder ein Passwort eingeben? Oder reicht allein der Link?
  • Was verrät die Adresse? Stehen im Hostnamen, im URL-Pfad oder im Titel Kundennamen, Beträge, Projektdetails oder andere Informationen, die nicht öffentlich sein sollten?
  • Lässt sich der Link sperren? Der Zugriff sollte widerrufen werden können. Bei vertraulichen Inhalten ist außerdem ein sinnvoller Ablaufzeitpunkt wichtig.
  • Was passiert nach dem Ausloggen? Öffne den Link in einem privaten Browserfenster oder mit einem anderen Konto. Das ist ein einfacher Funktionstest, ersetzt aber keine Sicherheitsprüfung.
  • Wo könnte die Adresse noch auftauchen? Prüfe, ob Analytics, eingebundene Skripte, Linkvorschauen, Protokolldateien oder Website-Scanner den Link erfassen oder weitergeben.
  • Braucht die andere Person wirklich den gesamten Chat? Oft ist eine kurze Zusammenfassung ohne vertrauliche Ausgangsdaten die bessere Wahl.

Was tun, wenn dein Unternehmen bereits vertrauliche Daten über KI geteilt hat?

Zuerst solltest du klären, welche Informationen tatsächlich geteilt wurden, mit wem und wie lange sie erreichbar waren. Bietet die Plattform die Möglichkeit, eine Freigabe zu löschen oder einen Link zu widerrufen, nutze sie. Bei Passwörtern, API-Tokens und Zugriffsschlüsseln reicht das Entfernen einer Seite allerdings nicht: Die betreffenden Zugangsdaten müssen geändert beziehungsweise widerrufen werden.

Enthielt das Material Daten von Kunden oder Mitarbeitern, muss das Unternehmen Umfang und Folgen der Offenlegung nach seinen Datenschutzprozessen prüfen. Nicht jede öffentlich auffindbare Adresse löst automatisch dieselben gesetzlichen Pflichten aus. Entscheidend sind Art der Daten, Risiken für die Betroffenen und die tatsächlichen Umstände. Falls nötig, sollte eine für Datenschutz zuständige Person oder ein Rechtsbeistand hinzugezogen werden.

Bei einer neuen Freigabefunktion sollten Zugriffsrechte von Anfang an Teil der Lösung sein und nicht als kosmetisches Extra zum Schluss dazukommen. Auch ein kleines WordPress-Modul zum Austausch von Kundendateien muss klar zwischen öffentlichen und privaten Inhalten unterscheiden und prüfen, wer was öffnen darf. Geht es um eine klar begrenzte Funktion in einer bestehenden Website, lässt sich das im Rahmen von [link WordPress Development Sprint] planen. Größere Kundenportale oder Systeme mit unterschiedlichen Benutzerrollen brauchen dagegen einen eigenen Projektumfang.

Die wichtigste Lehre reicht weit über KI hinaus

Meta Muse hat in diesem Fall nicht eigenmächtig fremde Daten veröffentlicht. Das System führte den Freigabewunsch des Nutzers aus. Durch die technische Umsetzung waren die öffentlich erreichbaren Adressen anschließend leichter zu finden als gedacht. Ein alter Konstruktionsfehler in neuem Gewand: Das System verwechselt fehlende Sichtbarkeit in Suchmaschinen mit Privatsphäre.

Wer eine neue „Teilen“-Funktion entwickelt, sollte deshalb nicht nur fragen, wie schnell ein Link erzeugt wird. Wichtiger ist, wer ihn finden kann, welche Informationen er verrät und wie sich der Zugang wieder entziehen lässt. Für die Sicherheit ist nicht die Länge einer zufälligen Zeichenfolge entscheidend, sondern der gesamte Umgang mit den Informationen.

Quellen und Grenzen der Untersuchung

Stand: 21. Oktober 2026. Die mehr als 6.800 beziehen sich auf Hostnamen aus einer einzigen Passive-DNS-Datenbank, nicht auf bestätigte Lecks vertraulicher Dokumente. Einzelne sensible Inhalte waren ohne Anmeldung im Browser erreichbar. Für einen kriminellen Missbrauch gibt es jedoch keine Belege. Meta setzte die Freigabefunktion aus. Die historischen Hostnamen blieben in externen Datenbeständen erhalten.