Skip to content
OriginalSecurity

Anyone with the link: how 35,578 Grok-built apps ended up open to the internet

Security researchers opened 35,578 apps built with Grok’s Build mode without signing in to anything. The cause was a publish default, a public DNS trail, and a button that treats a sales pipeline like a lunch poll.

Analog VHS illustration of a long corridor of glowing doorways standing open, a lone figure walking away down the hall
Every open door is a published app. The corridor is Grok Build’s public-by-default catalogue. Original GREP PRINT illustration. Illustration generated with AI.
On this page

In brief

  • Claroc tried 43,551 Grok app addresses; 35,578 of the 37,571 still online opened with no sign-in.
  • The publish panel preselected “Anyone with the link”, and each app’s hostname is indexed by passive DNS.
  • Exposed apps included a hospital roster, an ICU patient briefing, and SpaceXSI’s own sales pipeline.
  • On Grok-built test apps, visitors could also read, edit and delete data — the default, not a hack.

The scan

On November 8, 2026, researchers at the security firm Claroc started working through a long list of web addresses under grok.me — the domain where Grok, the AI assistant from SpaceXSI (the company formerly called xAI), publishes the apps people build with it. Nobody had sent them any of the links. They opened the first page of each one once, from the public internet, signed in to nothing, the way anyone would in an incognito window.

One address named a new hire and ended in "onboarding plan." It was the onboarding plan for a new member of SpaceXSI's own enterprise sales team, marked confidential: the systems to get access to in the first week, internal system addresses, the sales team's tools, 19 of the company's internal chat channels, the colleagues to meet, and a 30-day plan. Nothing asked them to sign in.

The full numbers, from Claroc's report "GhostShares 2," published November 10: of 43,551 Grok app addresses the researchers tried, 37,571 were still online, and 35,578 of those — 94.7 percent — opened for anyone with no sign-in. Only 1,993 answered with an HTTP 401, the error an app set to "Only you" or "Invited users" returns.

How a hostname becomes a public list

The exposure has two halves, and neither is a bug in the usual sense. The first is a default. In the account Claroc used, clicking Publish on an app Grok built proposed "Anyone with the link" as the access setting. The other options — "Invited users" and "Only you" — were there. They just weren't selected.

The second half is the addressing. Every published app gets its own hostname, <name>.grok.me. When someone opens one, their computer asks a DNS resolver where that name lives, and passive DNS services collect those lookups. Anyone with an account can search them by pattern. So the first time the people a link was meant for use it, the name lands in a commercial index — and one pattern search for *.grok.me returns the list. About half the names Claroc saw were four random words the builder never chose. Nobody would guess one, and nobody needs to, because the dataset lists them.

A Grok app published with Anyone with the link gets its own hostname, which passive DNS records after the first visit, letting anyone search for grok.me names and open the app with no sign-in
The five-step path from publish button to public app. The hostname, not the link, is what makes it findable. Credit: Muse / grep.tips. Source.

This is the part worth sitting with, because it breaks the mental model most people have of link sharing. A link feels private when you haven't sent it to anyone. But a hostname is not a secret: it is a public record of a lookup, and the lookup happens the moment the intended audience uses the link. Claroc calls pages like this GhostShares — they open for people who were never given the link, and those people can find them on their own. Last month, the same team found the same pattern in Meta's Muse. The lesson keeps repeating because the mechanism is the same every time: secrecy fails when the secret is a DNS record.

Most of the open apps were harmless — games, landing pages, calculators. Claroc estimates about one in ten held sensitive material, internal business data or personal data, and roughly two percent held material serious enough to rate high or critical. The cases the researchers confirmed by hand are the ones that will travel:

  • A hospital group's staff event app with a searchable roster of more than 3,500 employees.
  • An intensive care briefing for a single patient, with labs, imaging and ventilator status.
  • A cruise ship's galley inspection checklist listing crew members by full name and employee ID.
  • A fire department's live shift board, with each firefighter's name, badge number and the hours they are on duty.
  • A trucking firm's driver-recruiting list of more than a thousand people with their legal names and personal email addresses.
  • A contractor's staff timesheet whose code held every employee's account with the password in plain text, admins included — 18 accounts in all.

