Meta Pauses Muse Sharing After 6,800 GhostShares Found via Passive DNS

Shared AI Chats, Seen by DNS

On October 20, Meta paused conversation sharing in Muse AI. The trigger was a report from security firm Claroc: researchers enumerated more than 6,800 Muse share links with a single passive-DNS query, many containing business and personal information never meant to be public. Ars Technica reported first; The Verge obtained Meta's confirmation.

Scope first: the flaw affected pages users chose to share, not all private Muse conversations. Sharing generates a public link — designed so that "only people with the link can view it." Claroc showed that assumption never held.

The Mistake: Putting Titles in the Hostname

The technical detail deserves every share-feature developer's attention. Muse hosted shared content under cf.metaaiusercontent.com, with each share's hostname combining a readable conversation title and a random ID, for example:

home-sale-budget-9f21c8a3.cf.metaaiusercontent.com
loan-application-draft-a4c9e2.cf.metaaiusercontent.com

The random ID made brute-force guessing impractical. But DNS lookup records are publicly queryable. Passive-DNS services log the domain resolutions they observe — including the full hostname. So when anyone (the sharer, the recipient, any middlebox) resolved one of these links, the complete hostname — title and secret ID alike — landed in public DNS history. Claroc needed just one passive-DNS query to pull back thousands of entries, listed by title like a table of contents.

Claroc named these discoverable-but-unintended exposures GhostShares. Researchers opened several hundred pages to verify and found: a marketing company's CEO-level revenue review, a small-business loan application (with the requested amount), a property investor's full financial report (with addresses and exact return figures), a bank fraud alert with partial account details, a company's full-year staff vacation calendar, and confidential prep notes for an executive-search call with a frontier AI lab (naming the internal contact and meeting time).

An honest footnote, from Claroc itself: 6,800 is the count of deduplicated share hostnames, not 6,800 confirmed sensitive conversations — only a few hundred were opened, most pages were ordinary, there is no evidence of malicious misuse, and affected names and figures were withheld.

robots.txt Can't Stop DNS

The sharpest technical lesson: Muse's robots.txt asked search and AI crawlers to avoid share paths — and it was useless. Because robots.txt governs crawlers; DNS records govern resolution history. Different layers. Crawlers staying away doesn't erase lookup records.

Nor is this an isolated case. ChatGPT's shared conversations were previously exposed via search-engine indexing; Grok's shared chats had similar problems. AI products are re-stepping on Web 2.0's rakes — except this time, users feed agents more sensitive, less structured data: financial records, personnel schedules, trade secrets.

Claroc found a second discovery path too: 75+ archived scans of Muse share pages on urlscan.io. Even if DNS records were scrubbed, third-party archives keep copies. After Meta paused the feature, researchers rechecked 40 previously accessible links — all dead. But the titles in DNS history don't go away.

Zuckerberg's Promise, One Month Earlier

The irony: just a month earlier, Zuckerberg had called Muse "built from the ground up for privacy and security." Meta spokesperson Tracy Clayton's statement to The Verge was restrained: "we've paused this functionality while we review this report and consider changes to how these links can be discovered." Meta also said it opened a Muse bug bounty for researchers to probe more scenarios.

Claroc submitted the report through the bug bounty on October 8 (pages verified October 7–8). Twelve days from submission to pause — not slow, but the 6,800 links had been sitting in DNS history far longer.

5 Rules for Share Features in Vibe Projects

Share links are standard kit for vibe projects (sharing an AI-generated page, report, or conversation). GhostShares is a lesson for every indie developer:

• 1. Never put readable information in the hostname or any enumerable part of the URL. No titles, usernames, or project names. Use purely random, long-enough tokens (e.g., 128-bit), in the path or query — never the subdomain.
• 2. "Unguessable" is not "undiscoverable." In threat modeling, ask: which logging systems will this link pass through? DNS, CDN logs, browser history sync, archival services like urlscan — all are discovery surface.
• 3. robots.txt is not access control. It's a request to well-behaved crawlers. Real protection needs auth: share links should require login, be single-use or expiring, or at minimum be revocable by the creator.
• 4. Give share links expiry and revocation. One Muse lesson: once a link is out, you can't take it back. Default 7-day expiry plus one-click revocation shrinks the exposure window dramatically.
• 5. Warn before sharing sensitive content. When a user hits share and the conversation contains likely-sensitive patterns (amounts, account numbers, ID formats), show one confirmation. This is alignment at the product layer: users rarely realize "share" means "publish."

