On January 28, 2026, a social network called Moltbook launched. Its pitch: a social platform for AI agents — where AIs post, comment, and vote. Three days later, security researchers at Wiz discovered the platform’s database was wide open. Anyone who looked at the page source could grab a complete database key. 1.5 million API authentication tokens, 35,000 email addresses, every private message between AI agents — all exposed on the open web.
Moltbook’s founder Matt Schlicht had posted on X that same day: “I didn’t write a single line of code for @moltbook. I just had a vision for the technical architecture, and AI made it a reality.” He wrote zero lines of code. AI built the entire platform.
That post became the most expensive boast on the internet three days later.
The root cause, in retrospect, was a single Supabase Row Level Security (RLS) toggle left off. This toggle determines whether your database is “only you can access it” or “everyone in the world can access it.” The AI-generated code was functionally correct — it connected to the database properly, performed CRUD operations correctly. The toggle was just off by default. The AI didn’t turn it on, and the human didn’t know it needed to be turned on.
Three months after Moltbook, security firm RedAccess delivered a more systematic report. Using Google and Bing, they searched the official domains of four AI coding platforms — Lovable, Replit, Base44, and Netlify — and found roughly 380,000 publicly accessible apps built on these platforms, which they manually opened and inspected one by one. The result: roughly 5,000 apps had “virtually no security or authentication of any kind,” and about 2,000 of those directly exposed sensitive data.
The exposed content included: hospital work schedules with doctors’ personally identifiable information, corporate go-to-market strategy presentations, complete customer service chat logs from a retailer (including full customer names and contact details), internal financial records from a Brazilian bank, a shipping company’s vessel schedules and port assignments, and clinical trial data from a UK healthcare company.
Roughly 40% of the problematic apps were at the level of “an Axios reporter types in a URL and sees confidential documents.”
If anyone at your company is using AI coding tools to build internal
apps — CRM, scheduling, reporting, approval workflows — and IT doesn’t
know about it, your data is probably already sitting on a public
.lovable.app or .replit.app domain.
The strange thing about this problem: it has little to do with whether AI writes good code. The AI-generated code is functionally correct. Moltbook’s database connection worked fine. The Lovable apps leaking doctor schedules ran without issues. The failure isn’t in the code layer — it’s in the deployment layer.
The common thread across all four platforms: they don’t just generate code for you, they also deploy it to the public web with one click. Lovable, Base44, and Replit all assign a public URL under their own domains to every app. Netlify goes further — it’s essentially a public CDN by design, with no authentication unless you explicitly add it. As IANS Research security advisor Adrian Sanabria put it: “These platforms not only allow the vibe coder to create an application, but host the applications as well. The full stack exists in one place: from idea to production app connected to a proper domain name.”
This fundamentally changes the nature of the security problem. In traditional software development, there was a natural security decision window between “code is done” and “it’s live”: who deploys, to which environment, how database permissions are configured, whether authentication is needed. This window existed not by design but because deployment itself required time and technical skill. Vibe coding platforms compress this window to zero. You describe what you want, AI writes the code, and the app is already online.
What gets compressed isn’t just time — it’s also who’s making the decisions. The people who used to deploy applications at least knew what they were doing. Now the people deploying apps might be product managers, operations staff, or salespeople — they don’t know what RLS is, and they don’t know that “public” means something entirely different on the internet than it does on GitHub. As IANS Faculty member Josh More put it: “The entire idea behind vibe coding is that you have people who either don’t know what they’re doing or are lazy and don’t care about what they’re doing. Of course there are going to be issues with leaking sensitive data.”
The four platforms’ responses follow a strikingly consistent pattern. It’s worth examining separately because it explains why this crisis won’t resolve itself.
Replit CEO Amjad Masad’s response on X: “Users can choose whether apps are public or private. Public apps being accessible on the internet is expected behavior.” This is technically correct. Replit does provide a toggle to switch from public to private, one click away. But the problem is precisely this: a marketing colleague using the tool for the first time won’t realize they need to click that toggle, or even that such a toggle exists.
Lovable’s spokesperson told Axios: “Lovable gives builders the tools to build securely, but how an app is configured is ultimately the creator’s responsibility.” The same day, Lovable told WIRED that RedAccess hadn’t shared specific URLs and that they “couldn’t verify.” Base44’s parent company Wix said RedAccess “deliberately withheld the URLs,” and that two examples WIRED shared “appeared to be test sites or AI-generated data.” Netlify didn’t respond to any media inquiries.
The four companies’ responses share a pattern: frame the problem as user misconfiguration rather than platform design failure. This holds up legally, but it’s an engineering dodge. When a platform generates tens of thousands of apps daily, a significant share of its users lack security judgment, and the default setting is “public on deploy” — that’s not user error. That’s a systematic design failure.
A few numbers can give the problem scale.
Georgia Tech’s Systems Software and Security Lab has been tracking CVEs caused by AI-generated code since May 2025. They pull public vulnerabilities from CVE.org, NVD, and GitHub advisories, trace back to the fixing commit, and determine whether an AI coding tool introduced the bug. They found 6 in January 2026, 15 in February, and 35 in March — nearly a sixfold increase in three months. The research team estimates the real number is 5 to 10 times higher (roughly 400 to 700), because these are only the ones already discovered, fixed, and attributed to AI.
Another number comes from Escape.tech: after scanning roughly 5,600 publicly deployed vibe-coded apps, they found over 2,000 high-impact vulnerabilities, more than 400 exposed secrets and tokens, and roughly 175 instances of personally identifiable information exposure, including medical records and bank account numbers.
This crisis isn’t traditional Shadow IT repeating itself. Shadow IT — employees using software or cloud services without IT’s knowledge, like sharing work files through personal Dropbox or signing up for SaaS tools without approval — has one defining feature: the company doesn’t know what tools its people are using. Vibe coding pushes the problem one layer deeper: the employees themselves don’t know they’re running a database in production. A two-order-of-magnitude amplification, from “the company doesn’t know” to “the person who built it doesn’t know.”
A few things can be done today, without waiting for platforms to change their defaults.
First, search. RedAccess found 380,000 apps just by combining Google searches with platform domain names — any security team can do the same. IANS’s recommendation is to “assume all vibe-coded apps are public by default and check their security settings.” Under current platform defaults, this is the only correct starting point.
Second, establish visibility into AI tool usage. The AI tools developers are actually using often differ significantly from the list security teams have approved. Security company Backslash Security raised a $19 million Series A in February 2026 specifically for this. Within minutes of deployment at one customer, they discovered developers using an AI model explicitly forbidden by company policy.
Third, fix security at the deployment layer, not the code layer. Platforms like Northflank offer sandboxed deployment for vibe-coded apps: secrets injected at runtime rather than written into source code, database minimum permissions rather than admin access, environment isolation rather than shared infrastructure, independent preview environments per PR rather than everything piled onto one URL. The direction is right: patch defaults at the layer where failures are most common.
Finally, if you’re building with AI tools, or you know someone who
is, here’s the simplest check: is your app running on a public domain
like .lovable.app or .replit.app? If so, check
whether Google has indexed it. It probably has. Then find that privacy
settings toggle. If you can’t find it, don’t go live.
Vibe coding lets people who can’t write code build working software. That in itself isn’t the problem. The problem is that one-click deploy defaults to “visible to the entire world,” and the person clicking that button has no idea what they just did.