Grok AI App Leak: 35,000 Apps Open Without a Login

Grok AI App Exposure: 35,578 Apps Were Open to Anyone, and Some Held Passwords

Item	Detail
Topic	Public exposure of apps built with Grok's app builder
Reported by	Claroc, November 10, 2026
Live apps tested	37,571
Opened without sign-in	35,578 (94.7%)
Who should read this	Small business owners, CISOs, IT admins
Core fix	Restrict access, remove secrets from code, unpublish orphan apps

What is the Grok AI App exposure? On November 10, 2026, security firm Claroc reported that 35,578 of the 37,571 Grok-built apps it tested opened for anyone, and about 1 in 10 held sensitive business or personal data. The full Claroc research report describes the method. The Grok AI App feature lets people describe an app in chat and publish it, and its sharing default sits at the center of the dispute.

A sales manager types a few sentences into a chat box. Minutes later a working territory map is live. No ticket, no review, no call to IT.
Then a stranger opens the same link, because nothing told the app to say no. The Grok AI App leak shows how quickly a convenience feature can become a data exposure.

Quick summary

• Claroc says 35,578 of 37,571 live Grok-built apps opened without a login. Its own estimate is that about 650 to 800 held serious private data.

• The causes are sharing defaults, weak access control in generated code, and app addresses that leak through DNS records. Claroc did not report a confirmed attack.

• Check every Grok AI App your team published today. Set access to "Only you" or "Invited users", remove passwords from code, and unpublish apps nobody owns.

Why the Grok AI App Leak Matters Now

Grok can build a working app from a description typed into chat. Its maker opened that feature to every Grok plan on August 19, and each published app gets its own subdomain of grok.me. That last detail turns out to matter a great deal.

The feature shares a name with a separate terminal coding tool, also called Grok Build. That tool had its own problem, with repository uploads reported on July 14. This article covers only the chat app builder.
Here is what the researchers counted, in their own dataset.

Measure	Figure	Note
Names listed under grok.me	43,601	From one passive DNS service
Distinct apps loaded	43,551	Some names were records, not apps
Live apps that answered	37,571
Opened without sign-in	35,578 (94.7%)
Returned HTTP 401 (restricted)	1,993 (5.3%)	Expected for "Only you" or "Invited users"
Held sensitive material	About 1 in 10	AI-assisted grading, which over-counts
Serious material, estimate	About 650 to 800 apps	After the researchers checked a sample by hand
Confirmed by hand	150
Other organizations identified	30	26 with over 1,000 employees, 6 in the Fortune 500
Apps from SpaceXSI and X staff	24	Taken down after the report

Most of the open apps were harmless. They were games, landing pages and calculators. The trouble sits in the small share that were not.

This is not an isolated pattern. The same researchers showed in October that pages shared from Meta's Muse could be found through passive DNS, and in August 2025 more than 370,000 shared Grok conversations turned up in Google search. The Hacker News adds that Meta disabled sharing and then announced a fix on October 22.

Broader data points the same way. The Verizon 2026 Data Breach Investigations Report, released May 19, 2026, found that vulnerability exploitation (31%) overtook credential abuse (13%) as the top initial access vector.

Credentials still matter. SOCRadar's summary of the report says almost eight months passed before half of weak password and permission misconfiguration findings in third-party cloud environments were resolved. It also says source code is the most common data type employees upload to unauthorized AI platforms.
One caution. The DBIR covers November 2024 to October 2025, so it cannot measure this event. It shows the climate, not this specific leak.

The OWASP page on Broken Access Control ranks this weakness first in its 2021 Top 10. It says access control should deny by default, except for public resources, and should be enforced in trusted server-side code. Hold on to that, because the Grok findings map onto it closely.

How the Grok AI App Exposure Works

A link that looks private but is not

Every published app lives at its own hostname, written as the app name followed by grok.me. When someone opens it, their device asks a DNS resolver where that name lives. Passive DNS services collect those lookups and let subscribers search them by pattern.

