Uncloaked: 380,000 Exposed Apps and the Vibe-Coding Security Problem Nobody's Fixing
This edition has a theme instead of a grab-bag: every story below is about the same underlying pattern. An app gets built by describing it in plain English to an AI tool, it ships fast because that's the entire appeal, and nobody goes back to check whether the security defaults were ever appropriate for something real people would eventually use.
1. A Base44 authentication bypass let anyone into private enterprise apps
Researchers at Wiz found a critical flaw in Base44, the AI app-building platform Wix acquired for $80 million, that allowed attackers to create accounts inside private applications without any sophisticated hacking skill. Many of those apps were managing genuinely sensitive operations, HR systems, internal communications, private data repositories. Wix confirmed the flaw hadn't been exploited in the wild and patched it within 24 hours of disclosure, which is a fast turnaround. It's also a reminder that "fast turnaround after a researcher finds it" and "secure by default" are very different things.
Why it matters: Base44 is one of the platforms Decloak's platform security layer specifically checks for, alongside Lovable, Supabase, and Bubble, because this exact category of failure, authentication and authorization logic that looks fine in a demo and isn't, keeps showing up across the entire vibe-coding ecosystem, not just one vendor.
2. Researchers found 380,000 publicly accessible apps built with AI tools
Israeli security firm RedAccess told Axios it identified roughly 380,000 publicly accessible assets built with Lovable, Base44, Replit, and Netlify, including about 5,000 containing sensitive corporate data. The cause, in many cases, wasn't a bug at all: default privacy settings on some of these platforms make apps publicly accessible unless a user manually flips them to private. Many of the exposed apps were indexed by Google, meaning a normal search could surface them. Confirmed examples included a shipping company's internal vessel-tracking data and a health company's active UK clinical trial details.
Why it matters: this isn't an exploit story, it's a defaults story. Nobody broke in anywhere. The apps were built, technically worked, and were simply reachable by anyone who thought to look, the same failure mode as the Supabase RLS issue we've covered before, just one layer up the stack, at the platform's own default visibility setting rather than the database's access rules.
3. Cursor still doesn't protect your API keys from its own extensions
Security researchers at LayerX disclosed that Cursor, one of the most widely used AI coding tools, doesn't store a developer's API keys and session tokens in protected storage. Any extension installed in Cursor can read them, leading to full credential compromise. As of the disclosure, Cursor was aware of the issue and hadn't fixed it.
Why it matters: this sits right next to the hardcoded-secrets problem we wrote about a couple of weeks ago, except here the exposure isn't even in your own code, it's in the tool you're using to write it. If you're using Cursor, treating any extension you install as having access to your API credentials is the safe assumption until this changes.
4. A backdoor can hide inside the AI tool's own configuration rules
Pillar Security disclosed a technique called the Rules File Backdoor affecting both GitHub Copilot and Cursor. Attackers can manipulate the configuration/rule files these tools read to covertly influence what code gets generated, producing output that looks like normal, best-practice code but quietly leaks environment variables, database credentials, or API keys. It requires no special privileges, no admin access, just the ability to modify a config file inside a repository, and the malicious guidance blends into legitimate-looking generated code well enough to slip past both manual review and automated scanning.
Why it matters: this is a genuinely different failure mode from the others on this list. It's not a missing access control or a bad default, it's a supply-chain attack on the tool doing the coding, which means the vulnerability can exist before a single line of your actual application code is written.
5. The scale is accelerating, not levelling off
Georgia Tech's Vibe Security Radar confirmed 74 AI-linked CVEs through March 2026 alone, with roughly a 6x increase in new monthly CVEs between January and March. Separately, Claude Code alone was reported to account for more than 4% of all GitHub commits by early 2026, and a quarter of Y Combinator's Winter 2025 startup cohort had codebases that were 95% or more AI-generated.
Why it matters: the volume of AI-generated code in production is growing much faster than the tooling and habits needed to check it. None of the previous four stories are edge cases. They're what the growth curve looks like up close.
The thread connecting all five
None of these needed a sophisticated attacker either. An auth check that didn't verify what it claimed to. A default that was public unless someone remembered to change it. A credential store that any extension could read. A config file trusted a little too completely. The tools got dramatically better at producing working software in 2026. Checking whether that software is safe by default hasn't kept pace, and the gap is exactly where all five of these stories live.
Sources: Cloud Security Alliance's vibe coding vulnerability research note · Veracode on the Base44 vulnerability · Axios on RedAccess's 380,000 exposed apps finding · LayerX on the Cursor API key exposure · Coverage of the Rules File Backdoor affecting GitHub Copilot and Cursor
Decloak's platform security layer specifically checks for the failure modes common to Lovable, Supabase, Base44, and Bubble-built apps, publicly readable databases, exposed service_role keys, and known platform CVEs, alongside seven other attack surfaces. Scan your site free →