And then there were the 24 apps built by SpaceXSI and X staff themselves: the onboarding plan, a sales territory map of 594 strategic accounts and their pipeline, eight X advertising proposals and media plans — one of them to a U.S. federal agency, marked confidential — four live advertiser account boards, one tracking progress toward a $1.6 million sales goal, seven campaign reports for advertisers in Brazil, Japan, Korea and Thailand, and two copies of an X brand safety playbook labeled as an internal sales hub.

Beyond SpaceXSI and X, the open apps held internal data from 30 organizations the researchers could identify: 26 with more than 1,000 employees, six of them in the Fortune 500. Claroc names none of them.

Open is worse than it looks

From the outside, Claroc could only see that apps were open. Whether a visitor can also change the data takes changing it, and the researchers were not going to do that to anyone else's app. So they built two apps of their own, with made-up data.

The first was a contact list Grok was asked to save "so every visitor sees them." It got a database and no sign-in. From an incognito window, signed in to nothing, the researchers added a row that the next visitor saw.

The second was a customer list "for my company's sales team of 4 people." Grok added sign-in on its own, through "Continue with Google" and "Continue with X." But the code Grok wrote adds whoever signs in to the team before it checks whether they are on it — so the check always passes. A Google account that was not the owner's and had never been invited signed in, saw every customer, changed one record and deleted another.

Claroc is careful about the limit of this finding: it proved write access only on its own two apps, and did not sign in to, write to or test anyone else's. But the pattern is the point. An app that stores data with no login lets any visitor change it, and a team login that checks who you are but not whether you belong to the team is a lock that opens for every key. For an app like that, opening the page can also mean being able to add, change or delete the data behind it.

The other side

SpaceXSI's position, as reported to the press, is that Grok apps stay private until their creator chooses to share one, and that its employees' apps start out private. Its own staff still had 24 apps open to anyone, and SpaceXSI took those down after the report. It has not done the same for the apps other Grok users and organizations left open. As of Claroc's publication, there was no public confirmation that the default sharing setting for ordinary users had changed.

The contrast Claroc draws is with ChatGPT. When the researchers clicked Share on an app ChatGPT built, access was set to "Only me" until they changed it. Its addresses are also two levels deep and carry the account's username, so a name is much harder to guess — though no harder to find in DNS. That leaves the default to do the work: if a ChatGPT address does turn up in a DNS list, it leads to an app that only its owner can open.

The same structural problem reaches beyond Grok. ChatGPT, Lovable, Replit, Base44, Google AI Studio and Meta's Muse all give each published app its own hostname, and v0 and Bolt deploy to hostnames too. Every hostname gets its own DNS lookup, and that lookup is what makes the name findable. Shared chats work differently — the secret part of those links sits in the path, so DNS never sees it — but published apps are another matter.

If your people build apps with AI

The reason this keeps happening is not that the builders are careless. An AI-built app is made in a chat window and published from the same window, often in minutes, by someone whose job is running a sales territory or a shift roster. The builder doesn't file a request or install anything IT would see. A territory map and a lunch poll get the same publish button — and the app drifts, gaining a table, a sign-in or a share link with the next prompt, until an app that was harmless yesterday holds customer records today. One enterprise Claroc knows counted 500 AI-built apps, each one changing with the next prompt.

If you published a Grok Build app, check its access setting now and switch it to "Only you" or "Invited users." The setting exists; it just isn't the default, and nothing prompts the builder to use it. And if you run a team where people build with AI tools, the question is no longer whether they do — it's whether you know which builders they use, because Grok, Lovable, Replit, v0, Bolt, Base44 and Google AI Studio need no admin rollout and no company account.

"AI app builders turned publishing into a few clicks, and the default answer to who can see it is everyone," says Asaf Aprozper of Claroc Research. The 35,578 open apps are the receipt.