Claroc's enterprise advice is blunter: treat "employee creates an AI share link" as a data exfiltration event to monitor; where controls are inadequate, block muse.ai and metaaiusercontent.com at the proxy or DNS layer. For individuals, the conclusion is simpler: assume anything you typed into an AI chat has already left your computer — a share link just sends it further.

Passive DNS: The Internet's Call Log

To understand GhostShares, understand passive DNS. Normal DNS is "asking directions": you type a domain, a server returns its IP. Passive DNS is "bookkeeping": sensors deployed worldwide silently log every observed lookup — who asked for which domain, when.

These records exist for good reasons: tracking botnets, finding phishing domains, threat intel. But Claroc showed the flip side: if your "secret" was ever resolved as a domain name, it's in the public ledger. Muse share links were exactly that shape: title in the subdomain → sharer/recipient/middlebox resolves it → full hostname logged by sensors → anyone retrieves it with one query.

The key word is "passive": no scanning, no guessing, no breaching Meta's servers — just querying history. Claroc described "one passive-DNS query bringing back thousands, listed by title like a table of contents." That's why random IDs couldn't save it — random IDs defeat guessing, not bookkeeping.

The developer lesson is blunt: treat any string that appears in DNS queries as public. Subdomains, and in some cases plaintext SNI (the domain in TLS handshakes), must never carry secrets. Secrets belong in path/query/body inside encrypted channels.

How Claroc Investigated: Method and Boundaries

• Enumeration: queried passive-DNS sources for *.cf.metaaiusercontent.com, filtered wildcard-scan noise, got 6,800+ share hostnames;
• Sampled verification: opened only a few hundred pages — "enough to prove the problem" vs "reading everyone," they chose the former;
• Stop lines: stopped at the first password-gated page; didn't contact affected people/businesses (couldn't confirm intent); withheld all identifying details;
• Disclosure path: submitted via Meta's bug bounty on Oct 8 instead of blogging for traffic; published only after Meta paused the feature on Oct 20.

A model process for researchers — and a reminder for product teams: bug bounties aren't decoration. Meta's channel drove a feature-level takedown in 12 days. If your vibe project has real users, publish a security.txt and a vuln-report inbox. Researchers like Claroc may be your best free QA.

Full Timeline

• Earlier: Muse launches with the sharing feature;
• Oct 7–8: Claroc verifies pages enumerable and openable via passive DNS;
• Oct 8: Claroc submits via Meta's bug bounty;
• Oct 20: Claroc publishes; Meta confirms the pause to The Verge; researchers recheck 40 historic links — all dead;
• Oct 21: Ars Technica, Cyber Security News, TechBriefly, Digit and others follow.

Twelve days from report to pause — fast by industry standards (Samsung took 3 weeks to ban ChatGPT after its code leak in 2023). But titles in DNS history can't be deleted: response speed never recovers data already in the ledger.

History Rhymes: Three AI Share-Link Failures

• ChatGPT (2023–2024): shared conversations indexed by search engines, Googleable. Cause: share pages allowed crawler indexing. Meta learned this lesson — its robots.txt disallowed — but the root moved;
• Grok (2025–2026): shared chats visible beyond intent. Cause: insufficient link discoverability design;
• Muse (2026-10): robots.txt stopped crawlers, not DNS. Cause escalated from "application-layer discoverable" to "infrastructure-layer discoverable."

The shared root cause: PMs read "share" as "send a link"; security reads "share = publish." Every incident is a gap between users' assumed "point-to-point" and actual "network-discoverable." The first line of your share-feature spec should state the link's discoverability radius.

Enterprise Playbook

• 1. Inventory: which AI products' sharing features are employees using? Muse, ChatGPT, Claude, Grok… list them. You'd be surprised who's already sharing quotes via AI;
• 2. Classify: what may be shared (public materials, sanitized demos) vs never (customer data, finance, HR). One page in the handbook;
• 3. Technical controls: proxy/DNS-layer policy on share domains like muse.ai and metaaiusercontent.com — block or audit-log. Claroc's words: "monitor share creation as outbound data transfer";
• 4. Drill once: passive-DNS your own domains for subdomains that shouldn't exist. Most companies are startled by their first lookup.

