Somewhere inside SpaceXSI, the company behind Grok Build, a sales team was building apps with the company’s own vibe-coding agent. One was an onboarding plan, marked confidential, for a new member of the enterprise sales team. Another mapped 594 sales accounts across a territory. There were internal system addresses for the sales team’s tools, and advertising proposals for the company’s products. All of it was sitting in links that anyone on the internet could find. The company took them down within a few hours of a journalist emailing to ask about them.
That is the sharp end of a leak Claroc says exposed tens of thousands of Grok Build apps — not through a hack or a guessed password, but through a design choice about where the random part of a web address sits. The vendor’s own material was caught in it; almost everyone else’s was still out there when the story was published.
Grok Build put the randomness in the wrong place
Grok Build lets users share apps through links that are randomised, so only people who know the exact address can open them — the privacy of the link rests on the address being unguessable. But Grok Build put the random part in the wrong place.
Instead of sitting to the right of the domain, as it does in a Google share link, the randomness sits to the left of it: each published app gets its own hostname, in the form <name>.grok.me. And every time a browser looks up one of those hostnames, the lookup is recorded by passive DNS services — commercial databases that log which hostnames have been resolved and make them searchable. A link that was supposed to be unguessable becomes enumerable with a single query.
Researcher Sree Aprozper of Claroc put it plainly. “I went to my local [passive DNS] provider and searched for the pattern *.grok.me, and within minutes I was able to enumerate almost every live Grok Build app.”
The scale he found is stark. A passive DNS search returned 43,601 names under grok.me. Of the 37,571 apps still online when Claroc tested them, 35,578 — about 95 percent — opened without any sign-in. The remaining 1,993 returned an access error, consistent with the “Only you” or “Invited users” settings. Aprozper said his tests over the past week showed that Grok sets links to “Anyone with the link” by default, and users have the option to change that. “I did not have to authenticate or provide a token or anything. I just clicked and got all the data,” he said of one app he opened.
And opening the link is not the end of it: except in rare cases, a public Grok Build link grants access to the app and all its data — and the data can be modified by anyone holding the link.
What the open links held
Most of what Aprozper found was innocuous: personal to-do lists, hobby projects, the ordinary clutter of a tool people use to build small things. But the exceptions were serious. Among the examples he shared with Ars Technica were a Google Sheet containing the names and ID numbers of all employees at a “federal civilian agency,” a galley checklist from a celebrity cruise line listing the names of the individuals assigned to each role along with dates and hours, a person’s medical examination results, an app that appeared to be an internal business plan containing a spreadsheet with 10,000 customer rows — each with a name, email address and other details — and advertising proposals for SpaceXSI and its products.
Claroc’s public report omitted hostnames, app titles and links, and the firm says the saved copies will be deleted once notifications are complete.
The vendor’s own apps
The most telling part of the story is whose data was in the leak. SpaceXSI itself had created 24 Grok Build apps that included sensitive data about its own operations — the confidential onboarding plan, the 594-account territory map, internal system addresses, advertising proposals. It is not known whether the company intentionally shared the data or inadvertently shared it.
Claroc notified SpaceXSI of the spill on Sunday, November 8, providing exposure counts, two test apps and four proposed fixes. When no one responded, a Claroc official took to X to tag both Musk and Grok manager Matt Palmer about the threat. SpaceXSI began removing its links within a few hours of Ars Technica sending an email with questions on Monday. At the time the article went live, all 24 links returned an “app not found” error — while almost all of the other exposed data remained available.
The only data that got protected quickly was the vendor’s own — the federal agency’s employee list, the medical results and the 10,000-row customer sheet were among the material the investigation found exposed, while almost all the other exposed data remained available at publication. Whether that is because SpaceXSI was the only party that knew, or the only party that could act fast, is one of the questions the company has not answered.
Private by default?
A representative of Cursor — the AI coding service SpaceXSI recently acquired — told Ars Technica that Grok Build “apps are private by default and nothing goes public unless the creator chooses to share it,” and that competing coding agents from ChatGPT, Lovable and Bolt also give users the ability to generate shareable links. The representative did not respond to follow-up questions, including whether SpaceXSI intentionally exposed its proprietary information, why the company removed the data after Ars asked about it, and whether it planned to notify customers who had exposed similar material.
There is a genuine tension here, and it is worth stating plainly. The researcher’s tests found the default to be “Anyone with the link.” The vendor says nothing goes public unless the creator chooses to share. Both can be true at once if “choosing to share” means accepting a default in the same chat window where the app was built — Claroc notes that people create the apps by describing them in chat and publish them from that same window. But that reading makes the default the whole argument: if publishing sits one tap from building and the default is public, the exposure is the product working as designed. Whether user sharing choices also played a role, and whether SpaceXSI shared its own apps intentionally, remain open questions — and the vendor has not resolved them.
Claroc proposed four fixes: put shared apps on hard-to-guess paths under a single host, add organisation-domain-restricted sharing, default to “Only you” while showing who can open an app before publication, and add warnings for database-backed apps without sign-in. Claroc has also begun contacting affected organisations itself, because SpaceXSI’s response did not say it would notify app owners. Three organisations had been emailed by the time of publication.
A month earlier, the same flaw
Claroc found this exact failure a month earlier: its GhostShares research showed that shared links in Meta’s Muse agent could be found the same way — more than 6,800 share hostnames in passive DNS records, each address carrying the conversation’s title plus a random identifier in the hostname. Meta paused Muse’s sharing feature on October 20, 2026, and restored it on October 22 with new URLs for items shared before the fix. The old hostnames and their titles remain in passive DNS history.
Grok Build has also been here before, in a different way. In July 2026, an independent researcher found that the Grok Build command-line tool was uploading entire tracked Git repositories to xAI’s servers; the company added zero-data-retention and privacy controls, and Musk pledged the total deletion of prior uploads. A different flaw — an upload problem, not a share-link problem — but a familiar shape: a privacy boundary thinner than it looked, and a fix that arrived after the exposure.
For anyone using Grok Build’s shareable links, the practical advice from the reporting is simple: choose the “invite others” option unless you intend the app to be widely available. And for the company that built the tool, the uncomfortable fact stands on its own: its own confidential sales material was sitting in the open, discoverable in minutes, and it came down only after a journalist asked why it was there.
