From random hostnames to a searchable app index
Claroc enumerated 43,601 app addresses under grok.me and tested the 37,571 that remained online. Of those, 35,578 opened without authentication, a rate of 94.7 percent, according to figures reported by mlq.ai. The figures indicate an estate-wide condition rather than a small cluster of unusually exposed projects: nearly every live address Claroc checked yielded an app. SpaceXSI’s Grok Build had intended share links to function through obscurity, with randomized URLs restricting access to people who knew the complete address.
The weakness sat in the hostname. Grok Build placed each app’s randomized name there, causing those names to appear in passive DNS databases that anyone can search. A researcher could collect hostnames from that infrastructure record rather than guess complete URLs, then request the corresponding apps directly. arstechnica.com describes the design decision as defeating the platform’s attempt to keep data limited to people possessing exact links. Randomness still made individual names difficult to predict; passive DNS supplied a directory that removed the need to predict them.
This distinction matters because the exposure did not require compromising accounts, bypassing a login screen, or breaking encryption. The apps were already reachable; discovery was the missing capability, and searchable DNS records supplied it. That suggests a share-link model cannot treat hostname randomness as a meaningful access boundary when the hostname enters searchable infrastructure. Claroc’s 43,601-address list demonstrates enumeration at platform scale, while the 94.7 percent open rate shows how consistently those discovered addresses resolved into projects that an unauthenticated visitor could read.
What 35,578 open apps actually exposed
Most accessible apps were games, calculators, and ordinary websites, so the raw count overstates the volume of sensitive material. Claroc nevertheless estimated that 650 to 800 apps contained private data. That range implies a minority of the open estate, but a substantial absolute set of exposures, and it remains an estimate rather than a verified total. Reporting by thedeepdive.ca describes medical exams, sales plans, and staff data among the exposed material, establishing categories of sensitive information without supplying a complete inventory of affected individuals or organizations.
One example was a Tesla service-center scorecard listing 22 technicians, their output, and bonus standing. That artifact combines a staff roster with internal performance measures, making its exposure different in kind from a public calculator or game. The evidence does not say how many technicians’ records were accessed beyond Claroc’s examination, nor how long the scorecard remained available. Its presence inside an app built with a general-purpose coding tool shows how operational business data can enter an app-building and sharing workflow also used for ordinary websites.
Claroc also identified 24 open apps built by SpaceXSI and X staff. Their contents included a confidential onboarding plan, a sales territory map covering 594 accounts, and an X advertising proposal addressed to a U.S. federal agency. These were not merely demonstrations of what the coding agent could generate; they concerned internal operations and external business relationships. The record does not establish that every one of the 24 apps contained confidential information, so the specific examples should not be expanded into a blanket characterization of the full staff set.
Who chose public sharing, and what SpaceXSI removed
Responsibility for the sharing choice is disputed. Claroc says Grok Build’s publish panel preselected “Anyone with the link,” placing public reachability on the default path for creators who accepted the presented setting. SpaceXSI says apps remain private until their creator chooses to share. Those statements can both describe parts of the interface while leaving the decisive question unresolved: what users saw, which setting was selected, and how clearly the choice communicated discoverability. The evidence supplies no publication-flow screenshots or user-level decision records to settle that dispute.
The distinction between secrecy and discoverability is central to that disagreement. Even if a creator affirmatively selected link sharing, the stated promise of randomized URLs could lead that creator to expect a limited audience. Passive DNS indexing made the links enumerable by strangers, which is a separate condition from deliberately publishing an app in a directory. That suggests consent to share with known recipients cannot automatically be read as consent to platform-wide discovery. The available accounts do not document what individual creators understood or intended when they published.
SpaceXSI removed its staff apps after Claroc’s report and media questions, but left other users’ open apps in place. That response removed the operator’s identified staff material from public reach while leaving the broader exposure dependent on existing publishing controls and creator action. The evidence does not provide a removal timestamp, a company-wide remediation measure, or any indication that other creators were notified. It also does not state that the underlying hostname and passive DNS design changed, or that SpaceXSI altered the publish panel whose preselected setting Claroc described.
Sources
- arstechnica.com — Grok Build’s sharing design exposed 35,000 apps and private data
- mlq.ai — Grok Build left 35,000 apps open to anyone, including SpaceX's own confidential sales… (2026-11-11)
- mezha.net — Grok Build exposed confidential data, including SpaceXSI material (2026-11-10)
- thedeepdive.ca — Security Firm Says Grok Build Apps Exposed Medical Exams, Sales Plans and Staff Data (2026-11-11)
- New Horizon daily digest, 2026-11-11 (topic provenance)