Meta Restores Muse Sharing After Fixing Exposed Links, but Old Links No Longer Work
Two days after pausing Muse sharing over links exposed through public DNS records, Meta says the feature is back on, with new URLs for everything shared before the fix and a prompt on old links to ask the sharer for a replacement.
By Icarus3 min read
Meta Restores Muse Sharing After Fixing Exposed Links, but Old Links No Longer Work
Two days after pausing the feature, Meta says Muse sharing is back on, with a catch for anyone who shared something before the fix: those links no longer lead to the content.
Meta has restored sharing in its Muse assistant, two days after pausing it when security researchers showed that shared links could be found through public DNS records. David Singleton, an executive with Meta Superintelligence Labs, announced the change in a post on X on October 22, writing that the underlying issue is now fixed and sharing is back on.
The restoration comes with a condition that affects everyone who shared a Muse artifact before the fix. According to Singleton, artifacts shared before October 22 now have new URLs. Anyone who opens an old link will see a note asking them to get the new link from the person who shared it. Singleton apologized for the disruption, writing that protecting user data has to come first.
Singleton also pushed back on how the incident was reported. He said press coverage wrongly described a flaw in chat sharing, and that the issue was specifically with shared artifacts. Artifacts are documents, images, code, and web apps that Muse creates inside a conversation and that can be shared on their own link. That framing differs from the account given by Claroc, the security firm that found the exposure, and by Ars Technica, which first reported it; both described the exposed items as shared conversations. Singleton’s post does not offer evidence that settles the difference, and this article does not treat either framing as confirmed beyond what each side has said.
What was exposed
The pause followed research from Claroc, published October 20, into how Muse built its share links. Each shared item got a web address built from its own title plus a random identifier, served under the domain cf.metaaiusercontent.com. Because every hostname lookup is recorded in public DNS records, Claroc could search a commercial passive-DNS service for those hostnames and pull up more than 6,800 of them with a single query, then open a few hundred in an ordinary browser with no Meta account. Most were harmless, Claroc said, but a minority contained sensitive material, including a small-business loan application, a marketing company’s internal revenue review, and a workplace’s full-year staff vacation calendar. Claroc reported the findings to Meta’s bug bounty program on October 8 and said it found no evidence the exposed shares were misused.
Meta paused sharing after Ars Technica contacted the company about the research. When Claroc rechecked 40 shares on October 20 that had previously opened without an account, none opened anymore.
Why it matters
If you shared a Muse artifact before October 22, that link is dead, and the people you sent it to will need a new one from you. The artifact itself is not gone; only its public address changed. The restoration closes the immediate incident for Meta but leaves two loose ends. The old hostnames, titles included, remain in passive-DNS history, where no fix can remove them. And Singleton did not say how the new URLs are structured, including whether artifact titles still appear in them, so users cannot yet verify from his post alone that the same discovery method is closed for new shares. Anyone who shared something sensitive before the fix should assume its title was already recorded in DNS history, whatever the new link looks like.
Sources: Singleton’s October 22 announcement as reported by AndroidPure (https://www.androidpure.com/meta-muse-sharing-back-on/) and TokenPost (https://www.tokenpost.com/news/technology/39039); Claroc’s October 20 writeup (https://blog.claroc.io/ghostshares-muse-passive-dns/); prior All Things Muse coverage at /articles/muse-share-links-dns-exposure/.
