35,578 Grok-Built Apps Were Open to Anyone: 'Anyone With the Link' Default Exposed Patient Data, Passwords and SpaceXSI Staff Apps
Researchers found 94.7% of 37,571 live apps on grok.me loaded without sign-in because publishing preselected 'Anyone with the link', exposing medical, staff and corporate data.
Security researchers have found that 35,578 web apps built with Grok's chat-based app builder could be opened by anyone, with no sign-in required. That is 94.7% of the 37,571 live apps they tested. The exposed apps included hospital staff rosters, an ICU briefing containing a patient's lab results, plaintext administrator passwords, and two dozen internal apps belonging to employees of SpaceXSI, the company formerly known as xAI, which runs Grok.
What Happened
Grok's app builder lets users describe an app in a chat and publish it instantly. It opened to all plans in August 2026. Each published app gets its own subdomain under grok.me.
Security researchers began investigating on 8 November and published their findings on 10 November under the name "GhostShares 2". They used ordinary subdomain-discovery techniques, including passive DNS data that records lookups of hostnames, and identified 43,601 grok.me names. Of the 37,571 apps still online, only 1,993 returned an "access denied" (HTTP 401) response. Every other app loaded for an anonymous visitor.
The researchers say the root cause is a default setting. When publishing, the access panel preselected "Anyone with the link", rather than "Invited users" or "Only you". Because the app addresses leak into passive DNS, "anyone with the link" in practice meant anyone who looked.
What Was Exposed
According to the researchers, about one in ten open apps held internal business or personal data. Around 2%, an estimated 650–800 apps, were rated high or critical sensitivity. Examples they described, without naming the organisations, include:
- A hospital staff roster of more than 3,500 people
- An ICU briefing with a patient's lab results and ventilator status
- A fire department shift board with names and badge numbers
- A trucking company's recruiting list of more than 1,000 people
- A contractor timesheet app containing 18 plaintext passwords, some for administrator accounts
Thirty of the affected organisations were identified, six of them in the Fortune 500.
Twenty-four exposed apps were built by SpaceXSI and X staff. They reportedly contained an enterprise sales onboarding plan, a territory map covering 594 accounts, eight X advertising proposals (one marked confidential and addressed to a US federal agency), advertiser account boards and a brand-safety playbook.
The researchers also found a logic flaw in AI-generated sign-in code. In one test app, the generated code added every signed-in user to the team before checking membership. As a result, any Google account could read, edit and delete records. The researchers say they only loaded each app's first page once, did not submit forms or use credentials they saw, and ran write and delete tests only on two apps they built themselves.
Vendor Response
SpaceXSI said Grok apps stay private until they are shared, and that employee accounts default to "Only you". It agreed that "Only you" should be the default for all users, but argued that changing the default alone would not have protected the staff apps. The company removed the 24 staff apps within about two days.
According to the researchers, SpaceXSI did not take down other users' exposed apps, and its public statement did not say whether it would notify the owners. The researchers say they contacted three affected organisations directly and withheld all hostnames and app titles from their publication.
Who Is Affected
Anyone who published an app with Grok's builder without explicitly changing the sharing setting should assume it was publicly reachable. Organisations whose staff may have used the builder for internal tools are exposed as well. That includes rosters, trackers, dashboards and small CRUD apps fed with real data.
What To Do Now
- Find your apps. Search passive DNS for
grok.mesubdomains linked to your organisation, and ask teams directly. Only test apps you can tie to your organisation, and only with an unauthenticated page load. - Lock them down. Switch exposed apps to "Invited users" or "Only you", or unpublish them. Then confirm from a private browser window that an outside visitor gets an error.
- Rotate secrets. Check app code and data for credentials, API keys or passwords, and rotate anything found.
- Test the generated login logic. Sign in with an outside Google account that is not on the invite list and confirm it cannot read data.
- Govern AI app builders. Inventory the builders employees use (Grok, Lovable, Replit, v0, Bolt, Base44, Google AI Studio and others). Decide which data classes are allowed in them, and bring citizen-built apps into asset management.
- Report ownerless apps that expose third-party data to the vendor for takedown.
Why It Matters
This is not a new class of bug. It is the same "public by default" pattern that has exposed cloud storage buckets, shared documents and earlier AI app builders. What has changed is the speed and scale. Non-developers can now publish a working, data-backed web app in minutes, often with real patient, staff or customer data pasted in. They may not realise that a "random" URL is discoverable, or that the AI-generated access control may not actually check anything.
The researchers propose a set of fixes for the platform:
- Unguessable paths under a single host
- An organisation-only sharing option
- "Only you" as the default
- A clear publish-time warning when an app has a database but no sign-in
Until AI builders adopt safer defaults like these, security teams should treat them as shadow IT that needs the same discovery and review as any other SaaS.
