Grok Build Apps Expose 35,000 Unauthenticated Endpoints

Grok never fails to disappoint when it comes to making people lose their composure.

henry, reporting from the Non-Orthodox Temple QuantumBit | WeChat Official Account QbitAI

Grok never fails to disappoint when it comes to making people lose their composure.

Just moments ago, security firm Claroc discovered that over 35,000 applications built with Grok can be accessed without logging in, and some of them directly expose corporate secrets and personal privacy.

Most striking is that Musk's own SpaceXSI (the company formed after the SpaceX-xAI merger) and X are among them.

Employee onboarding plans, sales client data, advertising proposals... even their own family's secrets have been exposed.

And Tesla, which didn't merge, didn't escape either. A service center scoring sheet put the names, work efficiency, and bonus details of 22 technicians on a public webpage.

Even more outrageous is that not only did employees of their own products suffer, but the leaked content also involves sensitive information of ordinary people.

Including ICU patients' lab results, imaging exams, ventilator usage records, and plaintext account passwords of corporate employees.

Good heavens, is Grok really offering free one-click doxxing?

What exactly was leaked?

Specifically, at the very beginning, Claroc tested 43,551 (37,571 still online) Grok Build application addresses and found that 94.7% of the online applications could be opened without logging in.

Although most of these applications are AI slop made by you and me, like mini-games, calculators, and such...

But panning gold from sand, after model screening and manual sampling, Claroc estimated that roughly 650–800 applications contain private data.

The institutions involved include SpaceXSI, X, and another 30 companies, 6 of which are Fortune 500 companies.

How sensitive is this data? A few examples will make it clear:

1. An ICU patient briefing containing patient lab results, imaging exams, and ventilator usage status.

2. A contractor's timesheet management application that wrote the plaintext passwords of 18 accounts into a script, which anyone visiting the page could download.

3. SpaceXSI's internal sales tool, containing strategic client accounts, sales opportunities, and internal team information.

4. A Tesla service center scoring sheet, containing employee names, work efficiency, and bonus details.

....

Looking at it all, although there really are "good samaritans" who record their own passwords and medical checkup reports in Vibe Coding projects.

But Grok directly making them public is simply too outrageous.

So how did this data, which should only circulate internally within companies, end up on public webpages?

How does a random link become a doxxing entry point?

Simply put, when you use Grok vibecoding, it assigns each published application an independent URL, in a form similar to randomname.grok.me.

These random names are composed of several words, designed to make them hard for others to guess. But the problem is, hard-to-guess URLs don't mean secure access permissions.

Claroc found that these application addresses can be found in bulk through Passive DNS databases.

Simply put, whenever someone visits a website, the computer needs to query the server address corresponding to the domain name through DNS. Some DNS resolution services collect these query records and put them into a searchable database.

Thus, a discovery path is formed:

Someone visits an application → DNS query leaves a record → domain name enters the Passive DNS database → outsiders find the application addresses in bulk.

If the application's access permission is set to "anyone with the link," then as long as the URL is found, it can be opened directly.

In other words, Grok used random URLs to increase the difficulty of discovering applications, but didn't truly solve the access control problem.

For fairness, Claroc also ran a control test with ChatGPT applications: their application addresses could likewise be indexed by Passive DNS, but the sharing panel defaults to "Only me." Even if someone finds the URL, they can't access it.

This is a win for ChatGPT!

Furthermore, to verify whether Grok-generated code is reliable and how it handles team permissions.

Claroc later used fictional data to build its own customer management application for a four-person sales team.

Although Grok did automatically add Google and X login functionality, researchers found a rookie mistake after checking the code:

The application first adds the logged-in user to the team, then checks whether they are a team member. In other words, it pulls you into the group first, then checks if you're a group member.

Of course everyone is a group member then...

Subsequently, the researchers logged in with a Google account that had never been invited, and as a result, not only did they see all customer data, but they also successfully modified one record and deleted another.

In other words, if you want in, Grok's door is always open for you.

Official response and aftermath

After the incident was exposed, SpaceXSI told the media that applications are private until the creator actively shares them, and publishing requires multiple steps.

The company also stated that its employee accounts are set to "Only you" by default, and making an application public requires actively changing the permission.

But Claroc said that in the paid account it used for testing, the publishing panel had "Anyone with the link" pre-selected.

The key here is:

Being private before publishing and who gets access by default at publishing time are two separate questions.

If you click all the way through "Publish" and the final pre-selected access scope is still everyone with the link, confirming a few more times won't automatically add a team member list.

The researchers also verified Grok's existing permission control features.

After switching to "Only you," strangers accessing the page and data interface are rejected; unpublishing can also take an application offline within seconds.

So Grok has protection measures that work. The problem is whether these measures are actually applied when users publish internal tools.

Currently, this matter has already sparked debate on Twitter, with some believing it's users who set the permissions themselves, and others believing it's Grok's permission settings that are the problem.

As for the follow-up handling, it wasn't until within hours after Ars Technica sent an interview email that SpaceXSI began removing the relevant links.

As of the publication of the report, all 24 apps created by SpaceXSI and X employees have been taken offline.

However, a large number of apps created by other users remain accessible, and Claroc has also begun contacting the affected organizations on its own.

As for whether the platform will proactively notify other affected customers, Ars Technica has not yet received a clear answer.

Reference links [1]https://arstechnica.com/security/2026/11/grok-build-coding-agent-leaks-oodles-of-confidential-info-some-belonging-to-spacexsi/ [2]https://blog.claroc.io/ghostshares-grok-build-apps/