Muse AI Share Links Expose Business Secrets

Meta paused the conversation-sharing feature in its Muse AI assistant after researchers at the security firm Claroc found more than 6,800 shared chats that anyone could enumerate, among them internal company documents, CEO reviews, loan files and executive search notes. The researchers did not crack a token or exploit a memory bug. They read passive DNS records and cross-referenced them with urlscan.io, a public service that archives the pages it scans.

Key Takeaways:

• More than 6,800 shared Muse conversations were publicly discoverable through passive DNS records and urlscan.io, according to Claroc’s findings reported by MediaNama and The Verge.
• Each share link sat on a hostname built from a readable conversation title plus a random identifier, which stopped guessing but did nothing against bulk discovery.
• Meta paused the feature and later re-enabled it. The URL construction decides whether the exposure channel still exists.
• Any team shipping a share-a-conversation or share-a-document link faces the same trade-off: readable URLs help humans and hurt privacy.

Passive DNS Records Made the Share Links Findable

DNS was not designed to hide anything. Every hostname a browser resolves passes through a recursive resolver, and passive DNS sensors collect those query and response pairs into datasets that are sold commercially and, in some cases, published. A subdomain becomes a public record of existence the moment somebody opens the link. MediaNama reported that Claroc’s researchers found the shared conversations through exactly this channel.

The second channel was urlscan.io. The service fetches URLs on request and archives the response, including page text and a screenshot, and its result set is searchable by anyone with a browser. Share pages that reached that index were effectively published twice: once as a hostname in DNS, once as a rendered document.

Neither channel required knowing a user, holding an account, or guessing a value. Both are open to defenders as well, which is the part most incident response plans miss.

What the 6,800 Links Actually Revealed

TechSpot described the URL structure: each shared conversation had a hostname containing a descriptive title and a random identifier, and both could appear in searchable DNS records. That single choice turned an opaque identifier into a labeled index entry. A dataset full of hostnames reading like “acquisition-diligence” or “offer-negotiation-notes” is browsable by keyword even when each string ends in an unguessable suffix.

Reporters who examined the exposed pages described material no company would publish: internal company documents, CEO performance reviews, loan files, executive search notes, and one user’s confidential interview preparation with a leading AI lab. The common thread is that a chat transcript behaves like a compound document. It holds whatever was pasted into it, and assistants are built to encourage pasting.

Four Design Decisions That Combined Into a Disclosure

No single choice here looks reckless in isolation. Each is common in consumer products, and together they produce a channel that leaks at scale.

• Readable titles inside the hostname. Teams put the title in the URL because it makes links legible in chat apps and improves link previews. It also hands anyone watching DNS a semantic label for the content.
• Randomness used as the only control. The random identifier stops a targeted guess. It does nothing against bulk discovery, because discovery never involves guessing.
• Open access by design. A share link must work for people without accounts, so the endpoint cannot check authorization. The token becomes the entire access control model.
• No index suppression or expiry. Nothing in the reporting suggests the share pages carried noindex directives, robots rules, or a time limit. Public, crawlable and permanent is the wrong default for a document that may contain a salary review.

The weakness categories are well documented. Letting anyone who can reach a URL read private data falls under MITRE’s weakness entry for exposure of sensitive information to an unauthorized actor, and the missing per-object authorization check maps to broken access control in the OWASP Top Ten. Neither label captures the operational detail that made this one easy to exploit: the DNS label carried the description.

No CVE has been assigned at time of writing. A hosted service has no distributable package to patch, so the remediation is a product change, which is why the interesting question is what shipped when sharing came back.

Designing a Share Endpoint That Cannot Be Enumerated

The goal is a URL that is unguessable, unindexable, revocable, and absent from metadata channels. Concrete steps for a new build or a retrofit:

• Put the secret in the path, never in the hostname. A URL like https://app.example/share/<token> exposes only app.example to DNS; the token stays out of passive DNS, out of certificate transparency logs and out of TLS SNI.
• Generate the token from a CSPRNG using a long random byte string, never a counter, a timestamp, or a hash of the conversation title. Base64url encoding of that randomness keeps the string short enough to paste while leaving a search space no enumerator can walk.
• Keep the conversation title on the server. Render it after the token lookup succeeds, and never derive any part of the URL from user text or model output.
• Default every share to unlisted. Offer publishing to search engines as a separate, explicit action with its own warning.
• Send X-Robots-Tag: noindex, nofollow, noarchive on the share response, and set Referrer-Policy: no-referrer so the token does not travel to third-party assets.
• Expire links by default, let the owner revoke, and mint a fresh token on every re-share.
• Rate-limit token lookups per IP and per account, and alert when misses spike. Enumeration appears as a burst of not-found responses long before it appears as a breach.
• Show the sharer an access log: timestamp, coarse location, and whether the visitor arrived from a logged-in session.

