Grok Build Exposed Data From 35,000 Apps Because of a Secret in the Subdomain

Imagine this: in ten minutes you build an internal dashboard with an AI agent, click "share," and send the link to a colleague. The address is long and made of random words, so it can't be guessed. Then it turns out that anyone who knows how to use a public DNS query database can see it. According to researchers at Claroc, that is exactly what happened with Grok Build, the vibe-coding agent from SpaceXSI (the new name for the merged SpaceX and xAI).

What exactly broke

The idea behind the scheme is sound. It is called capability-based access control: knowing the URL is the same as having permission to access. All that's needed is that the address can't be guessed or found. Three random words give about 38 bits of entropy, that is, billions of combinations. Google does something similar in Docs, but there the random string sits in the path, after the domain.

Grok Build put the random words to the left of the domain, in the subdomain: cinder-crane-sand-frost.grok.me. And subdomain names leak. When someone first requests the IP address of a new host, the record settles into public passive DNS databases. All that remains is to search for everything ending in grok.me. There is nothing to guess; you just read a ready-made list. The URL path does not make it into the DNS query, which is why this trick doesn't work against Google links.

Claroc found 43,601 links on grok.me. More than 35,000 of them, almost 95%, opened the app along with all of its data. Among the findings: 3,784 medical checkups of workers at a Peruvian construction company, a list of 3,565 hospital employees, a spreadsheet of 22 Tesla technicians with productivity and bonuses, and about 4,000 orders from an auto carrier with prices and margins. There were also 24 apps belonging to SpaceXSI itself: a sales onboarding plan marked confidential and a map of 594 customer accounts.

Default versus reality

According to tests by Asaf Aprozper, CTO of Claroc, Grok Build sets access to "Anyone with the link" by default. To lock down an app, the user has to choose "invited people" or "only you" themselves. A Cursor representative (Cursor was recently acquired by SpaceXSI) assured that apps are private by default. Claroc's tests refute this. Ars Technica's further questions went unanswered.

The timeline is also telling. Claroc reported the leak on Sunday, received no reply, and tagged Musk and a Grok manager on X. The links to the 24 internal apps disappeared only a few hours after journalists made inquiries. The rest of the data remained accessible.

The problem is wider than Grok alone. Lovable, Bolt, and Replit also give each app its own address, so their DNS footprints are the same. Grok simply had the most sensitive corporate data. Meta Muse recently suspended its sharing feature after a similar leak. Claude artifacts, ChatGPT share, and Gemini share get this right: the secret lies in the path, and DNS doesn't see it.

What to do in practice

If you or your team built anything in Grok Build, first go into the settings of all your apps and change access to "invited people" or "only you." The same should be checked in Lovable, Bolt, and Replit. Remember that a link that has once gone into passive DNS may already have ended up in other people's databases. If the app contained personal data or commercial proposals, close access and assess whether you need to notify people and clients.

For those building platforms with sharing links, the lesson is this: a capability secret must not be placed in the hostname, only in the path or in a token after the domain. For internal tools, it's better to enable authorization outright and make public access a conscious choice rather than the default.

There are caveats too. The figures come from Claroc's research, and there is no independent verification yet. A public app doesn't necessarily contain sensitive data, and many of the 35,000 may simply be demos. SpaceXSI has not explained how internal documents ended up in open apps or whether it will notify customers. But the main takeaway doesn't change: vibe coding speeds up rollout, and with it, access-configuration mistakes. The habit of "generate and share" should include checking exactly who will be able to open the link.