You share a link to an AI conversation. It isn’t in search results, and the address contains a random identifier, so it feels like something a stranger would never find. Yet researchers uncover more than 6,800 such addresses with a single search of DNS data. No guessing random IDs, no hacked server and no account required. That’s what happened with Meta Muse’s conversation-sharing feature.

On 18 October 2026, Claroc published its “GhostShares” report. On 20 October, the researchers added an important update: Meta had suspended conversation sharing. This is an AI story, but the underlying issue has nothing to do with model hallucinations or prompt injection. It comes down to how web addresses were constructed and the dangerous assumption that a hard-to-guess link is the same thing as access control.

More than 6,800 addresses. Not 6,800 confirmed data breaches

Muse, Meta’s personal AI agent, launched on 8 September 2026. Among other things, it allowed people to create content during a conversation and share it afterwards. A user could ask the agent for a link, and anyone with that address could open the shared page without signing in.

WebsiteGarage / Services

Explore our services.

Claroc’s researchers searched a commercial passive DNS database containing domain names observed over time. After filtering out incidental scanning results, they found more than 6,800 hostnames associated with shared Muse content. Each hostname corresponded to a separate shared page. The team opened only a few hundred of them. Most contained ordinary or harmless material, but some revealed information you wouldn’t expect to see on a publicly accessible page.

That distinction matters: 6,800 is the number of addresses discovered, not the number of confidential documents, affected people or confirmed personal data breaches. We also don’t know how many Muse shares existed beyond the database examined. An address appearing in passive DNS records doesn’t, by itself, mean anyone has misused its contents.

Claroc identified six categories of potentially sensitive material. They included an internal company revenue analysis intended for its CEO, a small-business loan application, a property sale plan, a note about a bank alert containing part of an account number, and an annual employee leave calendar. Another page concerned confidential preparations for a senior-level job interview at a company developing advanced AI.

The concern isn’t just about names and financial figures. Sometimes the most revealing detail is that particular people are due to attend a meeting that hasn’t been made public, even if the rest of the document mostly contains publicly available facts. That knowledge could make impersonation, fraud or a carefully tailored phishing attempt much more convincing.

The report’s authors deliberately withheld the actual links, document titles and identifying details of the people involved. We’re doing the same. Reporting on a privacy failure shouldn’t mean helping spread someone else’s private information.

A quick explanation helps here. DNS is the system your browser uses to find the server behind a name such as www.example.com. A DNS query contains the hostname, not the page’s contents or the full path of its URL.

With Muse, the title of a shared conversation and its random identifier became part of the hostname under a domain used to serve shared content. In simplified form, it looked like this: annual-report-randomidentifier.example.com. That’s an invented example, not the address of a real conversation. The name itself offered a clue about what the page might contain, while the supposedly secret identifier was sitting in the very part of the address visible to DNS.

When someone opened a shared page, their device had to resolve its hostname. Some services that monitor DNS traffic record the answers they observe and make that historical information searchable. That’s what passive DNS is. It doesn’t mean every DNS request made by every internet user is published in one worldwide database. It’s enough for a particular hostname to be observed by a provider whose records can be searched.

In this case, a search of the passive DNS data returned the entire hostname, random identifier included. There was nothing to crack or guess. The researchers could then reach the corresponding shared page, which opened without authentication. A random identifier only offers protection if it genuinely stays secret.

Why didn’t robots.txt help?

Muse used a robots.txt file to discourage search engines from indexing shared content. That’s a useful way to manage crawling and indexing, but it isn’t a lock on the door. It doesn’t verify a visitor’s identity or prevent them from opening a page whose address they already know.

Crucially, Claroc didn’t need to search Google for Muse conversations at all. The researchers used DNS records, entirely outside the website indexing process. They also noted more than 75 recorded scans of Muse share pages on urlscan.io. Services like this provide another way for publicly accessible addresses to become easier to discover.

The same distinction applies to noindex. It can stop a search engine from showing a page in its results, but it does nothing to restrict direct access. Google Search Central explicitly distinguishes controlling indexing from protecting confidential material. If something should only be accessible to authorised people, you need access controls, not a polite request to search bots.

