Ghostshares Muse Passive Dns

Meta’s personal AI agent, Muse, shares a conversation when you ask it to. It publishes the conversation as a page and hands you a link to send. The page opens for anyone who has that link, without a login or a request for access, and that is by design: Muse shares only by link, so a public page is the only way the teammate you send it to can open it.

Once the page exists, you do not even need to be sent the link to reach it. Muse names each ’s web address after the conversation’s own title, and that address is written into public DNS. One passive-DNS brings back thousands of them, listed by name, like a table of contents.

We searched one such dataset for Muse’s content domain and opened a sample. Almost every still live opened straight away. Most were harmless. A minority were not: dozens of personal records and internal business documents, among them a candidate’s confidential prep for an executive- call with a frontier AI lab, down to the lab’s internal and the exact time of the meeting. To anyone looking to cause harm, a list like that is a shortcut, ready-made for fraud, impersonation or social engineering.

Every page in this post is public because someone asked Muse to it, and Muse did what it was asked. Plenty of AI assistants by public link. What makes Muse’s shares easy to find is the title sitting inside the web address, where public DNS records it for anyone to . We call these GhostShares: pages that open for people who were never handed the link, and that those people can find on their own.

Muse launched on September 8, 2026. A month later we ran a against a commercial passive-DNS service, which indexes the domains its own resolvers observe, for hostnames under cf.metaaiusercontent.com , the content domain Muse serves shares from. Each hostname is one , and because Muse builds the address out of the ’s title, the list came back readable: shares by name.

After filtering out the wildcard-DNS scan noise any such domain collects, more than 6,800 hostnames remained. We opened only a few hundred of them and left the rest. The titles told us what most pages held before we opened them, and the pages themselves opened on sight, without an account or a sign-in screen. If you had asked us beforehand, we would have guessed that gathering these would take real effort. It took one query.

Passive DNS is not even the only place they turn up. urlscan.io, a public URL-scanning service anyone can query, already holds more than 75 saved scans of Muse pages. The same exposure is sitting in an ordinary box.

How the title ends up in DNS

This class of leak is not new. In 2025, shared ChatGPT conversations surfaced in Google results, and OpenAI pulled the option that made them indexable ; weeks later, Google had indexed more than 370,000 Grok conversations . Keeping AI pages out of engines became the obvious precaution, and Muse takes it: its robots.txt asks the and AI crawlers to stay off the paths. But robots.txt governs crawling, not access, and our discovery never went near a engine.

Meta’s own help page spells out the model: you tap a link, and then “people with the link will be able to see your conversation,” the link “doesn’t expire,” and people “can the link.” It documents Meta AI rather than Muse specifically, but it is the closest published description Meta gives of how one of its AI links behaves, resharing included.

What makes the pages findable is lower down, in the address itself. Muse builds each ’s web address from the ’s title, a short phrase describing the conversation, then a random ID. The hostname usually gave away what a page held before we opened it, and since the link carries that same title and ID, a hostname pulled from DNS rebuilds the link.

DNS does the rest, for free. When someone opens a , their browser resolves the hostname, and a passive-DNS provider whose resolvers see that lookup records it and keeps it searchable. Nobody has to crawl, guess or get past anything. The title the user typed lands in a public index of domain names.

There is a random ID in each address, long enough that nobody could guess it. Guessing was never the point. The first time anyone opens the , DNS logs the whole hostname, random ID and all, so the part that was meant to be unguessable gets published with everything else. An ID only works as a secret while it stays secret, and a hostname is not a secret. Looking one up is just how the web works.

What the exposed pages held

Most of what we opened was unremarkable: small-business sites, listings, event calendars, the kind of page whose owner likely wanted it seen. The pages that concerned us were a minority. Six of them, by category only, with no names or links:

a candidate’s notes preparing for a confidential executive- call with a frontier AI lab, naming the lab’s internal 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 that included a bank fraud alert, with a partial account number and a transaction amount and time

a real-estate investor’s internal performance report, with two property addresses and exact return, income and mortgage figures

a workplace’s full-year staff vacation calendar, listing dozens of employees against the week each one would be away

We reached every one of these without being given its link, from a domain-lookup dataset, with no account. We did not the people or companies involved, so we can’t speak to what they intended; we can say the content was plainly sensitive, and that the two companies are real, confirmed against public sources.