So the first time the intended audience opens a link, the name can land in a commercial index. Grok suggests four random words as each app's name, and about half of the names researchers found followed that pattern. Such names are hard to guess, but that does not protect an app whose name already sits in a searchable list.

I keep coming back to this point. Random names feel like a lock. Here they were closer to a house number in a public phone book. Nobody has to guess when the list is handed over.
By the researchers' account, ChatGPT's app builder also uses per-app hostnames.

Its sharing setting started at "Only me" in their test, so a leaked address led to an app only its owner could open. That comparison comes from the researchers, and I have not tested it myself.

What was inside the open apps

The confirmed examples read like a list of things nobody meant to publish:

• A hospital group's staff event app with a searchable roster of more than 3,500 employees.
• An intensive care briefing for one patient, with labs, imaging and ventilator status.
• A fire department's live shift board with names, badge numbers and duty hours.
• A trucking firm's recruiting list of over a thousand people, with legal names and personal emails.
• Twenty-four apps built by SpaceXSI and X staff, including a sales territory map of 594 accounts and an advertising proposal marked confidential.

The case that stays with me is the contractor's timesheet. Its script file, which every visitor's browser downloads, held 18 staff accounts with passwords in plain text, admins included. Nobody had to break anything. The page handed over the keys to anyone who looked at its source.

Claroc also admits a limit. Most Grok apps load their records from a server after the first page appears, and the researchers only loaded first pages. They could not see those records. In the first set they read, 95% of open apps had no sign-in code at all, so the data behind them is probably open too. That is an inference, not a measurement.

The default setting dispute

This is where the two sides differ, so I will give both.
In the paid account the researchers used, after clicking Publish the next step offered three settings: "Anyone with the link", "Invited users" and "Only you". "Anyone with the link" was already selected. Their argument is that extra clicks do not protect data when the path ends with everyone selected.

SpaceXSI's answer, as reported, is that apps stay private until their creator shares them. It says publishing takes several steps, including a choice between "Only you" and "Anyone with the link" and a legal disclaimer, and that employee accounts default to "Only you". Even so, 24 apps from its own staff and X staff were open. SpaceXSI took them down after the report, and the researchers say it has not done the same for other users' apps.

Both statements can be true at once. Nothing goes public without a deliberate click. And the screen at that click may still lean toward public.

Broken access control, written by a chat prompt

The researchers built two test apps with made-up data and published both with the preselected setting. They touched only their own apps.

The first, a contact list, got a database but no sign-in. A visitor with no account could add a row from a private window, and the next visitor saw it.

The second, a customer list for a four-person team, did get "Continue with Google" and "Continue with X" buttons. But the generated code added each person who signed in to the team before checking whether they belonged. An uninvited Google account got in, viewed every customer, edited one record and deleted another.

This is textbook broken access control. The app proved who the visitor was but never asked whether the visitor was allowed. Authentication is not authorization, and a Grok AI App built from a vague prompt can skip the second half without telling anyone.

A safe self-check you can run on your own apps

The block below is illustrative. Replace the placeholder with the address of an app you own, run it only on your own apps, and never against someone else's.

# 1. From a device with no company login, check the front door

curl -s -o /dev/null -w "%{http_code}\n" https://<your-app-name>.grok.me/

# Expected for a restricted app: 401

# Anything in the 200 range means a stranger can load it

 

# 2. Save the scripts your app serves, then search them for secrets

grep -inE "password|passwd|secret|api[_-]?key|token" downloaded-app-script.js

# Any hit with a real value means: unpublish, rotate, rebuild

Illustrative inventory record, with made-up values:

app_owner:      sales-ops@example.com

data_class:     customer contact details

access_setting: Invited users

last_reviewed:  2026-11-11

secrets_in_code: none found

status:         keep

How to Secure Every Grok AI App Your Team Built

• Find out who is building. Ask teams which AI app builders they use. The Hacker News notes that builders such as Grok, Lovable, Replit, v0, Bolt, Base44 and Google AI Studio need no IT rollout or company account.

• List every published app. Any Grok AI App with internal data should be set to "Invited users" or "Only you", and a stranger should get an error page.

