Bug Bounty

Meta pauses Muse chat sharing after researchers find 6,800 links

Claroc found 6,800 Meta Muse share links listed by title in passive DNS. Meta paused sharing 12 days after its bug bounty report, once the press asked.

Network graphic illustrating Meta Muse shared chat links exposed through public DNS records

Meta has switched off conversation sharing in its Muse AI agent after researchers at Claroc showed that thousands of “private” share links could be listed by title from public DNS data. The finding went to Meta’s bug bounty programme on 8 October, but the feature was only paused twelve days later, after a journalist asked questions.

What happened

On 18 October 2026, security firm Claroc published research it calls GhostShares, describing how shared conversations from Meta’s Muse assistant could be discovered by people who had never been sent the link. Searching a commercial passive-DNS dataset for the content domain Muse uses to serve shared pages, the team says it recovered more than 6,800 share hostnames, each one readable because it carried the title of the conversation it pointed to.

Claroc opened a few hundred of those pages without logging in, and says almost all live ones loaded. Most were harmless, but a minority were clearly not meant for strangers. The firm describes a loan application with the sum requested, a company revenue review prepared for its chief executive, an investor’s property returns and mortgage figures, a to-do list containing a partial bank account number from a fraud alert, a full-year staff holiday calendar, and a job candidate’s notes ahead of a confidential call with a leading AI lab, naming the contact and the meeting time.

According to Ars Technica, which reported the research on 20 October, Claroc co-founder and CTO Asaf Aprozper filed the issue through Meta’s bug bounty programme on 8 October and also tried to reach Meta staff directly, without a reply. After Ars contacted Meta, the company said it had paused the sharing function while it reviews the report and considers how links can be discovered. Claroc says that when it rechecked 40 previously open shares on 20 October, none loaded. The hostnames, titles included, remain in passive-DNS history.

The technical picture

Share-by-link is a common pattern: the service publishes a page and the only protection is a long random token in the address. Muse followed that model, and Meta’s statement to Ars confirms the pages were designed to open for anyone holding the link.

The flaw was where the sensitive parts of the address lived. Rather than putting the conversation title and random token in the URL path, Muse built them into the subdomain, under cf.metaaiusercontent.com. Paths travel inside encrypted HTTPS; hostnames must first be resolved through DNS, and passive-DNS providers record those lookups in searchable archives.

The consequence is that the “unguessable” token can stop being secret the first time anyone opens the link. A single query against the right dataset returns the full hostname, title and token together, which is enough to rebuild the link. Claroc also found over 75 archived scans of Muse shared pages on the public urlscan.io service, so the exposure was not confined to paid data feeds.

Timeline from Muse launch on 8 September to Claroc's bug bounty report on 8 October and Meta pausing sharing on 20 October 2026

Why it matters for UK organisations

Muse launched in the United States on 8 September and, according to one availability tracker, had not been released in the UK by the end of September. That is no reason to relax: shared pages opened for anyone without an account, so UK residents’ details can sit in content created by a US colleague, supplier or recruiter, and staff can adopt consumer AI tools long before IT notices.

The UK data protection angle is straightforward. If an employee pastes customer or staff personal data into an AI assistant and then publishes it to a link that anyone can find, that is a disclosure the organisation is answerable for under UK GDPR. A holiday calendar naming dozens of employees, or a loan application, is exactly the kind of material that could trigger an assessment of whether the incident must be reported to the ICO within 72 hours.

There is also a lesson for UK teams building their own products. Plenty of UK SaaS providers, banks and public sector services offer “anyone with the link” sharing for documents, quotes, reports and dashboards. Many put identifiers or descriptive slugs into subdomains for routing convenience, yet Muse shows the hostname is effectively public metadata.

Expert view

When we test web applications, share links are one of the first things I look at, and the usual checks are token length, expiry and whether the page leaks the token through referrer headers. I suspect very few test plans ask what ends up in DNS. That is the uncomfortable point of this research: no single control failed, yet the design leaked by default.

The disclosure timeline is just as instructive. Claroc did the responsible thing and went through Meta’s own bounty channel with reproduction steps. Twelve days later, the fix was a feature switch-off that came only after press inquiries, with no reply to the researcher in between. Meta told Ars it opened the Muse bounty so researchers could raise “different scenarios”, but a programme is only as good as its response time. With many bounty queues swamped by AI-generated noise, a design-level finding with no CVE is easy to park as “intended behaviour”. Vendors need triage that recognises privacy-by-design failures, not just classic bug classes.

For UK researchers there is a further wrinkle. Claroc says it only viewed pages that loaded without any login and withheld every identifier. Under the Computer Misuse Act, viewing data you were not meant to see remains a grey area, and careful methodology like this is exactly what a statutory defence for good-faith research ought to protect.

What to do now

  1. Find out who is using consumer AI agents. Use proxy, DNS filter or CASB logs to look for muse.ai and metaaiusercontent.com, plus the share domains of the other assistants your staff use. This sits under the Cyber Essentials secure configuration and user access control themes: know what software is in use and who has it.
  2. Decide, then enforce. If you cannot see or govern sharing from an AI tool, block it on managed devices until you can. Where you allow it, say plainly in your AI acceptable use policy that a share link means the content is public.
  3. Check your own exposure. Search passive DNS and urlscan.io for your own domains and for the SaaS tools your teams rely on. Create a test share and look at what appears in the hostname and the path.
  4. Review your products’ share links. Keep tokens and anything descriptive out of hostnames. Put them in the path, use long random values, add expiry and revocation, and consider requiring sign-in for anything that could contain personal data.
  5. Run a data protection check. If staff shared personal data through Muse, record the incident, assess the risk to individuals and decide on ICO notification within the 72-hour window.
  6. Fix your own intake. If you run a bug bounty or VDP, make sure design and privacy findings get a named owner and a response target, not just memory-safety bugs.

Bottom line

GhostShares is not a clever exploit, just an ordinary feature leaking through an ordinary protocol, reported properly and then left waiting. For UK organisations the takeaway is twofold: treat any AI “share” button as publishing to the world, and make sure your own disclosure channels act on reports before a journalist calls.

Sources

Related Posts