THE ACQUISITION AUDIT: WHAT WE FIND BUYING RANDOM AI-BUILT SAAS

We bought 18 AI-built SaaS apps from Acquire.com, Flippa, and MicroAcquire over four months, and ran the same scan against each within an hour of close. Every single one had at least one critical or high finding. Here is the buyer-side reality of vibe-coded acquisition diligence.

Eighteen acquisitions over four months. Three marketplaces. Every single app had at least one critical or high finding within an hour of close. This is the first published buyer-side dataset on AI-built SaaS acquisition security we are aware of.

If you are buying a vibe-coded app, the table below is your checklist. If you are listing one, it is the diligence question your buyer is going to run.

Headline numbers

Metric Value
Apps purchased and scanned 18
Apps with at least one critical 14 (78%)
Apps with at least one high or critical 18 (100%)
Median findings per app at close 11
Median time-to-first-critical 23 seconds
Total spent on listings ~$340,000 (range $1.2k – $84k)
Window Jan 2026 – Apr 2026

What was wrong on day zero

Findings present at the moment of close, classified by category.

Finding class Apps affected Severity
Missing or broken Supabase RLS 12 Critical
Hardcoded secret in frontend bundle 9 Critical
Stripe sk_live_ in bundle (separate count) 4 Critical
Seller-still-has-credentials post-handover 7 Critical
BOLA in CRUD endpoints 11 High
CORS allow-all on credentialed endpoints 8 High
Outdated dependencies with known CVEs 14 High-Medium
Verbose error responses 13 Medium
No HSTS 17 Low
Test user accounts left in production 6 Medium

The standout — and the one most likely to be missed — is “seller still has credentials” (7 of 18). Marketplaces require the seller to transfer admin access to the buyer, but they do not require — and do not verify — that the seller has rotated their own credentials, removed their personal email from the DB user list, or revoked OAuth grants on connected services. In 7 of 18 cases, the seller could still log in as admin a week after handover.

By marketplace

Marketplace Apps purchased Critical-at-close rate Modal critical
Acquire.com 9 67% Missing RLS
Flippa 6 100% Hardcoded secrets
MicroAcquire (private deals) 3 67% Seller credentials retained

The differences are partly platform-mix — Acquire.com listings skew larger, with more polished apps; Flippa listings skew smaller and earlier-stage. The seller-credentials-retained issue is more common on private deals because the handover is less mediated.

What sellers disclosed vs what we found

Of the 18 listings:

  • 3 mentioned security in any form
  • 0 included a recent third-party security audit
  • 2 claimed compliance certifications (one GDPR, one SOC2-ready) — neither stood up to a five-minute check
  • 0 disclosed any of the findings the scan eventually surfaced

This is not a claim that sellers are dishonest. It is a claim that sellers do not know. None of these apps had been previously scanned with anything close to this depth, and most builders cannot meaningfully describe the security posture of an app the AI built for them. The disclosure gap is structural.

The pre-close diligence we recommend

Based on findings present at close — what would have caught the criticals before wire transfer.

Step Time Cost Critical findings caught
1. Run Token Leak Checker on demo URL 1m $0 4 of 9
2. Run Supabase RLS Checker 1m $0 12 of 12
3. Run Firebase Scanner 1m $0 2 of 2
4. Test BOLA manually with two test accounts 10m $0 9 of 11
5. Run full VibeEval scan 1m setup $19 All of the above + long tail
6. Verify seller has rotated credentials post-close 15m $0 7 of 7

The cumulative cost of pre-close diligence that would have caught every critical in this study: under 30 minutes of buyer time and $19. The cost of the criticals themselves, if exploited post-close, is unbounded.

CWE / OWASP mapping for buyer triage

For triage at handover, the categories below are the ones to gate the holdback clause on. Every finding the buyer-side scan surfaces should carry its CWE and OWASP tag so the LOI language can refer back without ambiguity.

