Innhold Show
If you shared a Meta Muse artifact before the fix, your old link no longer works. Meta Muse sharing is back with replacement URLs after Meta fixed a flaw that made shared pages easy to discover through passive DNS data. You will need to send each recipient the new link.
The feature returned just two days after Meta disabled it. Security company Claroc had found more than 6,800 sharing addresses with a single search of passive DNS data. Among the pages its researchers opened were a loan application, internal revenue figures, and other details that were hardly intended for random strangers.
Meta did the right thing by killing the old addresses instead of simply switching the same system back on. But a new URL does not make a shared page private. Muse still creates pages that anyone with the link can open, and both individuals and businesses should treat them as public pages.
What did Meta change in Muse sharing?
Meta restored the sharing feature after changing the URLs for shared Muse artifacts. Meta’s David Singleton wrote on October 22 that the problem had been fixed and sharing was available again. He also clarified that the issue involved addresses for shared artifacts – documents, images, and other results created in Muse – rather than a flaw in chat sharing itself.
Every artifact shared before the fix now has a new address. Anyone who visits an old link sees a message telling them to ask the person who shared the content for the new one. That creates a little extra work, but Meta made the right call here. Breaking old links is better than leaving potentially known addresses connected to the content.
The Verge reported on the feature’s return and pointed to Singleton’s announcement on X. Meta has not yet published a detailed technical explanation of the new URL design. We know the old addresses have been replaced, but not exactly how the company verified that the new ones cannot be mapped in the same way.
Why did the old URLs have to go?
The previous system placed the share title and a random ID in the hostname beneath Meta’s content domain. When a recipient opened the link, the browser had to look up that full hostname through DNS. Passive DNS services can retain records of those lookups and make them searchable.
The random ID was supposed to make the address difficult to guess. The problem was that nobody had to guess it. Once the full hostname entered DNS history, both the title and the ID went with it. Claroc searched for Meta’s known content domain and found more than 6,800 hostnames that effectively formed a table of contents.
According to Claroc’s technical report, its researchers opened a few hundred of the results without an account or login. Most were harmless, but a minority contained clearly sensitive material: a company’s internal revenue review, a loan application, a bank fraud alert showing part of an account number, and a vacation schedule listing employee names.
This was not a breach of Muse accounts, and Claroc found no evidence that the information had been abused. The users had asked Muse to share the content. The design failure was that a link intended for a specific recipient could be discovered systematically by people who had never received it.
Are the new Muse links private?
No. A shared page is still open to anyone who has its address. Meta’s fix is meant to stop those addresses from being collected as a searchable list through the old DNS mechanism, but it does not add access control to the content.
The distinction between private and unlisted matters. Private content normally requires a login, an approved recipient, or another form of access control. Unlisted content is open to anyone who gets the link. The new design may be much harder to discover, but a recipient can still forward the address, and the link can still appear in messages, logs, or other services.
That does not make every form of link sharing irresponsible. A random, unguessable address can work perfectly well for content that would cause no harm if someone forwarded it. But its security depends on the address remaining unknown. That is a poor model for documents where you need to control exactly who can read them.
Meta describes Muse artifacts as documents, images, and other files the agent creates while it works. These artifacts can contain far more than a throwaway chat response. Muse is designed to work with email, documents, purchases, and personal tasks, so its sharing button can move real personal and business data out of the workspace.
That is why trust has become the thread running through Muse. The agent has previously shared a user’s home address and sent a buyer there without permission. When a tool asks for access to so much of your life, “anyone with the link” is not a minor footnote. It is a security boundary.
What happens to shares created before the fix?
Old sharing addresses should no longer open the content. When Claroc tested 40 previously accessible pages on October 20, none of them worked. Now that sharing has returned, Meta says visitors to an old address will only see a message telling them to contact the sender for the new URL.
That limits the continuing risk, but it does not erase historical DNS data. Titles and old hostnames already recorded by third parties may remain in archives. If a title revealed a customer’s name, a loan application, or an internal project, that information can live on even when the document behind it no longer opens.
If you shared sensitive content, do not assume that a dead link recalls any copies that may already exist. A recipient could have downloaded the document, taken a screenshot, or forwarded it. Replacing the URL is a necessary technical repair, not a time machine.
What should you do if you used Muse sharing?
Review the Muse artifacts you previously shared and assess their contents as if the pages could have been public while the old addresses worked. Pay particular attention to customer information, financial documents, addresses, meeting details, employee data, passwords, and API keys.
If a live secret appeared in a shared artifact, rotate it. That includes passwords, API keys, access tokens, and other credentials that can be used directly. Meta making the old link useless is not enough. If personal information or business data was involved, the incident should also enter the organization’s normal security and incident-response process.
Before sending a new URL, check whether the recipient actually needs the entire artifact. Remove unnecessary data, and use a system with recipient controls or login requirements when the material is sensitive. Sharing links are fine for an illustration or a harmless document. They are a terrible home for loan applications, account details, and confidential plans.
For businesses, the principle is simple: an AI sharing link is an outbound data transfer. It should be discoverable, logged, and revocable. If your organization cannot see what employees share from Muse, restrict the feature until you actually have control.
A straightforward internal rule is to use public or unlisted AI links only for material that could safely be sent without recipient controls. Everything else should be shared through a system that can limit access to named people. That makes the decision understandable even to employees who have no desire to learn the difference between URL paths, hostnames, and passive DNS databases.
A fast fix is good – documentation would be better
Meta deserves credit for disabling the feature, breaking the old links, and shipping a fix quickly. That response is far better than pretending the problem was merely careless users. People must be able to use a sharing button without its URL design making thousands of pages discoverable through one DNS search.
At the same time, “the issue has been fixed” is a starting point, not the whole answer. Meta should explain how the new addresses are constructed, whether titles still appear in hostnames, how users can manage active shares, and whether a link can expire or require a login. Businesses also need logs showing when a share was created, opened, and revoked.
Muse is useful precisely because the agent can work with things that matter. Sharing must therefore be treated as a core security function, not a convenient afterthought. Use the restored feature for harmless content if it suits the job. Just do not confuse a new and harder-to-find URL with private access.
Frequently asked questions
Is Meta Muse sharing available again?
Yes. Meta restored sharing on October 22, 2026, after changing the URLs for shared Muse artifacts. Old shares received new addresses, while previous links now show a message telling the recipient to ask the sender for the replacement.
Do old Muse sharing links still work?
No. The old addresses should no longer open the content. Claroc tested 40 previously accessible shares after the feature was disabled, and none opened. Meta says those addresses now only display a message directing the visitor back to the sender.
Were 6,800 private Muse conversations leaked?
That is not what the evidence shows. Claroc found more than 6,800 sharing addresses and opened a few hundred. Most were harmless, a minority contained sensitive information, and the researchers found no evidence of abuse. The flaw made shared artifacts systematically discoverable.
Can I share confidential documents with a new Muse link?
Use recipient-controlled access or a login for confidential material. A Muse page remains accessible to anyone who gets its address, even if the old DNS method can no longer map the links. Remove unnecessary personal, account, and business information before sharing.
