Claroc’s “GhostShares” research highlights how link design can expose sensitive content—and why an unlisted page should not be treated as a private document.
Meta has restored Muse’s sharing feature after temporarily suspending it following research into discoverable links containing personal and business information.
According to an October 22 report by The Verge, Meta said it had fixed the underlying issue and assigned new URLs to previously shared artifacts. The company described the affected material as artifacts, such as documents and images, rather than a flaw in chat sharing.
That clarification updates earlier reporting, which described exposed material more broadly as shared conversations.
The incident concerns content published through a sharing feature. The findings do not establish that every private Muse conversation was accessible.
What researchers reported finding
Security firm Claroc said it identified more than 6,800 share hostnames and examined a few hundred associated pages. Its researchers reported finding sensitive personal and company material among them.
Claroc called the issue “GhostShares.” Its central finding was that people could discover shared pages without receiving their links from the users who created them.
In an October 20 update, the researchers said 40 previously accessible shares no longer opened during their recheck. However, historical hostname records—including descriptive titles—remained visible in passive-DNS history.
The count of discoverable hostnames should not be described as the number of confirmed victims, sensitive documents or malicious accesses. Those are different measurements.
Why the address design mattered
Claroc’s report identified a problem with placing descriptive share information in a hostname.
A hostname is the part of a web address that identifies the server a browser is trying to reach. A URL path identifies a resource after the hostname.
DNS resolves hostnames; it does not ordinarily receive the full URL path. Passive-DNS services collect historical observations of DNS responses from participating infrastructure. Consequently, a unique hostname can become discoverable even when its address contains a difficult-to-guess identifier.
That undermines the assumption that a link will remain obscure simply because nobody could readily invent it.
Not every hostname is necessarily captured by every monitoring service. The security concern is that discoverability can arise through infrastructure outside the sharing application’s direct control.
Random links and access controls solve different problems
A sufficiently unpredictable link can make guessing difficult. It does not necessarily restrict the page to an intended recipient.
If possession of the URL is enough to open the material, anyone who obtains it may have access. Links can also travel through forwarded messages, browser history, screenshots and other records.
For sensitive content, a stronger design can combine:
| Control | Purpose |
|---|---|
| Recipient authentication | Establish who is requesting access |
| Resource authorisation | Check whether that person may open the item |
| Expiration | Limit how long a share remains available |
| Revocation | Disable access when sharing is no longer needed |
| Access logging | Support investigation of page requests |
| Minimal URL metadata | Reduce information exposed through the address itself |
These are general design options, not independently verified descriptions of Muse’s updated implementation.
Moving descriptive information out of a hostname can reduce one exposure route. It does not make an unauthenticated page private by itself.
What Meta’s restoration does—and does not—establish
Meta’s reported replacement of old URLs is relevant to whether historical addresses still reach shared material.
However, changing an address cannot establish that previously displayed information was never copied. Nor does a fix announcement independently demonstrate that every relevant attack path has been tested.
The appropriate distinction is between preventing continued access through an affected mechanism and assessing any earlier exposure.
Users should also avoid assuming that pausing or restoring a feature automatically changes all copies, messages or records containing information previously shared.
What users should review
Anyone who shared sensitive material through Muse should inspect the service’s current sharing controls and identify what they published.
A proportionate review includes:
- Check the material. Determine whether it contained business documents, financial information, personal details or credentials.
- Remove unnecessary shares. Use available deletion or revocation controls and check the provider’s current instructions.
- Verify recipient access. For material that still needs sharing, prefer a service that supports access restricted to named people.
- Respond to the information involved. Revoke exposed API keys or other credentials if they were included.
- Notify the appropriate team. Employees should report possible company-data exposure through their organisation’s security process.
A missing access record is not proof that nobody viewed a page. Equally, a discoverable address alone does not prove malicious exploitation occurred.
Lessons for enterprise AI adoption
AI assistants can assemble information from several connected sources into one output. That makes the sharing boundary especially important: a document may contain more sensitive context than its creator initially notices.
Enterprise reviews should therefore examine how generated content leaves the application, not only how the assistant obtains its inputs.
Useful questions include whether sharing requires authentication, whether recipients are restricted, whether users can revoke access and whether sensitive titles enter infrastructure metadata.
The incident illustrates a distinction that applies well beyond AI: “not listed publicly” and “accessible only to authorised people” are different security properties.
