Incidents
Eight publicly-reported events.
Date: 2026-01-08
Severity: critical
Type: data breach
Moltbook — 1.5M API tokens + 35K emails leaked, 3 days after launch
- App
- Moltbook (vibe-coded social network)
- Builder
- Lovable
- Stack
- React + Supabase
- Cause
- Row-Level Security never enabled; anon key in client bundle was the only thing standing between attacker and database
- Scale
- 1.5M auth tokens, 35K email addresses, exfiltrated to public paste site
- Detection time
- ~72 hours from launch
Moltbook launched on January 5th 2026 with a Twitter announcement. ~3,000 signups in the first 24 hours. By the 6th, a security researcher had fingerprinted the stack from view-source and found the anon key in main.js. By the 7th, the obvious tables (users, auth_tokens) were confirmed readable without authentication. By the 8th, the exfiltrated data was on a public paste site with a write-up.
This is the textbook vibe-coded breach pattern. Lovable wired the React frontend to Supabase using the anon key — that part is correct. What didn't happen: nobody enabled Row-Level Security on any table. With RLS off, the anon key reads everything.
Lesson
The anon key is meant to be public. RLS is what protects your data. If you ship a Supabase app without RLS, you're shipping public read access to every table. For the full forensic timeline and the four lines of SQL that would have prevented the entire incident, read
Anatomy of the Moltbook breach. For the per-rule audit, see
/fix/supabase_anon_only_no_rls. For the broader workflow,
the pillar guide.
Date: 2026-03
Severity: high (population-level)
Type: systemic exposure
Lovable security crisis — 48 days of exposed projects, structural issue
- Reporter
- The Next Web (March 2026)
- Pattern
- Lovable project URLs were systematically discoverable; many shipped with permissive Supabase configurations and dev-mode artifacts
- Resolution
- Lovable rolled out additional safeguards including default RLS scaffolding hints and a built-in security check
The TNW write-up "Lovable vibe-coding security crisis exposed" traced a 48-day window during which Lovable-hosted projects could be enumerated and inspected at scale. Many had reproducible misconfigurations — anon key with no RLS, exposed Supabase admin URLs, dev-mode preview routes left in production.
Lovable's response was to add platform-level tooling: a built-in scan, default RLS hints in the generation prompts, and a checklist for the operator before publishing. vibecheck operates from outside Lovable and works on any AI builder; the goals overlap.
Lesson
Platform-level scans help, but they only cover apps on that platform. The same ops mistake — anon key + no RLS — happens on Bolt, v0, Replit, and any custom Supabase build.
Our Lovable checklist is platform-specific; the
scanner works platform-agnostic.
Date: 2026-01
Severity: population-level
Type: aggregate scan
SupaExplorer — 11% of indie launches expose Supabase credentials in frontend
- Researcher
- SupaExplorer project
- Sample
- ~20,000 indie launch URLs
- Findings
- 11% of apps expose Supabase credentials in frontend code; subset contained full
service_role keys (RLS bypass)
- Subset scan
- 1,645 Lovable showcase apps → 10.3% had critical RLS failures (CVE-2025-48757, CVSS 8.26)
Not a single breach — a population-level scan that quantified the prevalence of the pattern. SupaExplorer harvested 20K indie launch URLs from Product Hunt, Indie Hackers, etc., grep'd for Supabase JWTs, decoded them. 11% had keys in the bundle. A meaningful fraction of those had "role": "service_role" in the payload — keys that bypass RLS entirely.
Lesson
These aren't outliers. ~1 in 10 indie launches today ships with credentials publicly visible. The same scan would surface dozens of breach-shapes if anyone bothered.
/fix/supabase_service_role_in_client for what to do if you find one in your bundle.
Date: 2026-02
Severity: population-level
Type: aggregate scan
SymbioticSec — 98% of vibe-coded apps have at least one security flaw
- Researcher
- SymbioticSec
- Sample
- 1,072 vibe-coded applications
- Findings
- 98% had ≥1 vulnerability; spread across exposed credentials, missing RLS, public storage buckets, and missing security headers
Different sample, similar shape. SymbioticSec ran an automated scan against 1,072 apps identified as built with AI builders. Only 22 came back clean (a handful actually had security configured; the rest were trivially small or behind auth gates that prevented full scanning).
The 98% figure has been press-friendly but is somewhat misleading — many findings are low-severity (server version disclosure, missing security headers). The critical findings (exposed secrets, public databases) are present in roughly the 10–20% range, consistent with SupaExplorer.
Lesson
The aggregate "X% have a security flaw" stat conceals severity distribution. The actionable number is critical findings, which run 10–20%. That's the rate vibecheck operates against — scan an app and there's a 1-in-5 chance you're finding something that genuinely matters.
Date: 2026-03
Severity: population-level
Type: aggregate scan
Wiz Research — 20% of organizations using vibe-coding platforms have public DB misconfigs
- Researcher
- Wiz Research
- Scope
- Organizations Wiz had visibility into via existing customer relationships, filtered to those using vibe-coding platforms
- Findings
- 20% had public-facing database misconfigurations attributable to AI-generated wiring
- Source
- Wiz blog post on vibe-coded app risks
Wiz looked at the population of organizations they monitor and asked: of those using vibe-coding platforms (Lovable was the focal example), how many have a database that's publicly reachable in a way the operator presumably didn't intend? 20%.
This is a different sampling shape from SupaExplorer — Wiz's sample is enterprise-leaning, not indie. The fact that 1-in-5 enterprise users of vibe-coding platforms have the same misconfig as 1-in-10 indie launches suggests the issue isn't sophistication; it's that the platforms generate the same wiring regardless of who's prompting.
Lesson
Enterprises hit this rate too. Tooling matters more than experience. The fix is process: scan-on-deploy, regardless of who prompted the build.
Wire the scanner into your CI so every push gets checked.
Date: 2024-06-25
Severity: critical
Type: CDN supply-chain attack
polyfill.io — ~100,000 sites served malicious JavaScript after domain handoff
- Vector
- Cross-origin
<script src="cdn.polyfill.io/..."> tags without Subresource Integrity
- Cause
- The polyfill.io domain was acquired by a Chinese company (Funnull) in February 2024; by June, the served JavaScript was injecting redirect/malware payloads
- Scale
- ~100,000 sites identified by Sansec scanning, including major commerce, news, and public-sector deploys
- Mitigation
- Cloudflare and Fastly hot-patched their CDNs to serve a clean fork; Google blocked Search ads on affected sites; sites with SRI hashes were unaffected because the hash mismatch caused browsers to refuse execution
polyfill.io was a free CDN that served JavaScript shims to make older browsers behave like newer ones. Hundreds of thousands of sites included it via a single <script src="https://cdn.polyfill.io/v3/polyfill.min.js"> tag. When the domain changed hands in early 2024, the new operator started serving altered versions of those scripts: redirecting mobile users to scam sites, injecting cryptominers, harvesting form data.
The incident is the canonical modern argument for Subresource Integrity. Sites that had pinned a specific SRI hash (integrity="sha384-...") loaded the old, clean version and refused to execute the new one — the browser checks the hash before running the script. Sites without SRI ran whatever the CDN returned. The fix is one HTML attribute. The cost of skipping it was full XSS-equivalent code execution on every page load for ~100K sites.
Lesson
Every cross-origin
<script> or
<link rel="stylesheet"> in your HTML is an implicit trust delegation to whoever runs that CDN. The CDN can change hands, get compromised, get court-ordered, or just push a buggy build. SRI lets the browser refuse to execute when bytes change unexpectedly.
/fix/missing_sri_external_script for the full how-to.
Date: 2024-05 / 2024-06
Severity: critical
Type: credential reuse → mass data exfiltration
Snowflake customer data theft — 165+ tenants, ~570M records, no MFA gate
- Affected
- Ticketmaster, AT&T, Santander, Advance Auto Parts, Pure Storage, LendingTree, Neiman Marcus, plus 150+ other Snowflake customers
- Vector
- Stolen Snowflake user credentials (harvested from infostealer malware on developer workstations) used directly against tenants that had not enforced MFA
- Cause
- Snowflake permitted username+password auth without MFA by default; many enterprise customers never turned MFA on
- Scale
- ~570 million customer records exfiltrated; tens of millions of credit-card-related fields; AT&T paid an estimated $370K ransom for partial return
- Resolution
- Snowflake forced MFA-by-default for all customers in 2024; published guidance for credential rotation; threat actor (UNC5537) charged late 2024
Not a vibe-coded breach, but the most important credential-handling lesson of 2024 and a useful reminder that the failure mode for "we have a backend" doesn't make data safer if the auth surface is permissive. Every incident traced back to a credential that had been stolen by infostealer malware months earlier. None of it would have worked if MFA had been required.
The vibe-coded equivalent: anon Supabase keys with no RLS, public storage buckets, OAuth clients with permissive redirect-URI allowlists. The shape repeats — auth that never had to be passed because the data layer was open.
Lesson
Defense-in-depth matters. The "outer gate" failure (credential leak) is foreseeable; the inner gate (MFA, RLS, allowlist) needs to actually be turned on. vibecheck flags the kinds of inner-gate failures that show up in browser-visible code; this incident is the same shape one layer up.
Date: 2024-03-29
Severity: high (caught pre-distribution)
Type: 2-year social-engineering supply-chain attack
xz-utils backdoor — multi-year maintainer-takeover, caught hours before stable release
- Reporter
- Andres Freund (Microsoft engineer) — noticed unusual SSH login latency, traced to xz-utils 5.6.0 / 5.6.1
- Vector
- 2-year campaign in which "Jia Tan" became co-maintainer of xz-utils, then introduced obfuscated code that hooked into liblzma → systemd → sshd, enabling remote auth bypass for an attacker holding a specific key
- Scale
- Backdoor reached Debian unstable, Fedora Rawhide, openSUSE Tumbleweed, but was caught BEFORE landing in any stable Linux distribution. Counterfactual reach: most internet-facing Linux servers
Pure dependency supply-chain compromise. The attacker spent two years building real maintainer trust, then committed obfuscated build scripts that injected the payload only into release tarballs (not the public git tree, which is why nobody auditing the source caught it). The trigger condition was so specific — only attacker-supplied SSH keys would activate the backdoor — that even runtime fuzzing wouldn't have surfaced it.
Not a vibecheck-shaped finding (we operate on browser-visible code). Listed here because it's the canonical 2024 example of "you can't audit your way out of supply-chain trust" — and the second-order impact informs how the SRI and OAuth detectors are calibrated.
Lesson
Pin dependencies. Audit who is on the maintainer list of anything you ship transitively. For browser code: Subresource Integrity catches the same shape of attack (changed bytes from a previously-trusted source) at a much lower cost than what xz-utils would have required.
/fix/missing_sri_external_script.