Meta Muse GhostShares: Chat-Titel landeten in DNS-Daten

Mehr als 6.800 geteilte Konversationen mit dem KI-Agenten Muse von Meta waren über eine einzige Abfrage in einer kommerziellen Passive-DNS-Datenbank auffindbar – der Fall ist als Meta Muse GhostShares bekannt geworden. Betroffen sind alle, die einen Muse-Chat per Link weitergegeben haben: Die Share-Seiten waren bewusst ohne Login erreichbar, geschützt allein durch eine Zufalls-ID in der Adresse. Die Sharing-Funktion ist inzwischen pausiert.

Meta Muse GhostShares: Eine Abfrage, über 6.800 Einträge

Passive DNS funktioniert wie ein Adressbuch mit Gedächtnis: Resolver-basierte Dienste protokollieren, welche Hostnamen weltweit aufgelöst werden, und machen diese Historien durchsuchbar. Die Abfrage erfolgte auf genau dieses Archiv. Nach dem Herausfiltern irrelevanter Einträge blieben über 6.800 Share-Hostnames von Muse übrig. Von diesen Seiten wurden einige hundert geöffnet – ohne Account, rein passiv, ohne Adressen zu raten oder zu erzwingen. Eine passwortgeschützte Seite wurde ausgelassen.

Der Kontext macht den Fund brisanter: Muse ist Metas KI-Agent, seit dem 8. September 2026 verfügbar, und kann im Netz recherchieren, E-Mails versenden, Reisen buchen und Dokumente erstellen. Wer solche Aufgaben an einen Agenten delegiert, füttert ihn zwangsläufig mit internen Zahlen, Terminen und Personalthemen. Diese Inhalte landen dann im Gesprächsverlauf – und mit einem Klick im Share-Link.

Warum der Chat-Titel im Hostnamen zum Problem wird

Der eigentliche Fehler steckt im URL-Aufbau. Muse bildet die Share-Adresse aus einem kurzen Titel der Konversation plus einer zufälligen ID, gehostet unter cf.metaaiusercontent.com. Ein dokumentiertes Beispiel lautet home-sale-budget-9f21c8a3.cf.metaaiusercontent.com. Weil der Hostname den Gesprächstext trägt und der Link dieselbe ID verwendet, lässt sich aus einem erbeuteten Hostname der vollständige Link rekonstruieren – im Klartext: ein Hostname aus dem DNS baut den Share-Link wieder zusammen.

Damit fällt jene Schutzschicht weg, auf die sich Link-Sharing typischerweise verlässt. Eine Zufalls-ID schützt nur, solange sie geheim bleibt; ein Hostname ist nicht geheim, weil jeder Browser ihn beim Seitenaufruf auflösen muss. Die Share-Seiten waren absichtlich ohne Authentifizierung erreichbar – das war das Design, nicht ein Fehler bei der Auslieferung. Zusätzlich sind mehr als 75 gespeicherte Aufrufe von Muse-Share-Seiten dokumentiert. Neben gezielten Abfragen tragen also auch automatisierte Scanner solche Adressen in öffentliche Archive.

Welche Inhalte offenlagen – und wie viele

Die Mehrheit der geöffneten Seiten war harmlos: Kleingeschäfts-Websites, Anzeigen, Event-Kalender. Eine Minderheit enthielt jedoch Material, das niemand für die Öffentlichkeit vorgesehen hatte. Dokumentiert sind unter anderem eine interne Umsatz-Review eines Marketingunternehmens an den CEO, ein Kreditantrag eines Kleinunternehmers mit beantragter Summe, eine Bankbetrugswarnung mit Teil-Kontonummer und Betrag sowie ein Urlaubskalender mit Dutzenden Mitarbeitenden. Hinzu kommen ein Finanzbericht eines Immobilieninvestors mit Adressen und Renditekennzahlen sowie Vorbereitungsnotizen für einen vertraulichen Executive-Search-Call mit einem Frontier-KI-Labor, inklusive internem Kontakt und Termin.

Die Beispiele sind ohne Namen und Links veröffentlicht, das Muster heißt „GhostShares": Seiten, die Menschen erreichen, denen niemand den Link geschickt hat. Hinweise auf eine tatsächliche Ausnutzung der Daten fanden sich nicht. Wie viele der 6.800 Hostnames wirklich Vertrauliches enthielten, bleibt offen – geöffnet wurde nur ein Bruchteil.

Was Meta bestätigt – und was Claroc-Angabe bleibt

Der Meldeweg ist datiert: Der Befund ging am 8. Oktober 2026 über Metas Bug-Bounty-Programm ein. Daraufhin wurde die Sharing-Funktion pausiert. Nutzer können spezifische Muse-Artefakte teilen, wodurch eine Seite entsteht, die jeder mit dem Link aufrufen kann. Die Funktion ist pausiert: „we’ve paused this functionality while we review this report and consider changes to how these links can be discovered“ – eine unabhängig geprüfte Zusage über den künftigen URL-Aufbau ist das nicht.

Die Abschaltung wirkt: Bei einer Nachprüfung am 20. Oktober 2026 öffnete keiner von 40 zuvor erreichbaren Links mehr, auch die zugehörigen Content-Hosting-Adressen lieferten Fehler. Die Hostnames samt Gesprächstexten bleiben allerdings in der Passive-DNS-Historie stehen – gelöscht ist der Link, nicht das Leck der Titel. Die Zahl „über 6.800“ beruht auf einer Auswertung; das Ausmaß wurde nicht öffentlich bestätigt. Ein technischer Fix für den URL-Aufbau und ein Termin für eine Reaktivierung sind nicht bekannt.

Handlungsempfehlung: Share-Links als Datenabfluss behandeln

Für Admins ist der Fall kein Meta-Problem, sondern ein Muster. Drei konkrete Schritte:

Eigene Agenten und Produkte prüfen. Keine Nutzerinhalte in Subdomains. Share-Tokens gehören in den Pfad oder in authentifizierte Freigaben mit Ablaufzeit, nicht in einen Hostnamen, der in DNS-Logs und Scan-Archiven landet.
Muse-Links inventarisieren. Wer Muse im Unternehmen testet, sollte geteilte Links sammeln, deren Inhalte als exponiert behandeln und Betroffene informieren. Proxy- und DNS-Logs der letzten Wochen zeigen, welche Share-Hostnames intern aufgerufen wurden.
Policy nachziehen. Freigabe-Links aus KI-Agenten sind Datenexporte. Sie brauchen dieselbe Regelung wie Cloud-Freigaben: keine Kundendaten, keine Personalthemen, Vier-Augen-Prinzip bei Finanzinhalten.

Ob kommerzielle Passive-DNS-Anbieter Einträge auf Antrag löschen, ist offen – verlassen sollte man sich darauf nicht. Wer vertrauliche Inhalte in einen KI-Chat gibt, muss damit rechnen, dass die Frage nicht lautet, ob der Link weitergegeben wird, sondern wann er in einem Archiv auftaucht. Der belastbare Schutz liegt deshalb vor dem Teilen, nicht danach.

Quellen