A security incident, not a hack of Meta’s systems

People had intentionally used Muse’s sharing feature, and the application created a public page. The problem was that these pages were far easier to discover at scale than their unpredictable-looking addresses suggested. According to the report, there was no need to bypass a login, exploit a server vulnerability or take over an account.

This represents genuine exposure of some information, but the findings have clear limits. The researchers opened sensitive material in an ordinary browser without being given the link by its owner and without signing in. They did not, however, provide evidence that criminals had used these links or exploited the information for fraud. Calling this a confirmed data-theft campaign would therefore be misleading.

The timeline: disclosure, publication and Meta’s response

  • 7-8 October 2026: Claroc carried out its main checks of whether the sampled pages were accessible and what they contained.
  • 8 October: The researchers submitted the issue to Meta’s bug-reporting programme.
  • 18 October: The initial GhostShares report was published.
  • 20 October: Following questions from Ars Technica, Meta said it had suspended sharing and was reviewing how links could be discovered. That day, Claroc retested 40 previously accessible pages. None could be opened.

In its response to Ars Technica, Meta confirmed that the feature had been paused while it assessed the report. As of 21 October, that was not the same as publishing a full explanation of the root cause or permanently introducing a redesigned sharing system. The retest of 40 addresses showed that the pages controlled by Meta were no longer accessible in those cases. It didn’t show that every historical trace of the addresses had disappeared.

The hostnames, including any conversation titles embedded in them, remained in historical passive DNS records. That’s another important point: revoking access to content doesn’t automatically erase information that has already left your system.

This is not limited to AI assistants. Similar links are used for project previews, invoices, PDF proposals, cloud files, staging sites and documents shared with clients. Before assuming a link is safe, it’s worth asking a few practical questions.

  • Who can open the page? Does the visitor need to sign in, have permission to access that specific document or enter a password? Or is the link itself enough?
  • What does the address reveal? Could the hostname, URL path or title expose client names, amounts, project details or other information that should stay private?
  • Can the link be revoked? You should be able to withdraw access to shared content. Sensitive material should also have a sensible expiry date.
  • What happens after you sign out? Try opening the link in a private browser window or under another account. It’s a useful basic check, although it doesn’t replace a security audit.
  • Where else might the address end up? Check whether analytics, embedded scripts, link previews, server logs or website scanning services could record or pass it on.
  • Does the recipient really need the entire conversation? Sometimes a short summary without the confidential source material is a much safer thing to share.

What if your company has already shared sensitive information through AI?

First, establish exactly what was shared, who could access it and for how long. If the platform lets you delete the public share or revoke the link, do so. For passwords, API tokens and access keys, removing the page is not enough: the affected credentials need to be changed or revoked.

If the material included customer or employee data, assess the extent and impact of the exposure under your company’s data protection procedures. Discovering a publicly accessible address does not automatically trigger the same legal obligations in every case. The type of data, risks to individuals and actual circumstances all matter. Involve your data protection lead or legal adviser where appropriate.

When building a new sharing feature, permissions should be part of its design from the start, not an afterthought. Even a small WordPress module for sharing materials with clients needs to distinguish clearly between public and private content and verify who can open it. If you need a specific, limited feature on an existing site, it’s something to plan as part of [link WordPress Development Sprint]. Larger client portals and systems with multiple user roles require a separate project scope.

The biggest lesson goes well beyond AI

Meta Muse didn’t decide on its own to expose someone else’s data. It followed a request to share content, but the way the feature was built made the public links easier to find. It’s a familiar design mistake in a new setting: the system treats being hard to find as if it meant being private.

Whenever you build a new “Share” feature, ask more than how quickly it can generate a link. Ask who can find that link, what they can learn from it and how access can be revoked. Security doesn’t come from the length of a random identifier. It comes from how access and information are controlled throughout the process.

Sources and limits of the findings

Information current as of 21 October 2026. The figure of more than 6,800 refers to hostnames found in a single passive DNS dataset, not verified leaks of confidential documents. Some sensitive pages were confirmed accessible through ordinary browsing, but there is no evidence of criminal misuse. Meta suspended sharing; the historical hostnames remained in external records.