Meta’s Muse Chat Delen Functie Blootstelt Chats aan Publieke Zoekopdrachten

Muse, Meta’s AI-chatapp, explodeerde op de markt met meer dan 10,9 miljoen downloads in slechts 40 dagen, volgens Sensor Tower-statistieken gerapporteerd door TechCrunch. Maar nu ligt de focus op een opvallend privacyprobleem. Claroc, een beveiligingsbedrijf dat zich richt op AI-gerelateerde risico's, ontdekte dat Muse-chats die via een link werden gedeeld door iedereen konden worden ontdekt die openbare internetrecords doorzocht—zelfs als de afzender dacht dat alleen geselecteerde mensen ze zouden zien.

The Verge meldt dat Meta de deelfunctie van Muse heeft gepauzeerd terwijl ze dit probleem oplossen.

Meta heeft de groei van Muse niet aan het toeval overgelaten. Ze hebben 39% van hun advertentiebudget voor oktober in de app gestoken, met als doel vertrouwen op te bouwen en snel gebruikers te werven. Maar wanneer je zo snel opschaalt—vooral voor een tool die zowel voor gewone mensen als bedrijven is gepositioneerd—wordt elke slip op het gebied van privacy versterkt.

Gevoelige inhoud in de verkeerde handen is altijd een risico, maar vooral met het beoogde publiek van Muse.

Hoe Muse Delen Werkt—en Wat Er Fout Ging

Muse laat gebruikers chatgesprekken omzetten in unieke webpagina's, toegankelijk voor iedereen met de link—geen inlogwanden. Dat is een standaardstrategie voor AI-chatapps die samenwerking willen bevorderen. Maar de aanpak van Muse omvatte zowel de titel van de chat als een willekeurige code in het webadres.

Dus, als je een chat "Q3 budget review" noemde, zou de URL eruitzien als q3-budget-review-4d7a19e2—alles op een door Meta beheerd domein.

Elke keer dat iemand een gedeelde Muse-chat opende, voerde hun browser een DNS-lookup uit voor het adres. Passieve DNS-diensten registreren deze lookups stilletjes, en iedereen met toegang kan de adressen doorzoeken en ophalen. Zo ontdekte Claroc meer dan 6.800 Muse-deel-URL's, met duidelijke chat-titels die in feite de inhoud indexeerden.

Het willekeurige deel van de URL was bedoeld om de links moeilijk te raden te maken, maar dat deed er niet toe—omdat het hele adres, inclusief de willekeurige code, in openbare logs terechtkwam zodra iemand het bezocht.

De diepgaande analyse van Claroc toonde aan dat deze URL's niet alleen theoretisch blootgesteld waren—ze werden actief geïndexeerd door passieve DNS-databases. Dus, iedereen die vastberaden was (of de juiste automatisering had) kon gedeelde Muse-chats opsporen en opsommen zonder ooit de originele link nodig te hebben. Met chat-titels direct in het adres was het zelfs gemakkelijker om chats met mogelijk gevoelige materialen te spotten.

Het merendeel van wat Claroc vond was vrij alledaags—kleine bedrijfswebsites, evenementenagenda's. Maar sommige URL's onthulden veel gevoeliger gegevens:

  • Privé-aantekeningen van een sollicitant voor een gesprek met een toonaangevend AI-lab, compleet met interne contacten en vergadertijden
  • Een interne omzetbeoordeling van een marketingbedrijf, gemarkeerd voor de CEO
  • Een aanvraag voor een kleine zakelijke lening waarin het leenbedrag werd onthuld
  • Een vakantieschema voor het personeel van een heel jaar met tientallen werknemers

Deze variëteit—van HR-notities tot strategische bedrijfsplanning—toont aan dat het risico op blootstelling niet beperkt is tot één soort gegevens of bedrijf. Als jouw team samenwerkende chattools gebruikt, kun je getroffen worden.

Claroc heeft het probleem op 8 oktober gemeld aan het bug bounty-programma van Meta. Ze vonden geen bewijs van misbruik, en de chats werden alleen openbaar omdat gebruikers ze deelden. Toch besloeg de beoordeling van Claroc slechts één DNS-service, één type adres en een specifieke periode.

De werkelijke reikwijdte kan zelfs breder zijn—Claroc vond 27 nieuwe deel-URL's op hun laatste dag van controle, dus mensen bleven delen terwijl de controle toenam.

Gevolgen voor Bedrijven en Professionals

Deze zaak benadrukt een harde waarheid voor iedereen die vertrouwt op AI-gestuurde samenwerking: alleen omdat een link "niet vermeld" is, betekent dat niet dat het privé is. Voor bedrijven is dit geen hypothetisch risico—de bevindingen van Claroc omvatten vertrouwelijke interne documenten die iedereen zou kunnen tegenkomen.

Stel je een manager voor die een Muse-chat deelt met een concept bedrijfsplan of een lijst van aanstaande ontslagen, in de veronderstelling dat alleen de ontvangers het zullen zien. Als die link slechts één keer wordt geopend, kan het adres (en misschien de inhoud) in een openbaar DNS-log terechtkomen, ontdekbaar door iedereen met de juiste tools. Dat is een serieuze zorg voor bedrijven die gevoelige klantgegevens, HR-gegevens of eigendomsplannen beheren.