The content is not the only risk. The biography in a page like the call prep might be pieced together from public sources, but the meeting is not public: who is quietly talking to whom, and when. A page like this builds a private fact out of public parts and hands it to anyone who can DNS.

Everything here came from one channel: a commercial passive-DNS service, searched for the Muse content domain. We guessed and brute-forced nothing; every hostname came from the provider, and each maps to one . Muse sends only the ’s title in its first response and paints the conversation in with JavaScript, so a plain fetch sees a near-empty page; we loaded each one in an ordinary browser, which was all it took. We only ever viewed pages that loaded on their own, with no account, and every severity call in this post came from a person reading the page, not a keyword. We did not log in, fill in a form, or upload anything; one page asked for a password and we left it. Then we stopped, with the single later exception noted below.

This is one discovery channel and one hostname pattern, on one product, over a short window. It is not a measure of Muse’s total exposure, and we can’t tell how long any had been reachable, or whether someone else found it first.

Disclosure and timing

We reported this to Meta’s bug bounty program on October 8, 2026, with reproduction steps and example shares. We have no evidence that anyone has misused these shares. Our content checks were made during collection on October 7 and 8; we have not re-opened shares since, with one exception: on October 18, to capture the single redacted screenshot above, we re-opened the call prep once and no others. What we still watch, through passive DNS alone, is that the tier keeps minting new hostnames, 27 on the day we last looked. That is continued discovery, not re-verified access.

The pages we describe are public because their owners shared them, and the same pages already sit in a scan database anyone can . We are withholding every identifier (hostname, title, figure and link), so nothing here points a reader at affected content. We will delete the stored discovery data once Meta confirms it has what it needs.

Why a settings review can miss this

A security review that works from an app’s documented settings can miss this entirely. Each is a request an employee makes, one conversation at a time, and Muse carries it out as documented. What makes a findable, the way its URL and hostname are built and the way DNS records them, appears in none of the sharing controls. An approval is only a snapshot of the moment it was signed, and the shares happen after it.

Muse does what its users ask, and neither that nor the way it builds URLs is a setting your team can change. What you can control is whether your people use Muse at all, and what they ask it to .

Find out who is already using it. Muse launched weeks ago and needs no admin rollout, so employees can be creating and sharing conversations today, with no one having approved the tool. Treat it like any other shadow AI app: get visibility into who inside the company is touching muse.ai, and whether they are generating public shares that carry company data.

Tell people what a link does. Asking an AI assistant to a conversation publishes it as a page anyone with the link can open, and in Muse the conversation’s title also becomes a public DNS name. Say so in your AI usage guidance, to what may be pasted into an assistant, and say it again to the people you find sharing.

Watch what people . The risk starts when someone asks an assistant to , and a conversation becomes a public, discoverable page. If you run a security product that can see SaaS and AI activity, point it at exactly this: flag when a user creates a public , and treat an AI “ link” as an outbound transfer of whatever was in that conversation.

If you can’t detect it, block it. If nothing in your stack can see or govern Muse sharing, block the app at the network: deny muse.ai and its content domain metaaiusercontent.com at your proxy or DNS filter on managed devices, so conversations can’t be created from inside the company or served back out of it. It is a blunt control, but it closes the exposure while you put a better one in place.

And check your own exposure the way we found Muse’s: passive DNS and urlscan for the content domains of the SaaS and AI tools your staff use, and create a yourself to see what lands in the hostname and the URL. What you can retrieve, anyone with the same access can too.

Claroc gives security teams visibility into the SaaS and AI applications their people buy, build and adopt, and into how those apps are actually shared and configured, during approval and after it. Its browser extension notices when an employee creates a public link in an AI assistant such as ChatGPT or Claude, including assistants the security team has not reviewed yet, and adds it to the team’s findings in Claroc with what was shared and who can open it. The team hears the when it is created, so it does not first learn of an exposure like this from a blog post.

This continues our earlier research into links that leaked and still opened: LinkDrift , on internal files reachable at Fortune 500 companies without a login. The thread is the same in both. Nobody broke in. The tools work this way, and people use them.

AI assistants are only going to get more capable and more woven into how we work, so the practical course is to use them with your eyes open: assume anything you is public until you have checked, and make sure someone can see what leaves. These tools are useful, and they do what they are asked, including making a conversation public. What to is still the call of the person asking.

Or [email protected] .