al-ice.ai

The Unguessable ID Dies on First Click: 6,800 Meta Muse Share Pages Listed in Passive DNS

AI Security Research by al-ice.ai Editorial

Claroc's research team published GhostShares on 18 October 2026 and updated it on the 20th. The finding is small enough to state in one sentence and awkward enough to deserve the long version: when a user asks Meta's Muse agent to share a conversation, Muse publishes the conversation at a hostname built out of the conversation's own title, and public DNS then indexes that hostname for anyone who cares to look. One passive-DNS query against the content domain cf.metaaiusercontent.com returned, after filtering out wildcard-scan noise, more than 6,800 share hostnames — readable by name, like a table of contents.

On 20 October, after Ars Technica's Dan Goodin put the research to Meta, Meta said it is suspending the feature. Claroc rechecked 40 shares that had opened without an account earlier in the month; none opened, and the hostnames serving their content now error. The hostnames themselves, titles included, remain in passive-DNS history.

Why the random ID was never the control

Muse's share address is a title slug plus a random identifier. The identifier is long enough that nobody is guessing it, and Claroc is explicit that they did not try: “Guessing was never the point.” The first time anyone opens the share — including the colleague it was legitimately sent to — their resolver performs a lookup, and a passive-DNS provider whose resolvers observe that lookup records the entire hostname, random ID and all. The secret is published by the act of using it.

This is the part worth generalising beyond Muse. Capability-URL designs across the industry lean on the same assumption: the path segment is unguessable, therefore the resource is private. That assumption holds only while the secret stays off the wire in a position that gets logged. Put it in a path under HTTPS and it is reasonably well hidden. Put it in a hostname and you have handed it to the global DNS infrastructure, which exists to record and republish names. Muse made the second choice, and then made it worse by prefixing the ID with a human-readable description of the contents, so a scraped hostname list doubles as a triage queue: a reader can tell which pages are worth opening before opening any of them.

Meta did take the precaution everyone learned to take after 2025. Muse's robots.txt asks search and AI crawlers to stay off the share paths — the control that OpenAI reached for when shared ChatGPT conversations turned up in Google results, and that Grok lacked when hundreds of thousands of conversations were indexed. Claroc's point is that robots.txt governs crawling, not access, and their discovery channel never touched a search engine. Nor is passive DNS the only one: they note that urlscan.io already holds more than 75 saved scans of Muse share pages, which is an ordinary public search box.

What was behind the links

Claroc opened only a few hundred of the 6,800 and left the rest. Most were unremarkable — small-business sites, listings, event calendars, pages whose owners presumably wanted them seen. A minority were not. Described by category only, with no names or links, the six they highlight are: a candidate's notes preparing for a confidential executive-search call with a frontier AI lab, naming the lab's internal contact and the meeting time; a national marketing company's internal revenue review marked for its CEO; a small-business owner's loan application with the amount requested; a to-do list containing a bank fraud alert with a partial account number and transaction amount; a real-estate investor's internal performance report with two property addresses and exact return, income and mortgage figures; and a workplace's full-year staff vacation calendar listing dozens of employees.

The research makes a sharp observation about the first of those that is easy to skim past. The biography in a call-prep document might be assembled from public sources — but the meeting is not public. Who is quietly talking to whom, and when, is a private fact constructed out of public parts, and the share page hands it to anyone who can query a domain-name dataset. That is a different harm from a leaked file, and it is the harm that scales when an assistant's output is a narrative rather than a document.

Nobody broke anything

There is no CVE here and there will not be one. No authentication was bypassed, no bug was exploited, no rate limit was evaded. Every page was public because a user asked Muse to make it public, and Muse did exactly that; every hostname came from a commercial passive-DNS provider, not from brute force. Claroc disclosed to Meta's bug bounty programme on 8 October 2026 with reproduction steps, performed its content review on 7–8 October, and re-opened exactly one page afterwards — on 18 October, to capture a redacted screenshot. What it continued to watch through DNS alone is that the share tier kept minting new hostnames: 27 on the last day it looked.

Muse launched on 8 September 2026. A month of ordinary use produced 6,800 publicly indexed conversation pages. That ratio, not the six anecdotes, is the number for security teams to carry: the exposure here is a function of adoption, and it accumulates silently because each individual share is a sanctioned action by a user who was told only that “people with the link” could see it.

The governance gap this exposes

Claroc's framing of why a settings review misses this is the most transferable part of the write-up. Each share is a request an employee makes, one conversation at a time, and the app carries it out as documented. What makes the share findable — how the URL and hostname are constructed, and the fact that DNS records them — appears in none of the sharing controls a reviewer would inspect. An approval is a snapshot of the moment it was signed; the shares happen afterwards. That is the same structural problem we saw in the IMDEA PoPETs work on conversational-AI trackers and permalinks and in Grok's whole-repository upload behaviour: the privacy outcome is decided by a transport detail that no product setting surfaces.

The practical items, which apply to every AI assistant your staff use and not just the one Meta has now suspended: find out who is already using it, because consumer AI agents need no admin rollout; say explicitly in your AI-usage guidance that asking an assistant to share a conversation publishes a public page, and that in some products the title becomes a public DNS name; treat the creation of an AI share link as an outbound data transfer and alert on it if your tooling can see SaaS and AI activity; and if nothing in your stack can see it, block the app and its content domain at the proxy or DNS filter as a blunt stopgap.

The last suggestion is the one worth acting on today regardless of Muse's status: run the same query yourself. Search passive DNS and urlscan for the content domains of the AI and SaaS tools your people actually use, then create a share and watch what lands in the hostname. Whatever you can retrieve, so can anyone with the same ordinary access. Meta closed this one in twelve days from report to suspension, which is fast. The design pattern that produced it is not unique to Meta.

Our verification was read-only. The methodology, the 6,800-hostname figure, the cf.metaaiusercontent.com content domain, the title-plus-random-ID hostname construction, the six exposure categories, the urlscan.io count, the 8 October bug-bounty disclosure, the 27 new hostnames observed, the 8 September Muse launch date and the 20 October update stating Meta is suspending the feature were read first-hand from Claroc's GhostShares post, which is itself the primary research and carries the dated update. The suspension and Meta's response are independently reported by Ars Technica (Dan Goodin, 20 October 2026). We did not query passive DNS, did not open any Muse share page, and did not attempt to reproduce the enumeration; no request was sent to Meta infrastructure. Brave Search was used for discovery only.

Sources: