Somewhere on a public subdomain sits a hospital staff rota, complete with the personal details of the doctors on it. Nobody hacked it. Nobody needed to. It was built with an AI app generator, published with a click and indexed by a search engine, which is how security researchers found it alongside thousands of similar apps documented in a May 2026 Wired investigation.
The findings, produced by Israeli security firm RedAccess, are striking less for their sophistication than for their banality. Researchers led by co-founder Dor Zvi examined apps built with Lovable, Replit, Base44 and Netlify and found more than 5,000 with virtually no authentication; around 40% exposed sensitive material, including medical information, financial data, strategy decks and chatbot logs containing customer contact details. "The end result is that organisations are actually leaking private data through vibe-coding applications," Zvi told Wired.
From prompt to production, skipping everything in between
Vibe coding, the practice of describing software in plain language and letting a large language model write and deploy it, has moved from developer curiosity to a mainstream business tool in little more than a year. Its appeal is obvious. A marketing manager can turn a spreadsheet into a dashboard before lunch; an operations lead can replace an email chain with a working tracker. For organisations short of engineering capacity, that is genuine value.
The trouble is what gets compressed along with the build time. Traditional software passes through code review, security testing, IT approval and an asset register before it touches production data. A vibe-coded app can bypass every one of those gates, because the person building it may never think of it as "software" at all.
That distinction matters because RedAccess did not set out to study vibe coding. According to Axios, which independently verified several exposed apps, the team stumbled on the problem while researching shadow AI, meaning employees' unsanctioned use of AI tools, for its customers. Axios reported a far larger denominator: roughly 380,000 publicly accessible assets built on the four platforms, of which about 5,000 contained sensitive corporate data. In its own subsequent Shadow Builders report, RedAccess said more than 2,000 of those held sensitive corporate, operational or personal information, often with administrator access granted to anyone who reached the URL.
How the exposure actually happens
The mechanics are mundane, which is precisely the point. The platforms host apps on their own domains, so the researchers simply combined those domains with ordinary search terms in Google and Bing. Some tools, Security Boulevard reported citing Axios, publish apps as public unless the user manually switches them to private. No exploit, no zero-day; just a default and a search query.
Beneath the visibility settings sits a second, more technical layer of risk. Many vibe-coding tools wire generated front ends directly to hosted databases such as Supabase, which relies on row-level security policies to decide who may read which records. When the AI omits or misconfigures those policies, the public key embedded in the page's JavaScript can unlock entire tables. An April 2026 scan by Symbiotic Security of 1,072 vibe-coded apps using Supabase found only 26 with no detectable issues. In February, The Register reported on a Lovable-hosted education app whose AI-written access logic effectively inverted its own rules, blocking logged-in users while admitting anonymous ones and exposing 18,697 user records.
These are not exotic failures. They reflect a broader pattern in machine-written code: Veracode's 2025 GenAI Code Security Report found that across more than 100 language models, generated code introduced OWASP Top 10 vulnerabilities in 45% of test cases, and that models picked the insecure option nearly half the time when a secure one was available.
Whose fault is a public app?
The platforms pushed back hard. Replit chief executive Amjad Masad argued that users choose whether apps are public or private, adding, as Axios reported, that "public apps being accessible on the internet is expected behaviour." He also said RedAccess gave Replit only 24 hours before going to the press. A spokesperson for Wix, which owns Base44, said the researchers withheld the URLs needed to investigate and that some apps had been deliberately made public by their owners.
Those objections have merit. Public visibility is a legitimate feature, disclosure norms matter, and RedAccess sells shadow-AI security tooling, which gives it an interest in the problem looking large. Readers should also note that the headline figures come from the researchers' own classification of what counts as "sensitive", and the vendors disputed elements of the methodology rather than the existence of the exposed apps.
Yet "expected behaviour" is a weak defence when the expected user is not a developer. Security engineering has long recognised that defaults are policy: most people never change them. The cloud industry learned this the hard way with publicly readable storage buckets, an analogy VentureBeat drew explicitly. Amazon eventually made its S3 buckets private by default. Whether vibe-coding vendors follow without a comparable wave of embarrassment remains an open question.
What security leaders should do now
For CISOs, the uncomfortable lesson is that conventional controls were built around the wrong unit of risk. Endpoint agents, firewalls and code scanners assume software arrives through engineering pipelines. A sales analyst on a personal laptop, pasting CRM exports into a prompt and publishing the result, generates almost no signal in a SIEM.
The practical response starts with discovery. If researchers could find these apps with search engines, so can attackers, and so can a security team looking for its own company's name on platform subdomains. From there, organisations can extend data-loss prevention rules to vibe-coding domains, require single sign-on for any app that touches internal data, and offer sanctioned platforms with enterprise controls rather than blanket bans that simply push builders further out of sight.
Governance also needs to catch up with who now writes software. Lightweight registration for citizen-built apps, clear data-classification rules about what may be fed into them, and a named owner for each one would address most of what RedAccess found.
None of this argues against vibe coding. The productivity gains are real, and the technology will only become more capable. But the Wired findings expose a gap that better models alone will not close: AI has collapsed the cost of building software without collapsing the cost of securing it. Organisations that treat every generated app as production software, with an owner, an inventory entry and authentication by default, will capture the speed. Those that do not are, in effect, publishing their data and waiting for someone to search for it.
