Newshot Article title: Over 35,000 Grok-Generated Apps Exposed Online, Some Leaking Confidential Data and Passwords
Body:
Over 35,000 Grok Apps Publicly Exposed, Involving Sensitive Internal Data from Multiple Organizations
Researchers at security firm Claroc said yesterday that they found a total of 37,571 Grok-generated apps across the internet, of which 35,578 were accessible to anyone without login.
Of these public apps, 24 were built by employees of social platform X and SpaceXSI, the company behind the Grok AI assistant. Most of the public apps are games, landing pages, and calculator-type tools, but about one-tenth contain internal business data or personal information.
The employee-built apps involved various types of confidential content, including an onboarding plan for new sales staff, a sales territory map labeling 594 customers, and an advertising proposal submitted by X to a U.S. federal agency and marked confidential. SpaceXSI, formerly known as xAI, has now taken down all 24 employee-built apps but has not addressed other users' public apps.
In addition to the employee apps above, internal data from another 30 organizations was identified in the public apps, covering sectors such as construction, energy, healthcare, and defense. Of these, 26 organizations have more than 1,000 employees, and 6 are Fortune 500 companies.
The report estimates that about 2% of the public apps contain high-risk or critical-level sensitive content.
The leaked content includes a searchable list of more than 3,500 employees at a healthcare group, an intensive care briefing for a single patient, and a real-time duty board for a fire department. There was also a contractor's timesheet app that stored all employees' passwords in plaintext in its code.
Users can generate a working app by entering a description of their needs into Grok's chat window. On August 19, Grok opened this feature to users on all subscription plans. This chat-based building tool shares its name with a separate terminal coding tool, both called Grok Build; the latter's code repository upload issue was publicly reported on July 14.
According to Grok's official announcement, each published app is assigned a separate subdomain under grok.me, and app creators can set the scope of access permissions.
Flawed Default Permission Configuration Allows Unauthorized Users to Tamper with Data
An app only becomes public after the creator clicks the Publish button. When researchers tested with a paid account, they found that the next step of the publishing flow offers three access permission options: "Anyone with the link," "Invited users," and "Only me," with "Anyone with the link" selected by default.
This default setting poses a significant risk because app addresses cannot be kept fully confidential. When a user visits an app, the device performs a DNS query for the corresponding subdomain, and passive DNS services record such query requests; anyone with an account on the relevant service can search these records by characteristic patterns.
Grok randomly generates a four-word name for each app, and about half of the discovered apps follow this naming rule. Although such names are hard to brute-force guess, this protection mechanism becomes completely ineffective once an app name has been indexed in a searchable list.
ChatGPT's app-building feature also assigns a separate subdomain to each app, but when users publish an app, the default access permission is "Only me," and it changes only after the user manually modifies it. Therefore, even if a ChatGPT app's address is discovered through DNS data, visitors cannot open it due to insufficient permissions; only the app owner can access it.
The researchers obtained Grok app names through a generic subdomain discovery method and visited each app's homepage while not logged in.
To verify Grok's own permission protection mechanism, the team built two test apps containing fictional data and published them using the default-selected "Anyone with the link" permission.
The first test app was a contact list with its own database but no login verification configured. In a privacy window while not logged in, they were able to add a contact record, and all users who visited afterward could see this newly added content.
The second test app was a customer list for a 4-person sales team, and Grok automatically added "Sign in with Google" and "Sign in with X" buttons to it. But the code Grok generated had a logic flaw: after a user logs in, the system first adds them to the team member list and then verifies whether their identity falls within the authorized scope, so the verification process can always pass.
In the test, an unauthorized Google account not belonging to the app owner successfully entered the app, viewed all customer information, modified one record, and deleted another.
The above tests were conducted only on apps the team built themselves; the researchers did not test whether the discovered public apps carry the same risk of unauthorized modification.
Vulnerabilities Reported to Developer, Enterprises Can Follow Steps to Check for Risks
On Sunday, the researchers reported their findings to SpaceXSI through the contact channel published in the security.txt file, including 2 employee-built apps, and completed reporting information on the remaining 22 employee apps on Monday.
As of the report's publication, SpaceXSI had not issued a formal response to the vulnerability report but had responded to reporters' questions about the research.
SpaceXSI responded that Grok apps remain private until the creator actively shares them. The publishing flow includes multiple steps, where users must choose between "Only me" and "Anyone with the link" permissions and also confirm a legal disclaimer, and that the default permission for employee accounts is set to "Only me."
However, actual testing results showed that 24 apps built by SpaceXSI and X employees were still publicly accessible.
In the report, the researchers recommended that SpaceXSI set "Only me" as the default permission and add an option to restrict app access to users with the company's own email domain.
SpaceXSI's response did not mention contacting the owners of other public apps. The research team has now begun proactively emailing affected organizations to inform them of the risk, and as of the report's publication had completed notifications to 3 organizations. To avoid expanding the risk, the report redacted the addresses and names of all apps.
On October 18, the same research team published research on Muse, pointing out that pages shared by Meta's Muse AI Agent could be discovered through passive DNS. Meta subsequently temporarily disabled the sharing feature and on October 22 announced a fix for the sharing mechanism, assigning new addresses to all shared content.
Claroc mainly provides tools for discovering and securing AI-generated apps, and the company offers the following checking recommendations:
- Inventory the AI app-building tools used by employees. Tools such as Grok, Lovable, Replit, v0, Bolt, Base44, and Google AI Studio can be used without IT department deployment or corporate accounts, so they require priority checking.
- If the enterprise has access to passive DNS data, query the relevant domains of the above building tools and visit the query results through a privacy browser window to verify permissions.
- Confirm that all Grok apps storing internal data have permissions set to "Invited users" or "Only me," and that external users should receive an error page when accessing them.
- Try logging into the app with an account outside the enterprise; if access succeeds, the app lacks an authorized access list check.
- Check whether the scripts loaded by each app contain sensitive information such as names, email addresses, and passwords, and take down apps without a clear owner.
Testing verification showed that after setting an app's permission to "Only me," external users receive a 401 error when accessing the page and requesting data; after performing a takedown, the app stops serving externally within seconds.
Over 35,000 Grok-Built Apps Exposed Online, Some Leaking Confidential Data and Passwords