Meta halts Muse chat sharing after DNS leak exposes private data

Meta has temporarily disabled the link-sharing feature for its Muse AI assistant after security researchers discovered that thousands of private conversations were publicly accessible. The flaw allowed anyone with access to public DNS records to reconstruct URLs and view sensitive data, including financial reviews and job interview notes.

What happened

Security firm Claroc published a report this week detailing how they located more than 6,800 Muse conversation links by scanning public DNS records. These records act as a directory for web traffic, mapping domain names to IP addresses. Because Meta’s implementation included predictable elements in the URL structure, researchers could reverse-engineer the links without needing direct access to user accounts or private databases. The exposed conversations contained highly sensitive information, such as a marketing company’s revenue review, a small business owner’s loan application, a workplace’s full-year staff calendar, and preparation notes for a job candidate interviewing with an AI lab.

In response to the findings, Meta confirmed it has paused the functionality that allows users to share specific Muse artifacts. Tracy Clayton, a spokesperson for Muse, stated that while the feature was designed to let people share pages with those who have the link, the company is now reviewing the report to determine how these links can be better protected from discovery. This incident highlights a recurring issue in the AI industry, where sharing features for platforms like OpenAI’s ChatGPT, Anthropic’s Claude, and xAI’s Grok have previously resulted in private chats appearing in search engine results.

How it works

The vulnerability stemmed from how Muse constructed the web addresses for shared conversations. According to Claroc, each share’s URL was built using three components: the share’s title, a short phrase describing the conversation, and a random ID. While the ID provided some randomness, the inclusion of the title and descriptive phrase made the URLs partially predictable. More critically, the hostname itself often revealed the content type before the page was even opened.

Because these hostnames and associated records were published in public DNS logs, researchers could query these directories to find active Muse subdomains. By combining the hostname data with the known URL structure, they could rebuild the full links. This method bypassed any intended privacy controls, as the links did not require authentication or additional permissions to view once the correct address was guessed or reconstructed. The system relied on "security by obscurity" through random IDs, but the predictable metadata and public visibility of the infrastructure undermined that protection.

Key details

• Claroc researchers identified over 6,800 publicly accessible Muse links via public DNS records.
• Exposed data included revenue reviews, loan applications, staff calendars, and interview notes.
• Muse URLs were constructed from a title, a descriptive phrase, and a random ID.
• Public DNS records revealed hostnames that helped researchers reconstruct the full links.
• Meta has paused the sharing feature while it reviews the security report.
• Similar incidents have occurred with ChatGPT, Claude, and Grok sharing features.

Why it matters

For software engineers and technical founders, this incident serves as a stark reminder that generating unique IDs is not sufficient for securing shared resources. When building features that allow users to share content via links, relying on unguessable tokens alone is risky if other parts of the URL or the infrastructure metadata leak information. Publicly visible DNS records, server logs, or even client-side hints can provide attackers with the missing pieces needed to enumerate valid resources. This is particularly critical for AI applications where users may inadvertently paste sensitive corporate data into chat interfaces, assuming the platform’s default privacy settings are robust.

Furthermore, this highlights the importance of defense-in-depth strategies for shared assets. A secure sharing mechanism should not only use cryptographically strong random identifiers but also enforce access controls, such as expiration dates, password protection, or explicit user authentication. Without these layers, any leak of the URL structure or metadata can lead to mass exposure of private data. Teams building AI-powered products must treat shared links as public-by-default unless explicitly secured with additional barriers, ensuring that even if a link is discovered, the content remains inaccessible to unauthorized parties.

What you can do

• Audit your URL generation logic to ensure no predictable metadata, such as titles or timestamps, is included in public links.
• Implement strict access controls for shared resources, requiring authentication or one-time passwords rather than relying solely on link secrecy.
• Monitor public DNS records and certificate transparency logs for your domains to detect unintended exposure of subdomains or services.
• Set automatic expiration times for all shared links to limit the window of vulnerability if a link is leaked.
• Educate users about the risks of pasting sensitive data into AI tools, even when using internal or enterprise-grade platforms.
• Conduct regular penetration testing focused on enumeration attacks to identify if resource IDs can be guessed or reconstructed.