Innovation or Negligence? The Dark Side of the "Vibe Coding" Wave
Security researchers at RedAccess scanned hundreds of thousands of apps built on vibe coding platforms like Lovable, Replit, and Base44. What they found should worry anyone shipping software without a security review.
Innovation or Negligence? The Dark Side of the "Vibe Coding" Wave
I said this months ago. I warned people that it would happen.
Now, we finally have the hard numbers.
Security researchers at Red Access recently ran a massive scan on applications built using popular, instant "vibe coding" platforms like Lovable, Replit, and Base44. What they uncovered honestly sounds like a dystopian piece of fiction.
But it is completely real.
The terrifying reality by the numbers
The researchers discovered 380,000 applications completely exposed to the open internet.
Out of those, more than 5,000 platforms were actively leaking deeply sensitive, real-world data. This is high-stakes data left out in the open:
- Private medical data: A British healthcare app left a list of active clinical trials and patient details completely visible online.
- Global logistics: A shipping company's app exposed live, real-time port schedules for massive cargo ships.
- Corporate secrets: Uncensored customer service chat logs and internal business strategy documents were sitting on the public web.
There was no login screen, no required password, and no data permissions enforced, so anyone with the URL could see everything.
RedAccess reported that roughly 380,000 vibe-coded assets were publicly accessible across platforms including Lovable, Replit, Base44, and Netlify. Axios and WIRED independently verified examples from the findings in May 2026.
Why did this happen?
It happened because the barrier to building software has dropped to zero. Someone who has never written a single line of traditional code can now sit down and build a fully functional application in minutes.
They can build something that looks beautiful on the outside without having a single clue how identity verification or data restriction works. They don't know what database security rules, like Supabase Row Level Security (RLS), even are, and there is no engineering team reviewing their work before it goes live.
The study found two massive red flags:
- 91.5% of the analyzed applications contained active, plug-and-play security flaws.
- 96% of the most critical vulnerabilities were simply basic security settings that were never switched on.
It's the digital equivalent of building a state-of-the-art bank vault and forgetting to lock the front door.
"It Works" does not mean "It's Secure"
The tools are doing exactly what they were designed to do: they turn a prompt into a working application. The failure is one of human understanding, not technology.
Handing someone a tool that generates an entire application at the click of a button without teaching them the absolute basics of safety is like giving someone a GPS and expecting them to know how to plan an entire city's infrastructure.
We have accidentally created a culture that assumes if an application "works," it must be safe to launch.
There are no shortcuts in security. No matter how smart our building tools get, if the person behind the wheel doesn't understand the foundations of data protection, the result will always be a disaster waiting to happen.
Speed is not safety. An app that loads, looks polished, and "works" can still ship with public database access, missing login checks, and exposed API keys, all before anyone in security even knows it exists.
What do you think?
At Puaro, we believe in building fast, but we also believe that security cannot be an afterthought left to chance.
Is the "vibe coding" wave a brilliant leap forward for tech innovation, or is it just opening the floodgates to corporate negligence?
Share this post on LinkedIn and let us know your thoughts in the comments.
What security teams can still do
You cannot ban every no-code tool. You can require that anything talking to production data has auth, and that secrets do not live in the client bundle. Scan the repos and the hosted app configs the same way you scan "real" services. Red Access's numbers are a vendor study; Axios and Wired checked specific apps. That is enough to put vibe-coded internals on the asset list.
Puaro will not crawl Lovable for you. It will catch keys that landed in git on the way to that app. Start at getting started. Comparison context is on Why Puaro. Plan limits are on pricing.
Put those apps on the same inventory as the services you already scan. Same auth rule, same secret rule, same owner. If the generated app talks to a database, it is in scope. "We did not write the code" is not a control. Ask who can rotate the keys if the generated app is deleted tomorrow. If nobody can answer, it is already a secret store you do not own.