DATA STUDY / ACQUISITION DILIGENCE

THE ACQUISITION AUDIT: BUYER-SIDE SECURITY DILIGENCE FOR AI-BUILT SAAS

When you buy an AI-built SaaS off Acquire.com, Flippa, or MicroAcquire, the security posture at handover is consistently poor and consistently under-disclosed. This catalog documents the failure shapes we encounter at close, the cheap pre-close diligence steps that catch them, and the LOI language that protects the buyer.

When we run a security scan within an hour of buyer takeover on AI-built SaaS purchased from Acquire.com, Flippa, or MicroAcquire, the recurring outcome is “at least one critical or high finding present at close.” This catalog ranks the failure shapes we encounter at handover and gives the buyer-side diligence flow that catches each one before the wire transfer.

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

Catalog scope

Field Value
Window Jan 2026 – Apr 2026
Source Anonymized buyer-side engagements at handover + gapbench reproducible scenarios
Marketplaces covered Acquire.com, Flippa, MicroAcquire (private deals)
Scan timing Within 60 minutes of admin-access transfer
Reproducibility anchor indie-saas, supabase-clone, multi-tenant-saas, auth-system, ref0 (clean control)

We do not publish a corpus count of listings audited or the total spent because the engagement portion is anonymized by design. The diligence flow itself, reproducible against gapbench, is the part any buyer can verify before their next acquisition.

What is wrong on day zero

Findings recurrently present at the moment of close, classified by category and ranked by relative frequency.

Finding class Relative frequency Severity
Missing or broken Supabase RLS Most common Critical
BOLA in CRUD endpoints Highly common High
Outdated dependencies with known CVEs Highly common High–Medium
Verbose error responses leaking stack traces Common Medium
Hardcoded secret in frontend bundle Common Critical
CORS allow-all on credentialed endpoints Common High
No HSTS Common Low
Seller-still-has-credentials post-handover Common (and under-disclosed) Critical
Test user accounts left in production Less common but recurring Medium
Stripe sk_live_ in bundle (subset of secret-in-bundle) Less common, highest financial impact Critical

The standout — and the one most likely to be missed — is “seller still has credentials.” 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. We routinely find the seller can still log in as admin a week after handover.

By marketplace

Marketplace Relative critical-at-close incidence Modal critical
Flippa Highest (smaller, earlier-stage listings) Hardcoded secrets
MicroAcquire (private deals) High (less mediated handover) Seller credentials retained
Acquire.com Moderate (larger, more polished listings) Missing RLS

The differences are partly platform-mix — Acquire.com listings skew larger and more polished; 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 disclose vs what we find

Across the engagements:

  • The modal listing includes no security disclosure of any kind.
  • The minority that mentions security typically does not include a recent third-party audit.
  • Compliance claims (GDPR, SOC2-ready) without supporting evidence are the exception, not the rule, and we have not seen one stand up to a five-minute check.
  • Sellers do not, as a rule, disclose findings the scan eventually surfaces.

This is not a claim that sellers are dishonest. It is a claim that sellers do not know. Few of these apps have 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

The steps that catch each finding class above before wire transfer. Each step has a clear gapbench reproducibility anchor so the buyer can practice the flow against a known-vulnerable target first.

Step Time Cost Failure shape caught
1. Run Token Leak Checker on demo URL 1m $0 Secrets in bundle
2. Run Supabase RLS Checker 1m $0 RLS off, permissive policy, service-role exposure
3. Run Firebase Scanner 1m $0 Open Firebase rules
4. Test BOLA manually with two test accounts 10m $0 BOLA on read/PATCH/PUT
5. Run full VibeEval scan 1m setup $19 All of the above + CORS, dependencies, long tail
6. Verify seller has rotated credentials post-close 15m $0 Seller-still-has-credentials

The cumulative pre-close diligence that catches the modal critical-blocker categories: 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

Source. Failure shapes are drawn from anonymized buyer-side engagements between Jan 2026 and Apr 2026 across Acquire.com, Flippa, and MicroAcquire, focused on listings identifying as built on Lovable, Bolt, Cursor, Replit, or V0 in the typical hobby-to-mid-size price range. We do not publish a corpus N or aggregate purchase total because the engagement portion is anonymized by design and not a uniform random sample of all marketplace listings.

Scan timing. Each engagement 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 catalog.

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.

Limits. Per-engagement cost is not negligible and the disclosure burden is real, so the underlying engagement set is intentionally small. The failure-shape ranking is directionally meaningful; the absolute frequencies would have wide confidence intervals if we tried to publish them.

Calibration via gapbench. The buyer-side diligence flow described here 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.

Sources and references

Citations

VibeEval. The Acquisition Audit: Buyer-Side Security Diligence for AI-Built SaaS. May 2026. https://vibe-eval.com/data-studies/acquisition-audit-acquire-flippa/

/ REPRODUCE

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 — the most common Stripe-leak shape at handover
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 — the modal RLS failure at handover, catchable in 60 seconds
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 — the modal BOLA shape at handover
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 — the under-disclosed handover failure (CWE-732) that no automated scanner flags
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
/ FAQ

COMMON QUESTIONS

01
How is this catalog grounded?
Failure shapes are drawn from anonymized buyer-side engagements where we have audited AI-built SaaS at handover on Acquire.com, Flippa, and MicroAcquire, plus the reproducible scenarios on the public gapbench benchmark that mirror each shape. We do not publish a specific count of listings audited because the engagements are anonymized by design; the diligence flow itself, reproducible against gapbench, is the part anyone can verify.
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. The modal listing includes no security disclosure of any kind, no recent third-party audit, no penetration test summary. 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 catch the modal critical-blocker categories in this catalog (secrets in bundle, RLS off, open Firebase) in 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
Are these apps necessarily worthless?
No. The point of this catalog is not that AI-built SaaS is worthless — many of these apps have real customers, real revenue, and real product-market fit. The point is that the security state at handover is consistently poor and consistently 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
→
/ NEXT STEP

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 →