Elon Musk's Grok leaked its own internal confidential information, fully exposing the salary and performance details of SpaceX and Tesla, and even patient privacy was not spared.

Grok never fails to deliver absurdly unexpected blunders that catch people completely off guard.

Just recently, security firm Claroc discovered that more than 35,000 applications built with Grok are accessible without login, and some of them directly expose corporate confidential information and personal privacy data.

The most notable case is that SpaceXSI, the merged entity of SpaceX and xAI owned by Elon Musk, and X are also on the list of affected parties.

Employee onboarding plans, sales customer data, advertising proposals... even the most sensitive internal information of these companies has been leaked to the public.

Moreover, Tesla, which has not been merged with the above entities, did not escape the leak either. A service center scorecard posted the names, work efficiency and bonus details of 22 technicians on a public web page.

What is more ridiculous is that not only internal employees who use the product have been affected, the leaked content also involves sensitive information of ordinary users.

The leaked data includes ICU patients' laboratory test results, imaging examination records, ventilator usage logs, and plaintext account passwords of enterprise employees.

It is almost unbelievable that using Grok can give strangers one-click full access to all your private information for free.

What exactly has been leaked?

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

Although most of these applications are trivial AI-generated tools made by ordinary users, such as mini-games and calculators...

After screening through models and manual sampling, Claroc estimates that about 650 to 800 of these applications contain private data.

The involved institutions include SpaceXSI, X, and 30 other enterprises, 6 of which are listed in the Fortune 500.

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

1. A brief for ICU patients, including patients' laboratory test results, imaging examination records and ventilator usage status.

2. A working hour management application for a contractor, which writes the plaintext passwords of 18 accounts into the script, and anyone who visits the page can download the data.

3. SpaceXSI's internal sales tool, which contains strategic customer accounts, sales business opportunities and internal team information.

4. Tesla service center scorecard, which contains employees' names, work efficiency and bonus details.

......

After going through all the cases, it does seem unreasonable that some users would record their own passwords and medical examination reports in the Vibe Coding tools.

But Grok directly made all this data public to everyone, which is still an extremely unreasonable and flawed design.

So how did this data, which was supposed to only circulate internally within the company, end up on public web pages?

How did a random link become an entry point to expose all private data?

Simply put, when you use Grok vibecoding, it will assign a unique URL to each published application, in the form of random-name.grok.me.

These random names are composed of several words, and the original design intention is to make them difficult for others to guess. But the problem is, hard-to-guess URLs do not equal secure access permissions.

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

To put it simply, every time 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 store them in a searchable database.

Thus, a discovery path is formed:

Someone visits the application → the DNS query leaves a record → the domain name is added to the passive DNS database → external personnel find the application addresses in batches.

If the access permission of the application is set to "Anyone with the link", then anyone who finds the URL can open it directly.

In other words, Grok uses random URLs to increase the difficulty of applications being discovered, but it does not really solve the access control problem.

For the sake of fairness, Claroc also conducted a control test on ChatGPT applications: their application addresses may also be included in passive DNS, but the sharing panel is set to "Only me" by default. Even if others find the URL, they cannot access it.

This is one clear advantage of ChatGPT over Grok!

In addition, in order to verify whether the code generated by Grok is reliable and how it handles team permissions.

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

Although Grok did automatically add Google and X login functions, the researchers found a very low-level error after checking the code:

The application adds the visitor to the team first, and then checks whether he is a team member. That is, it pulls you into the group first, and then checks if you are a group member.

Which means everyone will be recognized as a group member...

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

In other words, as long as you want to access, the door of Grok is always open for you.

Official Response and Follow-up Progress

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

The company also stated that its employee accounts are set to "Only you" by default, and users need to actively modify the permissions to make the application public.

But Claroc said that in its paid accounts used for testing, the pre-selected option on the publishing panel is "Anyone with the link".

The key point here is:

Being private before publication, and who is allowed to access the application by default when publishing, are two completely separate issues.

If you click through the entire "publish" process, the pre-selected access scope will still be all people who hold the link. Even if you confirm multiple times, the system will not automatically add a list of team members to the access permission list.

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

After switching to the "Only you" mode, strangers will be denied access to the page and data interface; unpublishing can also take the application offline within a few seconds.

So Grok does have usable protection measures. The problem is whether these measures are actually enabled when users publish internal tools.

At present, this incident has sparked heated discussions on X. Some people think that it is the users themselves who opened the permission incorrectly, while others think that Grok's default permission setting is problematic.

As for the follow-up processing, SpaceXSI did not start removing the relevant links until several hours after Ars Technica sent the interview email.

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

However, a large number of applications created by other users are still accessible, and Claroc has begun to contact the affected institutions on its own.

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

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/

This article is from the WeChat official account QbitAI, written by henry, and is republished with authorization from 36Kr.