Coverage has been circulating this week citing a new report, attributed to a firm called RedAccess, claiming roughly 380,000 publicly accessible vibe-coded apps across Lovable, Base44, Netlify, and Replit, with around 5,000 of them actively leaking sensitive corporate or personal data. I want to react to this carefully, because I think how you handle a report like this matters as much as the number itself.
Why I'm being deliberately careful with this one
I've seen this specific figure through secondhand coverage rather than a report page I could examine directly myself, and the exact numbers haven't been something I've been able to independently verify to my own satisfaction. That doesn't mean the finding is wrong. It means the responsible move is treating the topline figures as directionally plausible rather than repeating them as precisely confirmed facts, especially the kind of specific numbers that are easy to state confidently and hard to actually check without seeing the underlying methodology.
Why the direction of the claim is entirely believable regardless
Whatever the exact figures turn out to be, the underlying claim, that a large number of AI-built apps are sitting publicly exposed, with a smaller but real subset actively leaking sensitive data, fits every pattern I've documented on this blog since January. Moltbook, the Lovable disclosure, the exam-app vulnerabilities, none of those needed a firm from outside to notice them first, they were found by researchers actively looking, which is exactly the methodology a report like this would use at a larger scale. A big number here wouldn't be surprising. It would be consistent.
What I'd actually do with a report like this
- Take the direction seriously: a meaningful share of AI-built apps are very likely sitting exposed in some way right now, whether the precise count is 380,000 or a different number.
- Hold off treating the specific figures as settled fact in your own writing or decision-making until the methodology behind them has been independently reviewed or the original source verified directly.
- Use the moment as a prompt to actually run the checks on your own app, rather than treating a large abstract number as something that only applies to other people's projects.
- Notice which platforms get named specifically, and if you're building on one of them, that's a reasonable nudge to double-check your own configuration rather than assuming the report is only describing other people's mistakes.
The broader habit worth building from this
A big, alarming number spreads fast, and it's tempting to either dismiss it entirely as clickbait or repeat it uncritically because it confirms what already feels true. Neither is the right instinct. The useful middle ground is taking the direction seriously enough to actually act on your own app, while being honest about which specific numbers you can and can't personally vouch for. That's the same discipline I try to apply to every report I cite on this blog, and it's worth applying here too.