Finding category at close CWE OWASP Holdback severity
Missing or broken Supabase RLS CWE-862 / CWE-863 A01 · API1 Critical-blocker
Hardcoded secret in frontend bundle CWE-798 A02 · A05 Critical-blocker
Stripe sk_live_ in bundle (separate count) CWE-798 A02 Critical-blocker (financial impact)
Seller-still-has-credentials post-handover CWE-732 / CWE-284 A01 · A05 Critical-blocker
BOLA in CRUD endpoints CWE-639 A01 · API1 Critical-blocker
CORS allow-all on credentialed endpoints CWE-942 A05 · API8 High-blocker
Outdated dependencies with known CVEs CWE-1104 A06 Medium (patch + monitor)
Verbose error responses leaking stack traces CWE-209 A09 · A05 Medium
No HSTS CWE-319 A02 · A05 Low (deploy fix)
Test user accounts left in production CWE-798 / CWE-284 A05 Medium-blocker (rotate + audit)

The “seller-still-has-credentials” row is the under-disclosed one. CWE-732 (Incorrect Permission Assignment for Critical Resource) is rarely flagged by automated scanners because it is not a code-level finding — it is a handover finding. The diligence step is procedural: confirm the seller has rotated their own creds, removed their email from admin roles, and revoked OAuth grants. Verify by attempting the login.

What buyers should add to their letter of intent

Based on what we encountered, the pre-close conditions that would have prevented every “seller still has credentials” finding:

  • Seller rotates Stripe, Supabase, Firebase, and any AI provider keys at close
  • Seller removes their personal email from all admin/owner roles at close
  • Seller revokes OAuth grants on Google Workspace, GitHub, Slack at close
  • Buyer runs an automated security scan within 24 hours of handover; criticals trigger the holdback clause

We are happy to share template LOI language with buyers; ask for it via the contact form.

Methodology

Sample. Eighteen AI-built SaaS apps purchased between Jan 2026 and Apr 2026 across Acquire.com, Flippa, and MicroAcquire. Selection was opportunistic — we filtered for listings identifying as built on Lovable, Bolt, Cursor, Replit, or V0 and within a $1k-$100k price range. We do not claim the sample is representative of all marketplace listings.

Scan timing. Each app was scanned within 60 minutes of admin-access transfer. The “at close” snapshot is the first scan; subsequent post-fix scans are not in this dataset.

Disclosure. Sellers were informed before close that anonymized findings would be published. No seller is named, no listing URL is published, no domain is revealed. Aggregate counts only.

Cost basis. “Total spent” is the actual purchase price across all 18 listings, range $1,200 to $84,000. We are happy to discuss methodology under NDA with any party considering a similar study.

Limits. Eighteen apps is small. We deliberately stayed small because the per-app cost is not negligible and the disclosure burden is real. The aggregate findings are directionally meaningful but the precise counts have wide confidence intervals.

Calibration via gapbench. The buyer-side diligence flow described in this study can be practiced and reproduced against gapbench.vibe-eval.com scenarios that mirror each finding shape — without needing real acquisition spend. The clean control (ref0) is what a properly-audited target should look like under the same scanner.

Reproduce on the public benchmark

The acquired apps are not public for seller-privacy reasons. The diligence flow itself is reproducible against gapbench scenarios that mirror the finding shapes:

Diligence step gapbench scenario for practice Pattern walkthrough
1. Token leak check indie-saas, config-leak Source maps and .git in production
2. RLS check supabase-clone The Supabase service-role key in your frontend bundle
3. BOLA cross-account multi-tenant-saas, fintech-app BOLA in AI-generated CRUD
4. Mass assignment / self-editable role mass-assignment Mass assignment
5. Seller-credentials-rotated auth-system Magic links, OTP, password resets
Clean reference ref0 False positives and the ref0 control

A buyer who has run the diligence flow against the gapbench scenarios first will recognize each finding shape on a real listing in seconds. The cost of the practice run is zero; the cost of skipping it is unbounded.

Citations

VibeEval. The Acquisition Audit: What We Find Buying Random Apps from Acquire.com and Flippa. May 2026. https://vibe-eval.com/data-studies/acquisition-audit-acquire-flippa/

RUN IT YOURSELF

Each scenario below is live on the public benchmark. The commands are copy-paste ready. Outputs may evolve as we tune the scenarios; the bug stays.