• Test from outside. Try the link in a private window with no login. Then try a personal Google account that was never invited. If either gets in, the app needs a real allowlist.

• Search the scripts for secrets. Look for names, emails and passwords in the files the app loads. Rotate anything you find, because it may already have been copied.

• Unpublish apps nobody owns. In the researchers' tests, unpublishing took an app offline within seconds.

• Move sensitive data out. Patient, customer, payroll and legal data should not live in a chat-built app at all. Use your approved systems.

• Write a short policy. Name the approved builders, require an owner for each app, and set a review date.

Approach	Effort	Risk reduction	Limits
Set access to "Only you" or "Invited users"	Low	High	Does not fix passwords already in code
Unpublish orphan apps	Low	High	Needs a complete app list first
Remove secrets, rotate credentials	Medium	High	Exposed values may already be copied
Server-side allowlist after sign-in	Medium to high	Very high	Needs developer skill or a security review
Monitor DNS for your builders' domains	Medium	Medium	Needs passive DNS access
Approved-builder policy and training	Low to medium	Medium	Depends on people following it

For small business owners, steps 2, 4 and 5 take an afternoon and cover most of the risk. For CISOs, the harder question is governance. The joint CISA secure by design and secure by default guidance urges manufacturers to ship products that are safe without extra configuration. Customers can turn that into buying criteria: ask any AI builder vendor what the default audience is before a team publishes anything.

Hoplon Insight Box

• Treat AI-built apps as part of your attack surface, even when IT never approved them.
• Make "Only you" or an invited list the minimum for any app that touches staff, customer or health data.
• Rotate any password found in app code. Assume it was copied.
• Keep a one-page register of AI-built apps with an owner and review date.
• Ask vendors about default sharing settings in writing before rollout.

A research firm's view. Claroc's Asaf Aprozper argues that AI builders made publishing a one-click action, while the default answer to who can see the result is everyone. That is a researcher's opinion from a company that sells related tools. Weigh it with that in mind, but the access-control logic holds on its own.

Wrap Up

The Grok AI App exposure is less about one company and more about a habit. We now build tools faster than we review them. A link that works for the people it was meant for may also work for everyone else, and a random-looking address will not change that.

No one has confirmed that attackers copied this data. Claroc says it cannot tell how long any app was open or whether anyone else found it. Plan as if someone did.

If you are unsure what your teams have published, a professional review is cheaper than a notification letter. Cybersecurity specialists such as Hoplon InfoSec can inventory AI-built apps, test access controls and help write a policy your staff will follow.

FAQ

Is a Grok AI App safe for business data?

Not by default, based on the researchers' findings. Treat it as safe only after you set access to "Only you" or "Invited users", confirm a stranger gets an error, and keep passwords out of the code.

How can I tell if my Grok app is public?

Open its link in a private browser window with no login. If the page loads, it is public, and you should change the access setting or unpublish it.

Does the Grok app leak mean hackers stole data?

Not confirmed. Researchers showed apps were open and reported no confirmed theft, and they say they cannot tell whether anyone else found them.

Author Bio and Review

Author: Gazi Mahmud, Co-Founder and CIO of Hoplon InfoSec LLC, cybersecurity leader, and CISM & CISA certified professional with expertise in cyber risk management, security governance, compliance, and incident response.

Technical reviewer: Mohammed Talukder is the Co-Founder and CEO of Hoplon InfoSec, with over 16 years of experience in cybersecurity and technology. His expertise includes offensive security, vulnerability management, cyber risk management, and incident response. His professional credentials include CISM, CISA, CEH, and CompTIA PenTest+. He has also received Infosys recognition awards for his professional contributions. He shares practical cybersecurity insights to help organizations strengthen their security posture.

 Read More Articles:

Mobile Security 2025: Top 7 Antivirus Apps You Can Trust
X Suspended Twitter Account: Causes, Appeals & Recovery
Microsoft Teams Phishing Attack:Remote Access Scam Explained
SAP Security 2026: Risks, Best Practices & Checklist