Summary
- Claroc accessed 35,578 Grok-built applications without authentication, including applications containing sensitive business and personal information.
- The investigation identified exposed material linked to 30 organisations alongside 24 applications built by SpaceXSI and X personnel.
- The operator disputes the implication that applications automatically become public, while Claroc highlights sharing settings and weak generated authorisation.
Thousands of applications generated using Grok have been found accessible without authentication, with some exposing confidential business information, employee credentials, and sensitive personal records.
Researchers at Claroc examined applications created through Grok’s Build functionality, which allows users to generate and publish software through conversational instructions.
Of 43,551 application addresses tested, 37,571 remained online. Claroc found that 35,578 of those applications, approximately 94.7%, could be opened without signing in.
Most were ordinary games, calculators, or landing pages. A smaller subset contained confidential commercial material or personal information that appeared unsuitable for unrestricted access.
The results do not mean all 35,578 publicly accessible applications contained private data, or that criminals had obtained their contents. They establish that some sensitive information was reachable through applications available to anyone holding their addresses.
Confidential records appeared in accessible applications
Claroc identified 24 public applications built by personnel associated with SpaceXSI, formerly xAI, and X. These reportedly included an internal onboarding plan, a sales territory map containing 594 accounts, and confidential advertising proposals.
Researchers also identified internal information linked to 30 other organisations, including 26 employing more than 1,000 people and six Fortune 500 companies.
Examples included a hospital staff directory with more than 3,500 records, an intensive-care briefing containing patient information, and an employee timesheet whose client-side code exposed passwords in plaintext.
Claroc said it did not try to modify third-party applications or use exposed credentials. Its testing of write permissions was confined to applications the researchers created using fictional data.
Identifying the organisation associated with a public application does not establish that its wider infrastructure was compromised. The reported exposure concerns information that had been placed within accessible generated applications.
Publication settings can allow broad sharing
In the researchers’ paid test account, publishing an application presented access options including anyone with the link, invited users, and only the creator. The option permitting anyone with the link was preselected.
SpaceXSI disputed an implication that applications were automatically public, noting that users must complete publication steps and that applications built by its own employees start private.
Those statements are compatible with a separate concern about a broadly accessible option being selected during publication. A tool may require an intentional publishing action while still creating an exposure if the creator does not understand the resulting sharing permissions.
According to Claroc, SpaceXSI removed the 24 public applications associated with its personnel after notification. Other applications remained accessible when the research was published.
Authentication is not the same as authorisation
Claroc created two test applications to examine generated security controls. One was a shared contact list with no login, allowing the researchers to modify its fictional records from a browser session without authentication.
The second was described as a customer list intended for four members of a company’s sales team. Grok generated sign-in options through Google and X, but Claroc found that a Google account outside the intended team could access and edit records.
In that test, authentication identified the person signing in without enforcing membership of the intended authorised group.
The researchers did not test the same authorisation path in every public application. Their results demonstrate weaknesses in the apps they built and the need to distinguish sign-in functionality from access controls governing the underlying records.
Generated software requires separate security checks
AI-assisted development can make it easier for employees without extensive programming experience to create operational tools, but those tools may still hold business records, passwords, or connected application permissions.
Publishing through an application builder can occur outside established software deployment and review processes, making it harder for central IT teams to know which systems are exposed.
Organisations using AI-generated applications need visibility over publication settings and data access, particularly if applications are connected to production systems or used to hold confidential information.
Existing applications may require additional review if sensitive content was included before effective authentication and authorisation were introduced.
Claroc’s GhostShares 2 investigation describes its scan methodology, the examples confirmed manually, and the operator’s response.
The findings show how rapid application generation and publication can expose information when sharing choices and access restrictions are not examined independently of the generated software’s functionality.