Het probleem wordt verergerd omdat veel gebruikers—en zelfs IT-professionals—niet weten hoe passieve DNS-logging werkt. In tegenstelling tot je typische webserver, waar de serviceprovider de toeganglogs beheert, worden passieve DNS-records bewaard door derden en kunnen ze door iedereen met toegang worden doorzocht. Dus, het verwijderen van een Muse-chat of het intrekken van een link achteraf lost het probleem niet noodzakelijk op—het adres kan nog steeds ergens rondzweven, en iemand kan de informatie tijdens het blootstellingsvenster hebben gekopieerd.

Er is ook een ander risico: het plaatsen van de chat-titel in de URL. Dat is handig voor gebruikers, maar riskant als de titel onthult waarover wordt gesproken. Een concurrent of kwaadwillende actor zou kunnen scannen op titels zoals "Q3 budget review" of "fusieplanning"—ze zouden de pagina zelfs niet hoeven te openen om waardevolle informatie te verkrijgen.

Praktische Stappen om Gedeelde Inhoud te Beschermen

  • Deel geen gevoelige informatie via openbare of niet-vermelde links—vooral als er geen inlog vereist is.
  • Herzie je deelbeleid voor AI- en cloud-samenwerkingstools. Zorg ervoor dat medewerkers het verschil tussen "niet vermeld" en "privé" begrijpen.
  • Houd een oogje in het zeil voor onbedoelde lekken door openbare DNS-records voor je eigen inhoud te doorzoeken of beveiligingstools te gebruiken. Beveiligingsteams moeten controleren op lekken, vooral na het uitrollen van nieuwe apps.
  • Train medewerkers over de risico's van "niet-vermelde" links en waarom obscuriteit geen echte beveiliging is. Gebruik echte voorbeelden om het punt duidelijk te maken.
  • Blijf op de hoogte van updates van leveranciers over beveiligingsproblemen of functie wijzigingen. Meta heeft het delen van Muse gepauzeerd—let op toekomstige updates of patches.

Bovenop dat, overweeg technische controles in te voeren. Blokkeer bijvoorbeeld niet-geauthenticeerd delen in zakelijke omgevingen, vereis wachtwoorden voor gedeelde links, of implementeer DLP-tools om gevoelige gegevens te onderscheppen en te stoppen voordat ze onzorgvuldig worden gedeeld.

Mijn Perspectief: Een Waarschuwend Verhaal voor AI-samenwerking

Hier is hoe ik het zie: dit is een schoolvoorbeeld van hoe gemak en beveiliging in tegengestelde richtingen trekken met moderne AI-tools. Het delen van een chat met een link is geweldig voor remote of projectgebaseerde teams. Maar zoals de bevindingen van Claroc laten zien, kunnen shortcuts—zoals leesbare chat-titels in URL's stoppen—terugkaatsen, vooral wanneer openbare infrastructuur zoals DNS-logs in het spel is.

Dit gaat niet alleen over Muse. Veel SaaS- en AI-platforms gebruiken vergelijkbare deelmodellen, en de meeste mensen hebben geen idee hoe "niet vermeld" snel kan veranderen in "publiek." De boodschap: als iets echt gevoelig is, reken dan niet op obscuriteit of niet-vermelde links. Eis echte privacyfuncties zoals wachtwoorden, vervaldatums voor links, of toeganglogs.

Als je op zoek bent naar AI-tools voor jouw team, geef dan prioriteit aan beveiligingscontroles boven flashy functies of hype.

Nog één ding: Claroc, het bedrijf dat het probleem aan het licht bracht, verkoopt ook software om risicovolle AI-deling te detecteren. Hun motivatie is duidelijk, maar hun technische bevindingen zijn solide en ondersteund door bewijs. Als je een bedrijfsleider bent, raak dan niet in paniek—maar benader elke nieuwe AI-functie met een gezonde dosis scepsis, en vraag leveranciers om transparantie.

Vraag niet alleen hoe een functie werkt, maar ook hoe het kan falen—en wat er is om die fouten op te vangen of te voorkomen.

Als jouw organisatie al Muse of vergelijkbare tools gebruikt, is dit het moment om te herzien wat er is gedeeld, toeganglogs te controleren als je die hebt, en contact op te nemen met leveranciers over mogelijke blootstelling. Gebruik dit als een reden om te heroverwegen hoe je nieuwe AI-tools evalueert en uitrolt—beveiliging en privacy zouden naast productiviteit op je checklist moeten staan.

De Conclusie

De Muse-deelfout zou een wake-up call moeten zijn: in de wereld van AI-samenwerking is "niet vermeld" lang niet hetzelfde als "privé." Als je iets kritieks voor jouw bedrijf deelt, zorg er dan voor dat je precies weet wie het kan zien—en hoe het anders kan worden gevonden. Behandel voorlopig elke deelbare link alsof deze publiek is, en houd je leveranciers aan een hogere beveiligingsnorm.

Naarmate deze AI-tools zich vermenigvuldigen, zal het een mix van technologie, gebruikersopleiding en leveranciersverantwoordelijkheid vergen om gevoelige bedrijfsgegevens daadwerkelijk veilig te houden.

Voor meer informatie over Meta Muse, bezoek https://muse.meta.com/.