
GhostShares 2: Grok apps exposed xAI's business secrets and private data
We found more than 35,000 apps built with Grok that anyone with the link could open. Among them were SpaceXSI's own sales territory map, an X ad proposal to a U.S. federal agency marked confidential, an ICU patient's la…
以下正文同步自 Hacker News 最新,版权归原站所有,已转换为易读排版。
We found more than 35,000 apps built with Grok that anyone with the link could open. Among them were SpaceXSI's own sales territory map, an X ad proposal to a U.S. federal agency marked confidential, an ICU patient's lab results, a hospital group's staff list and a timesheet that hands out its employees' passwords.
Grok’s Build mode, where people describe an app in the chat and Grok writes it.
On November 8, 2026, we were working through a long list of web addresses under grok.me, the domain where Grok, the AI assistant from SpaceXSI (the company formerly called xAI), publishes the apps people build with it. Nobody had sent us any of them. We opened the first page of each one once, from the public internet and signed in to nothing, the way anyone would in an incognito window.
One address named a new hire and ended in “onboarding plan”. It was the onboarding plan for a new member of SpaceXSI’s own enterprise sales team, marked confidential: the systems to get access to in the first week, internal system addresses, the sales team’s tools, 19 of the company’s internal chat channels, the colleagues to meet and a 30-day plan. Nothing asked us to sign in.
Figure 1. The top of SpaceXSI’s onboarding plan, names covered. Click any figure to see it larger.
We were shocked. The company that makes Grok had its own internal material open to anyone holding the link, and we had never been given it.
We call pages like this GhostShares: they open for people who were never given the link, and those people can find them on their own. Last month it was Meta’s Muse. This time it is the apps people make by describing them to Grok and publish from the same chat window.
We reported the onboarding plan to SpaceXSI that afternoon, along with an X advertising proposal from the same list. Then we went back through every first page we had saved, more than 30,000 of them, looking for anything else built by SpaceXSI and X staff. By the end of the full read we had 24 open apps:
One more, an archive of a streaming service’s ad measurement studies, asked for a password. It was the only SpaceXSI or X app we found that did.
Figure 2. SpaceXSI’s sales territory map. Account names and cities are covered.
Figure 3. The budget page and footer of the X proposal to a U.S. federal agency, marked Confidential. Agency details and amounts are covered.
On Grok the link is the hostname: every published app gets its own address, <name>.grok.me. When someone opens one, their computer asks a DNS resolver where that name lives. Passive DNS services collect those lookups from the resolvers they run or buy data from, and anyone with an account can search them by pattern. So the first time the people a link was meant for use it, the name lands in a commercial index.
Figure 4. Illustrative. Every hostname is made up.
In Muse (GhostShares), each address carried the conversation’s title. Grok proposes four random words instead, and about half the names we saw were exactly that. Nobody would guess one, and nobody needs to, because the dataset lists them.
ChatGPT also gives each app it publishes its own hostname, and it handles both steps differently. When we clicked Share on an app ChatGPT built, access was set to Only me until we changed it. Its addresses are two levels deep and carry the account’s username, in the form <app-name>.<username>.chatgpt.site, so a name is much harder to guess than four random words under one shared domain. It is no harder to find: once someone opens the app, the name reaches passive DNS data the same way, and one pattern search lists it. That leaves the default to do the work. If a ChatGPT address does turn up in a DNS list, it leads to an app that only its owner can open.
Shared chats work differently. Claude’s published artifacts live at claude.ai/public/artifacts/<id>, ChatGPT’s shared conversations at chatgpt.com/share/<id> and Gemini’s at gemini.google.com/share/<id>. The secret part of each link sits in the path, so DNS never sees it. Published apps are another matter: Grok, ChatGPT, Lovable, Replit, Base44, Google AI Studio and Meta’s Muse give each app its own hostname, and v0 and Bolt deploy to hostnames too. Every hostname gets its own DNS lookup, and that lookup is what makes the name findable.
A path is not private either. In August 2025, more than 370,000 shared Grok conversations on grok.com/share/ links turned up in Google search, because search engines could index the pages. Moving the secret into the path keeps it out of DNS, but search indexing and link scanners can still expose it.
Of the 37,571 Grok apps still online when we tried them, 35,578 (94.7%) opened for anyone. Only 1,993 (5.3%) answered with HTTP 401, the error an app set to Only you or Invited users returns.
Most open apps were games, landing pages and calculators. About 1 in 10 held sensitive material, internal business data or personal data, and by our estimate roughly 2% held material serious enough to rate high or critical. Among the ones we confirmed by hand:
Figure 5. The timesheet’s script file, which every visitor’s browser downloads: 18 accounts with plain-text passwords, every value covered.
Besides SpaceXSI and X, 30 organizations had internal data in open apps that showed who they belonged to. We name none of them here.
From the outside we could only see that apps were open. Whether a visitor can also change their data takes changing it, and we were not going to do that to anyone else’s app. So we built two apps of our own, with made-up data, to see what security Grok builds in when nobody asks for it, and when a team does. Building works on Grok’s free plan; in our account, publishing needed a paid one. Nothing goes public until the builder clicks Publish. In our account, the panel that opens offered Anyone with the link, Invited users and Only you, with Anyone with the link already selected. We published both apps with whatever it proposed.
The first was a contact list we asked Grok to save “so every visitor sees them”. It got a database and no sign-in. From an incognito window, signed in to nothing, we added a row that the next visitor saw.
The second was a customer list “for my company’s sales team of 4 people”. Grok added sign-in on its own, it said “so names, phones, and emails aren’t left open”, through two buttons, “Continue with Google” and “Continue with X”. The code Grok wrote adds whoever signs in to the team before it checks whether they are on it, so the check always passes. A Google account that was not the owner’s and had never been invited signed in, saw every customer, changed one record and deleted another.
Figure 6. Illustrative, simplified from the code Grok wrote for us.
Grok has the right settings. Switched to Only you, our first app answered 401 to a stranger on both the page and its data function, and unpublishing the second took its address offline within seconds. They are not the default, and nothing prompts the builder to use them.
What the two apps showed is that Grok leaves out basic controls: an app that stores data with no login lets any visitor change it, and a team login checks who you are but not whether you belong to the team. That is why the open apps we found may be worse than they look. For an app like that, opening the page can also mean being able to add, change or delete the data behind it. We proved this only on our own two apps, and did not sign in to, write to or test anyone else’s.
An AI-built app is made in a chat window and published from the same window, often in minutes, by someone whose job is running a sales territory or a shift roster. The builder doesn’t file a request or install anything IT would see. A territory map and a lunch poll get the same publish button.
The apps also drift. A builder adds a table, a sign-in or a share link with the next prompt, and an app that was harmless yesterday holds customer records today.
“AI app builders turned publishing into a few clicks, and the default answer to who can see it is everyone,” says Asaf Aprozper of Claroc Research.
This works for one app on one builder. One enterprise we know counted 500 AI-built apps, and each one changes with the next prompt.
With our report we sent SpaceXSI four fixes: serve shared apps on a hard-to-guess path under one host, so the link never becomes a DNS name; add an “everyone in my organization” option limited to the company’s email domain; make Only you the default and show who can open the app before it goes live; and warn at publish when an app has a database and no sign-in, building an invite list instead when a request describes a team.
After our report, SpaceXSI answered questions from a reporter covering this research. It said Grok apps are private until their creator chooses to share one, and that publishing takes several steps: click Publish, pick an address and click Publish again, choose between Only you and Anyone with the link, then accept a legal disclaimer and click Publish a final time. It said employee accounts are set to Only you by default, so making one of their apps public also means switching it to Anyone with the link, and that this is more steps than builders such as Lovable ask for.
We agree that nothing goes public before the builder clicks Publish, and we said so above. Our finding is about the access step that follows. In the paid account we used, that step offered Anyone with the link, Invited users and Only you, and Anyone with the link was already selected. Extra clicks on a path that ends with access already set to everyone do not protect the data: the people who published the 35,578 open apps went through every one of those steps.
Only you as the default is the change we asked for, and SpaceXSI already uses it for employee accounts. It is not what ordinary users get, and on its own it did not keep SpaceXSI’s own data in: the 24 open apps described above were built by SpaceXSI and X staff.
We found the app names with common subdomain discovery techniques, which listed 43,601 names under grok.me. We loaded the first page of each app once, from the public internet and signed in to nothing, and read the saved copies offline. 35,578 of them opened.
An AI model flagged the pages that looked private, and we read the flagged apps by hand to confirm them. Checking the model against a random sample we read ourselves puts the total at roughly 650 to 800 apps with private data.
We did not sign in, submit forms, call server functions or use any password or key we saw. Screenshots were made from the saved copies, with personal details covered. Every write and delete happened on our own two apps. We will delete the saved copies once we have finished notifying the affected organizations.
We published now, without the hostnames, because the default is a design choice SpaceXSI defended rather than a bug it said it would fix, and people building on Grok need to check their own apps. SpaceXSI holds the full list of app addresses and can reach every app’s owner, but its response did not say it would. So we are telling the affected organizations ourselves wherever we can find someone to tell: their security team where one publishes an address, and otherwise their security or privacy lead. This post leaves out every hostname, app title and link that could lead a reader to an app or a person, and describes personal material only by kind.
The apps in this post did real work: sales pipelines, galley checklists, staff rosters, customer and order records. Had the same teams bought software for that work, it would have come with company sign-in, roles and an admin who can see who has access. Built with AI, they went live behind a link anyone could open.
Claroc secures the apps people build with AI while they are built and after they go live:
In a 30-minute exposure check, we look for AI-built apps tied to your organization that anyone can open, and show you what they expose.
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。