Meta paused Muse sharing after researchers found 6,800 links

If you shared something from Meta Muse, you should treat it as if it may have been public. Security company Claroc found more than 6,800 hostnames for shared Muse pages with a single passive DNS search. Some of the pages contained personal documents and internal business information.

Meta paused the sharing feature while it investigated the report. When Claroc checked 40 previously accessible shares on October 20, 2026, none of them opened anymore. The historical DNS records, including titles that appeared in the hostnames, did not simply disappear with the pages.

This was not a sophisticated break-in. Muse put the title in the hostname, and shared pages could be opened without signing in. A routine part of the internet became a table of contents for shared AI material. That is a gross design failure in a product asking users for an enormous amount of trust.

Update, October 22, 2026: Meta restored sharing with new URLs, and the old links no longer work. I have covered what changed and why the replacement links are still unlisted rather than private. The article below documents the original October 20-21 incident and the findings that caused Meta to pause the feature.

What did researchers find in shared Meta Muse pages?

Claroc found more than 6,800 hostnames associated with shared Muse pages under Meta’s content domain. Its researchers opened a few hundred of them in an ordinary browser without an account or login. Most were harmless, but a minority contained clearly sensitive information, according to Claroc’s technical report.

The examples included a small-business loan application, an internal revenue report marked for a company’s CEO, a bank fraud alert showing part of an account number, and a complete employee vacation schedule. The researchers also found preparation for a confidential recruiting conversation with a leading AI company, including a contact and a time.

Claroc did not open all 6,800 pages. That number does not mean there were 6,800 sensitive leaks, and the researchers found no evidence that anyone had abused the information. The documented problem is narrower, but still serious: thousands of shared objects could be discovered by someone who had never received the link.

The researchers reported the issue to Meta’s bug bounty program on October 8. After Ars Technica asked Meta about it on October 20, the company said the feature had been paused. Disabling it quickly was the right move. It should not take a security report and questions from the press to establish that a hostname is not a secret hiding place.

How did passive DNS reveal the links?

Muse built each hostname from the share title and a random ID beneath cf.metaaiusercontent.com. When a recipient opened the link, the browser first had to resolve that complete hostname through DNS. Passive DNS services can retain observations of those lookups and make the hostnames searchable later.

A random ID would normally make a sharing address difficult to guess. Here, nobody had to guess. The DNS lookup exposed the full hostname, including both the descriptive title and the supposedly secret random component. Claroc could search for Meta’s known content domain, retrieve the records, and reconstruct the sharing addresses.

Ars Technica described the pattern with hostnames that could resemble loan-application-draft-[random-id].cf.metaaiusercontent.com. That example is constructed, but the design pattern was real: the name could reveal the subject while the complete hostname supplied everything needed to visit the page.

Meta’s robots.txt told search engines not to index the shared pages. That can help with conventional search results, but it does nothing to stop passive DNS collection. robots.txt is a request to crawlers, not access control. Claroc also found more than 75 stored Muse shares in the public scanning service urlscan.io, so the discovery problem was not confined to one commercial DNS tool.

Were the Muse shares private or public?

The pages were public in the technical sense: anyone with the correct address could open them without signing in. Users had also asked Muse to share the material. But a link sent to one colleague is normally understood as unlisted, not as something strangers can retrieve from a searchable inventory.

That distinction matters. “Anyone with the link” can be a reasonable sharing model when the address is genuinely difficult to discover. Meta put the title in a publicly observed hostname while DNS exposed the rest of the address. The shares were not merely accessible. They could be mapped systematically.

Meta cannot wave this away by pointing out that users pressed the share button. People need to understand what that button does. If it creates an open web page with no login and an address that can surface in external search systems, the product must say so in painfully clear language. Better still: do not build sharing that way.

The necessary limit is that Claroc did not document abuse. Its researchers examined one discovery route over a limited period and did not know how long each page had been available. That does not make the design acceptable, but it does define the facts: serious exposure and a credible risk of misuse, not proof of mass theft or compromised accounts.

What did Meta do after the report?

Meta paused Muse sharing while it reviewed the report and the way its links could be discovered. In a statement reported by The Verge, Meta pointed to Muse’s bug bounty program and said shared objects created a page available to anyone with the link.

Claroc’s October 20 check suggested that the content pages had been taken offline. The researchers tested 40 shares that had previously opened without an account, and none worked. Meta then restored sharing on October 22 with replacement URLs that invalidated the old links.

Breaking the links did not erase DNS history. Titles and hostnames already observed can remain with passive DNS providers. If a title identifies a project, a company, or a private event, that information may survive even after the page behind the address stops working.

Meta needed to do more than move the title out of the hostname and flip the switch back on. Sharing potentially sensitive material should come with clear public-page warnings, expiration options, recipient restrictions or login controls, and one place where users can revoke every active link. An AI agent working across accounts and documents needs stronger boundaries than a random file uploader.

A good sharing system should also tell the user when a link was created, whether it has been opened, and whether access can be limited to named people. Otherwise, users get an off switch without any meaningful answer about what happened while the page was available.

What should you do if you shared something from Muse?

Review what you shared and assume that both the page and its title may have been publicly visible while the old URL worked. The old addresses are now dead, but they should not be treated as a secure archive or as proof that nobody saw the material.

Look closely for customer information, internal financial figures, addresses, account details, meetings, contracts, and personal data. If a share contained a password, API key, access token, or another live secret, deleting or disabling the link is not enough. Rotate the credential. If business data was involved, put the event through the organization’s normal incident-response process.

For businesses, my advice is even clearer: an AI sharing link is an outbound data transfer, not merely a handy shortcut. Identify who uses Muse, look for traffic to muse.ai and metaaiusercontent.com, and consider blocking the service on managed devices if you cannot detect and control what employees share.

The same principle applies to other AI assistants. An unlisted link is not private just because Google does not show it. Check whether it requires a login, expires, can be forwarded, and places any part of the title or content in the URL. If the answers are unclear, remove the sensitive details and share the sanitized version through a system with real recipient controls.

Muse asks for trust faster than Meta earns it

Muse is not merely a chatbot that answers questions. The agent is designed to fill in forms, book appointments, make purchases, and work with documents and accounts. The more of a person’s digital life it can reach, the more expensive a careless sharing design becomes.

This incident was technically specific. The researchers did not break into private Muse accounts, and they did not trick their way through a security mechanism. They discovered pages for objects that users had chosen to share. The sharing feature worked the way Meta built it. That is precisely why this is so serious: the risk was part of normal use.

Meta was right to pause the feature when the issue became public and right to break the old URLs before restoring it. That is the absolute minimum. When a product is sold as a personal agent and asks for access to huge parts of your digital life, privacy and access control must be the foundation – not the repair added after 6,800 hostnames appear in one search.

My recommendation is simple: do not give Muse more access than you can afford to have it mishandle, and do not put sensitive material in an AI share unless the recipient is actually controlled. Meta has to prove over time that these boundaries hold. This failure gave users another good reason to wait.

Frequently asked questions