Meta Restores Muse Artifact Sharing and Replaces Old Share Links

What changed on October 22

In a post on X published at 17:14 UTC on October 22, 2026, David Singleton of Meta Superintelligence Labs said the underlying issue behind the Muse sharing pause is fixed and that sharing is back on. He stated that the flaw concerned shared artifacts specifically, not chat sharing, and pushed back on press coverage that described the problem as a chat-sharing defect. The report was independently covered by Jay Peters at The Verge later the same day, which corroborates the vendor statement but does not constitute a technical retest of the fix.

The operational detail that matters most for anyone who used Muse sharing is this: every artifact shared before the fix now has a new URL. Anyone who visits an old link sees a note asking them to request the new link from the person who shared it. Singleton acknowledged the disruption and said protecting user data had to come first. Meta did not publish an exact time at which the fix was implemented, so the restoration date should be read as the announcement date.

Where this sits in the incident timeline

This follows our earlier article about Meta’s October 20 sharing-pause response, published on October 22 before the restoration announcement. The pause followed a security researcher’s report that some shared artifact URLs were discoverable through passive-DNS records. That earlier article, "Meta Pauses Muse Share Links After Researchers Found Conversations Through Passive-DNS Records," remains available and explains the original mechanism. Nothing in the October 22 announcement reopens that incident as a new breach. The new facts are the resumption of service, the link-replacement mechanism, and the vendor's clarification that the affected surface was shared artifacts rather than chat sharing.

What the vendor statement does and does not prove

A company announcement that an issue is fixed is a report about the company's own remediation, not independent verification of it. No public post-restoration security test has been obtained, and this article does not claim one. The fix's efficacy for any particular artifact is untested here. Historical passive-DNS records are outside Meta's control, and a replacement URL changes the address of a share; it does not erase what was recorded before the pause. Meta reports that sharing has resumed with replacement URLs. Customers should review intended recipients and verify replacement-link behavior with non-sensitive test documents before sending new access; the retired URLs are described as notices directing visitors to request replacements.

What this means for your business

If your team previously sent Muse artifacts to customers through share links, the restoration announcement creates a concrete task: find those obsolete links and decide who should receive replacement access. Consider a contractor who once sent a customer an AI-prepared scope document through a share link. Before issuing a replacement, the owner should confirm the intended recipient, confirm the approved document version, record the new link, and approve the message that delivers it. When that step happens informally, through forwarded links and memory, nobody can later answer who has access to which version.

Detailed In Design could build a customer document portal that manages exactly that record: named recipient permissions, a register linking each deliverable to its owner and recipients, replacement-link tracking, human approval before replacements are sent, and access and revocation records. This is a proposed custom system, separate from Muse and from any vendor product. Its benefit is visibility into document ownership, recipient review, and follow-up, reducing reliance on unmanaged forwarded links. It carries real limitations: it requires authorized identity and document integration, a reliable link inventory, retention policies, and tested access revocation. It cannot repair a vendor's platform, change third-party access policies, erase historical DNS records, or retract copies a recipient already downloaded.

A restrained next step is an access review of your own shared links. List the documents your team has published through share links, note which recipients received them, and check whether those links still resolve to the intended content. That inventory is the prerequisite for any replacement decision, whether the tool is Muse or something else.