Grok Build left 35,578 of 37,571 live apps open to anyone with the link, according to a scan by security firm Claroc. The finding shows that SpaceXSI’s vibe-coding agent could expose internal business records, advertising material, medical information and plaintext passwords through app addresses that were discoverable without sign-in. Claroc said the public exposure rate was 94.7 percent, a scale that turns a publishing default into a broad data governance issue for companies building internal tools with the service.
Grok Build: A default with broad consequences
Claroc listed 43,601 app addresses under grok.me while checking the service. Only 1,993 live apps returned an access-denied error, meaning that 35,578 could be opened from the public internet without authentication. The Decoder reported that most of those apps were games, landing pages or calculators. That does not make the exposure harmless, because a small group of apps can contain information that is far more valuable than a simple utility.
In Claroc’s paid account, the publish panel preselected Anyone with the link. The other available choices were Invited users and Only you. SpaceXSI said apps are private until their creator shares them, that publishing takes several clicks including a legal disclaimer, and that employee accounts default to Only you. Claroc’s position is that additional steps do not resolve the issue when the final setting still favors public access.
The setting also applies to generated applications, not only static pages. Claroc built two test apps of its own. In one team app, the generated code added anyone who signed in before checking team membership. The researchers said an uninvited account could then read, edit and delete records. That behavior turns a weak publishing choice into a potential authorization flaw inside the application itself.
How the links became discoverable
Each published Grok Build app receives a hostname built from four random words plus grok.me. The random phrase carried up to 38 bits of entropy, which appeared strong enough to make direct guessing difficult. Claroc found that Grok Build placed that random part to the left of the domain, while Google Gemini places its random identifier to the right. Every visit to a Grok Build app triggers a DNS lookup, and passive DNS services record those lookups in searchable databases.
The result was that the links could be found without guessing the phrases. The Decoder compared the approach with locating a mailbox in a public postal directory rather than guessing a password. Heise reported that random identifiers for shared ChatGPT conversations, Claude Artifacts and Gemini content sit in a path that DNS does not transmit. Claroc also said Lovable, Replit and Bolt assign each app its own hostname, so the discovery problem is not unique to Grok Build. The publishing default and application safeguards remain distinct issues.
SpaceXSI material was exposed
Twenty-four of the accessible apps were built by SpaceXSI and X employees. Among the exposed SpaceXSI material was a confidential onboarding plan for a new enterprise sales team member, including internal system addresses and 19 chat channels. Claroc also found a publicly accessible sales territory map with 594 strategic accounts and pipeline data, eight X advertising proposals, four live advertiser account boards and two copies of an X brand safety playbook.
One of the eight X advertising proposals targeted a U.S. federal agency and was marked as confidential. Engadget reported that campaign reports and dashboards with advertising spending were also exposed. Only one of the exposed apps asked for a password. These cases matter because they involved internal planning and commercial information from the company operating the tool, not only material uploaded by outside users.
Claroc co-founder and chief technology officer Asaf Aprozper said: We were shocked. The company that makes Grok had its own internal material open to anyone holding the link, and we had never been given it. SpaceXSI began removing the 24 employee apps within hours of Ars Technica emailing questions, and by publication those links returned an app not found error. The company had not removed the open apps belonging to other Grok users and organizations.
Patient records and account credentials
Claroc estimated that about one in ten of the open apps held sensitive business or personal data, with roughly 650 to 800 apps containing private data. The firm classified roughly two percent of the open apps as serious enough to rate high or critical. Confirmed cases included a hospital group roster of more than 3,500 employees, an intensive care briefing containing one patient’s laboratory results and ventilator status, and a fire department shift board with badge numbers.
A timesheet app exposed another problem. Its source code held 18 user accounts with plain text passwords. Dataconomy also reported exposed employee names and identification numbers, along with galley checklists from a celebrity cruise line. The Decoder reported that shared Claude chats and artifacts, plus Meta’s Muse conversations, had surfaced through similar discovery methods. These examples show why access control cannot be treated as a matter for app teams alone.
Besides SpaceXSI and X, Claroc identified 30 affected organizations. Of those, 26 had more than 1,000 employees and six were Fortune 500 companies. The AI Pin reported that only 1,993 apps, or 5.3 percent, answered with an access error. The concentration of exposed data among large employers creates a compliance burden, especially where medical rosters, credential lists and sales pipelines sit behind apps that were expected to be private.
Disclosure, removal and remaining risk
Claroc reported the problem to SpaceXSI through the address in its security.txt file on November 8, then sent details on the other 22 staff apps on November 9. Ars Technica found all 24 still exposed on Monday evening, according to Chip Dispatch. SpaceXSI’s cleanup of its own material did not extend to the broader set of apps belonging to outside users and organizations. Claroc had begun notifying affected organizations directly and had emailed three by publication.
Claroc asked SpaceXSI to serve apps under a path on one host, add an organization-only sharing option, make Only you the default and warn when an app has a database but no sign-in. SpaceXSI had not committed to contacting the owners of the other open apps. A representative for Cursor, the coding company SpaceXSI recently acquired, said apps are private by default and nothing goes public unless the creator chooses to share it. That account did not fully resolve the conflict with the publish panel observed by Claroc.
Privacy defaults become a competitive issue
Privacy trouble predates this report. In July, a researcher found that the Grok Build command-line tool uploaded developers’ entire repositories, including Git history and committed secrets, to company cloud storage. The Decoder also reported that more than 370,000 shared Grok conversations appeared in Google Search in August 2025, while Ireland’s data protection authority is investigating whether X neglected data protection by design over sexualized deepfakes.
The current exposure is still different in scale and form. Those incidents involved search indexing and repository upload. This episode centers on public app publishing, discoverable hostnames and weak defaults inside generated code. For teams adopting Grok Build, the practical lesson is to confirm access settings before publication, review generated membership checks, rotate any credentials that may have entered source code and avoid placing regulated or commercially sensitive information in casually shared apps until the platform’s controls improve.
Until SpaceXSI changes the publish default and adds owner-level warnings, Claroc’s direct notifications, rather than a broad cleanup, define the remaining exposure. Grok Build has demonstrated that user-generated applications can carry the risk profile of production systems, even when the applications themselves are games, landing pages or calculators. That makes privacy defaults a purchasing and competitive variable rather than a secondary security footnote.