Pre-close diligence step 1 — secret leak check (5 min, $0)
curl -s https://gapbench.vibe-eval.com/site/indie-saas/ | grep -oE 'sk_(live|test)_[A-Za-z0-9]{20,}|eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+'
expected Stripe key + JWT in bundle — 4 of 9 acquired apps would have failed at this step
Pre-close diligence step 2 — RLS check on demo URL
curl -s 'https://gapbench.vibe-eval.com/site/supabase-clone/rest/v1/users?select=*' -H 'apikey: ANON_KEY'
expected 200 with rows — 12 of 12 RLS-affected acquired apps would have failed at this step
Pre-close diligence step 3 — BOLA cross-account probe
curl -s https://gapbench.vibe-eval.com/site/multi-tenant-saas/api/projects/1 -H 'Authorization: Bearer USER_B_TOKEN'
expected 200 with another user's data — 9 of 11 BOLA-affected acquired apps would have failed at this step
Post-close verification — seller-credentials-rotated check
curl -s -X POST https://gapbench.vibe-eval.com/site/auth-system/api/login -d '{"email":"former-owner@example.com","password":"OLD_PASSWORD"}'
expected 200 with admin session — happens in 7 of 18 cases without a holdback clause
Clean reference — ref0 returns nothing
curl -s -I https://gapbench.vibe-eval.com/site/ref0/
expected All probes clean — what a clean acquisition target should look like

COMMON QUESTIONS

01
Did the sellers know you were running this study?
Each seller was informed before close that we would publish anonymized findings. Two sellers declined; we did not buy from them. The remaining sales proceeded with consent for anonymized aggregate publication. No seller is named, no listing URL is published, no app domain is revealed.
Q&A
02
Why scan within an hour of close?
To capture the security state at the exact moment of buyer takeover — before the new owner has had time to change anything, before the seller has had time to clean up, before the marketplace has time to mediate. The timestamp matters because every other security claim about an acquired SaaS is stale by the time the buyer reads it.
Q&A
03
Were the listings honest about security?
Mostly silent. Of 18 listings, only three included any mention of security or compliance. None included a recent third-party audit. Two claimed 'GDPR compliant' without evidence. Listings that mention security at all are a small minority — buyers should assume nothing has been verified.
Q&A
04
What is the cheapest pre-close diligence?
Run the [free token leak checker](/token-leak-checker/), the [free Supabase RLS checker](/supabase-rls-checker/), and the [free Firebase scanner](/firebase-scanner/) against the listing's demo URL. These three together would have caught a critical finding in 16 of 18 apps in this study. Total time: under five minutes. Total cost: free.
Q&A
05
Should marketplaces be doing this?
We think so, and we have proposed automated pre-listing scans to Acquire.com and Flippa. Their position is that listings represent active businesses and intrusive scanning is not appropriate without seller consent. A consent-based pre-listing scan badge — 'security-checked at listing' — would be a meaningful trust signal that does not currently exist in any marketplace we work with.
Q&A
06
Did any of the apps have value?
Yes. The point of this study is not that AI-built SaaS is worthless — most of these apps had real customers, real revenue, and real product-market fit. The point is that the security state at handover is uniformly poor and uniformly under-disclosed. You can buy a good business with a bad security posture; you just need to know before you wire funds.
Q&A
07
Where can I run the same diligence checks against deliberately vulnerable targets?
https://gapbench.vibe-eval.com/ runs 97 deliberately vulnerable scenarios that mirror the failure shapes in this study. Practice the diligence flow against indie-saas (secrets), supabase-clone (RLS), multi-tenant-saas (BOLA), and auth-system (auth-flow gaps). ref0 is the clean control — what a properly-audited target should look like.
Q&A
08
What CWE / OWASP categories should an acquisition LOI gate against?
Critical-blocker categories at close: CWE-798 / A02 (hard-coded credentials), CWE-862 / A01 / API1 (missing authorization, including RLS off), CWE-639 / API1 (BOLA), CWE-915 / API6 (mass assignment / self-editable role), CWE-732 (incorrect permission assignment, e.g. service-role exposure). High-blocker: CWE-942 (CORS allow-all), CWE-352 (CSRF on state-changing endpoints), CWE-770 (no rate limit on auth). Buyer LOI should make any critical-blocker a holdback trigger.
Q&A
09
Are marketplaces actually moving on this?
Slowly. We have proposed automated pre-listing scans to Acquire.com and Flippa. Their position is that intrusive scanning requires seller consent. A consent-based 'security-checked at listing' badge would be a meaningful signal that does not currently exist on any marketplace we work with. Until that lands, the buyer-side diligence in the table below is the only line of defense.
Q&A

RUN PRE-ACQUISITION SECURITY DILIGENCE

Same scan we used in this study. Run it before you wire funds — 60 seconds, no setup.

RUN PRE-ACQUISITION SCAN