Three architectures cover most of the ground, and they differ mainly in where the access decision lives. A random path token with a server-side lookup gives instant revocation because the row can be deleted, at the cost of a database read on every view. A signed token with the expiry and object ID baked into the URL removes that read but makes revocation hard, since the only way to kill a signed link is to rotate the signing key and invalidate every link at once. An authenticated viewer gate is the strongest control of the three and the least likely to ship in a consumer product, because it converts a viral share into a signup wall.

The trade-offs are real. Opaque paths break social previews and make support tickets harder to triage, which is why teams reach for readable subdomains. An authenticated viewer gate cuts reach, the opposite of what a growth team wants. Both costs are payable; a leaked board deck costs more.

Server-side rendering of a title plus a short-lived path token is the middle path most teams should take. It keeps the link friendly in a chat window, keeps the description out of DNS, and keeps a revocation switch in the operator’s hand.

Detection: Finding Your Own Share Links First

The channels Claroc used are open to the company that owns the domain, and monitoring them costs less than a press cycle.

• Subscribe to passive DNS data for your share domains and alert on any new hostname that resolves publicly. If share links move to a path, the same check becomes a scheduled search for your hostname in urlscan.io results.
• Watch Certificate Transparency logs for subdomains of the share domain, since certificate issuance enumerates what exists.
• Plant a canary: create an internal share link with a unique marker string, never distribute it, and alert if that string appears in an external dataset or search index.
• Segment analytics by visitor type. Traffic from datacenter ASNs, scanner user agents, or a wave of zero-referrer hits on one link is an enumeration signal, not growth.
• Alert on share creation volume per account. A user sharing hundreds of conversations in an hour is either a scraper or a compromised session.
• Retain share-access logs long enough to investigate. A default retention window measured in days leaves nothing to work with when an inquiry arrives three weeks later.

Meta’s Response and the Condition for Re-enabling

Meta paused the feature, and The Verge later reported that sharing was turned back on. A pause removes the exposure for as long as it lasts. It does not change the mechanism that produced it, and that mechanism lives entirely in how the URL is constructed.

The commercial pressure to restore the feature quickly is easy to see. Sensor Tower figures reported by Yahoo Finance put the Muse app at 10.9 million U.S. downloads in its first 40 days, and a sharing loop is one of the cheapest acquisition channels a consumer AI product has. That is exactly why the fix has to be structural rather than a temporary switch.

Three questions decide whether the re-enabled version is safe: does the token sit in the path rather than the hostname, do share responses carry noindex and no-referrer headers, and can a user revoke a link already sent. Meta has not published the new URL scheme. Until it does, treat any Muse share link as a public document and assume a DNS sensor saw the hostname the first time it was opened.

Share Feature Audit Checklist

• Confirm no user-supplied or model-generated text appears in any hostname, subdomain, or path segment that identifies content.
• Verify the token comes from a CSPRNG with a wide random space, and confirm it is not a counter, a timestamp, or derived from the conversation title.
• Check that share responses return X-Robots-Tag: noindex and Referrer-Policy: no-referrer.
• Open a share link in a private window with no cookies. If it works, confirm that is intended and that the object is scoped correctly.
• Verify every shared object can be revoked by its owner, and that revocation invalidates the token rather than merely hiding the page.
• Confirm an expiry default exists and is enforced server-side, not only in the interface.
• Review access logs for share endpoints: retention window, ASN capture, and who can read them during an investigation.
• Run a passive DNS query and a urlscan.io search against your own share domain, then read the results the way an attacker would.
• Confirm rate limits on token lookups and an alert that fires when not-found responses spike.
• Check that every request behind the rendered page re-validates the token, including the API calls that fetch the conversation body.

Claroc’s finding did not depend on anything exotic. It depended on a title in a DNS label and a page that stayed public after it was shared. Both are decisions a team makes in an afternoon and lives with for a release cycle, which is why the checklist is worth running before the next share button ships.

Sources and References

Sources cited while researching and writing this article:

• Meta pauses Muse AI chat sharing after researchers find over 6,800 discoverable links
• Meta pauses Muse sharing after researchers find AI chats on the web
• Meta suspends Muse sharing after sensitive documents turn up in shared chats
• MSN
• Meta Suspends Muse Sharing After CEO Reviews, Loan Files, and Executive Search Notes Surface
• Meta turns Muse sharing back on
• weakness entry for exposure of sensitive information to an unauthorized actor
• OWASP Top Ten
• Meta’s Muse AI agent hits 10.9 million downloads as ChatGPT slides 25%