Meta’s Muse put the titles of shared chats where anyone could look them up Meta suspended Muse chat sharing after Claroc researchers enumerated 6,800 shared conversation links and found sensitive material in a few hundred they opened, including a candidate's prep notes for a confidential executive-search call with a frontier AI lab, a national marketing company's internal revenue review, and a small-business owner's loan application. Claroc found the links in a single query because Muse built each share address from the conversation's title plus a random ID as a subdomain under cf.metaaiusercontent.com, so passive DNS logs captured the full hostname once the intended recipient opened the link. Claroc said most of the pages it opened were harmless, and the risk applied only to conversations users chose to share, not every Muse chat. There is a fairly standard way to share something private on the internet. You click “share,” the service makes a web address with a long string of random characters in it, and you send that address to the one person you want to see it. Nobody else can find the page because nobody else can guess the string. It’s not a perfect security model. It’s roughly the security of hiding your house key under one of an astronomically large number of doormats. But it mostly works, as long as the address stays between you and the person you sent it to. Muse, Meta’s new general-purpose AI agent, did the standard thing and then added a twist. As Dan Goodin reported for Ars Technica https://arstechnica.com/security/2026/10/meta-muse-exposes-users-personal-and-business-secrets-when-they-share-conversations/ , researchers at the security firm Claroc said they were able to enumerate 6,800 links that Muse users had made to share conversations. They opened a few hundred and found a lot that was plainly not meant for the public. There was a candidate’s prep notes for a confidential executive-search call with a frontier AI lab, naming the lab’s internal contact and the meeting time. There was a national marketing company’s internal revenue review, marked for its CEO, and a small-business owner’s loan application with the amount requested. One to-do list included a bank fraud alert with a partial account number and a transaction amount and time. A real-estate investor’s internal performance report had two property addresses and exact return, income and mortgage figures. And one workplace’s full-year vacation calendar listed dozens of employees next to the week each would be away. If you had asked us beforehand, we would have guessed that gathering these would take real effort. It took one query. The phone book problem How did one query manage it? According to Claroc’s research, as summarised by Unite.ai https://www.unite.ai/meta-suspends-muse-chat-sharing-after-researchers-find-links-in-public-dns/ , Muse built each share address from the conversation’s title plus a random ID, and put both in the hostname, as a subdomain under cf.metaaiusercontent.com. The random ID was long enough that nobody would guess it. The trouble is where it sat. A hostname is the part of an address your computer has to look up before it can load anything. When the person you shared with clicks the link, their browser asks the domain name system which IP address that hostname points to. And people record those answers. Passive DNS systems put sensors at recursive resolvers and other plumbing, log the DNS responses they see, and keep the history. Plenty of commercial services will let you search it. So the moment the intended recipient opened a Muse share, the whole hostname went into a searchable database: the title, the random ID, all of it. A random string protects you from people guessing it. It does nothing once it’s printed in a list next to a helpful label. Claroc described its search results as being “listed by name, like a table of contents.” Here’s a hypothetical, to make it concrete. Imagine you ask Muse to help with a loan application, the conversation gets a sensible descriptive title, and you share it with your accountant. Your accountant clicks, which is exactly what you wanted. Now the title is sitting in a database that anyone with a subscription can search, next to an address that opens the page. Nothing went wrong in any step you could see. The leak happened because the person you trusted did the one thing the feature exists for. Some scope. The risk only applied to conversations users chose to share, not every Muse chat. Claroc also said most of the pages it opened were harmless, according to AI Weekly https://aiweekly.co/alerts/meta-suspends-muse-chat-sharing-after-6800-links-leak-via-dns : small-business sites, listings, event calendars. Claroc looked at a few hundred out of 6,800, though, so a lot of the pile is still unopened. Built from the ground up Muse launched on September 8. Last month Mark Zuckerberg said it was “built from the ground up for privacy and security.” That was not the agent’s first rough patch on that front: it had already given out a user’s address https://rews.cc/a/meta-s-muse-agent-gave-out-a-user-s-address-the-root-cause-w-5eced4 , after Meta’s pre-launch scramble to seal the walls https://rews.cc/a/eleven-days-before-muse-meta-s-scramble-to-seal-the-walls-ar-41849e around it. Asked about the share links, Meta sent Ars this statement: We opened the Muse bug bounty program so researchers could raise different scenarios and help us continue improving the product. People have the ability to share specific Muse artifacts, which creates a page that can be accessed by those with the link. However, we’ve paused this functionality while we review this report and consider changes to how these links can be discovered. Translation: “different scenarios” means bugs. “Accessed by those with the link” is technically correct, if you count everyone who can search a passive-DNS database as having the link. “Consider changes to how these links can be discovered” is a nice way to say the links shouldn’t have been discoverable. The bug bounty program is worth a look, too, since Meta brought it up. Asaf Aprozper, Claroc’s co-founder and CTO, said he reported the findings through it on October 8. He also tried contacting people at Meta on LinkedIn. He said he got no reply through either channel. Claroc published its research on October 18. Meta paused sharing after a reporter asked about it, and Ars ran the story on October 20. That’s twelve days of silence through the official channel and a fast fix once the press called. Claroc, to its credit, said it was “glad to see it closed this quickly.” Quickly is relative. Engadget also confirmed https://www.engadget.com/2292281/meta-suspends-muse-chats-sharing-feature-after-it-left-private-details-exposed/ that the feature is suspended, and Meta hasn’t said how long it will stay off or what a redesign would look like. On October 20, Claroc said it rechecked 40 shares that had opened without an account earlier in the month. None opened, and the hostnames serving them returned an error. So the pages are gone, at least for now. Pausing the feature stops new links from being made. But the hostnames, conversation titles included, are still in passive-DNS history, because that’s what passive DNS is for. Meta says it’s considering how these links can be discovered. For 6,800 of them, the answer is a database that keeps a permanent record, conveniently sorted by title.