For individuals, one rule: before sharing, assume a stranger will open the link. If that bothers you, don't share — or scrub first.

Threat-Modeling Your Share Links: A Self-Check Table

• Readable info in the link? Titles/usernames/project names → remove all, use purely random tokens;
• Token length? ≥128-bit from a cryptographic RNG — no auto-increment IDs, timestamps, or MD5(title);
• Which "bookkeeping" systems will the link pass? DNS (subdomains!), CDN logs, email gateways, archival sites like urlscan, browser history sync — ask "what if it logs this" for each;
• Discoverable by default? noindex meta tags; robots.txt is a start, not the finish — consider DNS layer and archives;
• Revocable? Can creators kill a link with one click? Default expiry? Meta paused the whole feature — suggesting per-link revocation wasn't even designed;
• Auth required? "Link = access" is the weakest tier; at least offer login-gated or burn-after-reading for sensitive shares;
• Do users know they're "publishing"? Does the UI plainly state "this link is forwardable; content will be publicly accessible"? Muse's users clearly didn't know titles entered DNS.

Tape this table to your spec. It prevents ~80% of GhostShares-class incidents. The remaining 20% is unknown attack surface — that's what bounties and external researchers are for. Leave them a channel (security.txt); it matters more than anything.

Why VibeFix Covers This: AI-Generated Sharing Is the Hot Zone

"Share what the AI made" is standard vibe-product kit: share an agent-generated report, an AI conversation, an AI-built page. v0, Lovable, Bolt made "one-click shareable deploy links" a core selling point. GhostShares proves a product's security level is its share feature's security level.

Vibe scenarios amplify risk three ways. First, more sensitive content: users feed agents work documents, data reports, code — an order of magnitude more sensitive than chitchat. Muse's leaked loan applications and financial reports prove it. Second, less savvy users: many vibe users are non-technical; "share link" means "show a friend" to them — DNS and archival sites aren't in their mental model. Third, lazier developers: share features are often "have the agent whip one up," and agent-written share links will likely be "title in URL + auto-increment ID" — GhostShares verbatim.

So if AI is writing your product's share feature, check its link format now: readable titles in the URL? Random or sequential IDs? Expiry? Three questions, five minutes. Meta's 6,800 leaked links teach the price of skipping them: the whole feature goes down.

One open question: Meta chose to pause the entire feature rather than fix the URL scheme. VectorWire's read: the fix isn't just a URL-format swap — it likely needs architectural rework (auth systems, historic link migration, the un-erasability of DNS history). The lesson for vibe teams: design share features revocable, expirable, and auditable from v1. Retrofitting costs a rewrite. Don't repay GhostShares' tuition.

One more overlooked detail: Claroc found Muse share pages "returned the title first, loading conversation content via JavaScript." Simple curl saw titles only — but researchers used ordinary browser sessions and content loaded fine. The defensive lesson: never treat "frontend rendering" as access control. Sensitive content needs server-side auth, not the illusion that "JS-loaded means crawlers can't see it." Leaked titles were bad enough; one weaker auth tier and it's full text.

Closing line: a share link encodes access capability into a string, and strings flow through DNS, logs, archives, chat histories — every handler a potential "publisher." Design share features by first assuming the string appears in a public GitHub repo tomorrow, then deriving what may and may not go inside. Designs that survive that thought experiment deserve the name "sharing."

Glossary

Passive DNS: a historical database of "who resolved which domain when." Built for threat intel; this time the key to enumerating share links. It logs resolution behavior, not page content — but Muse put titles in hostnames, hand-delivering content summaries into behavior logs.

SNI (Server Name Indication): the domain sent in plaintext during TLS handshakes. Even on full HTTPS, middleboxes may see it. Same principle: domain-layer information is public by default.

urlscan.io: a public website-scan archive; submitted URLs are publicly viewable. Claroc found 75+ archived Muse share scans there — "a user pasted the link into a scanner" is itself a leak path. Someone in your user base has definitely done this.

GhostShares exposure chain: share link, subdomain, passive DNS, 6,800+ enumerable