Breach breakdowns

Breakdown: how a public app_id unlocked private Base44 apps

By Pritesh Ghodge, security engineer · Published 4 November 2026

In July 2025, Wiz Research disclosed a flaw in Base44, the AI vibe-coding platform bought by Wix. Anyone who knew an app's ID (which was in the app's URL) could create a verified account on private apps, including ones set to SSO-only. Wix fixed it within 24 hours and said it found no evidence of abuse. It's still a useful case study, because the same mistake turns up in hand-built and AI-built auth flows alike.

Timeline

• Early July 2025: While mapping Base44's attack surface, Wiz Research gets an alert about Swagger-UI (API documentation) interfaces exposed on two Base44 domains.
• 9 July 2025: Wiz confirms the authentication bypass and discloses it to Base44 and Wix.
• Within 24 hours: Wix ships a server-side fix. It says there's no evidence of past exploitation, and SecurityWeek reports that customers don't need to do anything.
• Late July 2025: Wiz publishes its write-up. The Hacker News, SecurityWeek, Infosecurity Magazine and Dark Reading cover it.

How the attack worked

Base44 gave app owners three access modes: public (anyone can sign up), private with beta authentication (which, as Wiz notes, still allowed self-signup), and private with SSO, the only truly private option.

Wiz found two undocumented endpoints that needed no authentication:

• api/apps/{app_id}/auth/register: register a user with an email address and password
• api/apps/{app_id}/auth/verify-otp: verify that user with a one-time password

The only input that identified the target was app_id, a random-looking string. It wasn't a secret. Wiz found it in every app's URL and hardcoded in the manifest path: manifests/{app_id}/manifest.json.

So the attack was:

1. Open the target private app and read its app_id from the URL or manifest.
2. Call register with your own email address and password for that app_id.
3. Receive the OTP by email and call verify-otp.
4. Log in. Because the server never checked whether the app allowed self-signup, the new account was accepted, getting around the SSO requirement.

Wiz says it confirmed this against several enterprise apps used for internal chatbots, knowledge bases, and PII and HR operations.

Root cause

The server didn't enforce the app's own privacy setting. The UI said "private, SSO only". The registration API didn't check that setting before creating an account. Dark Reading quotes Wiz saying Wix fixed it by "enforcing proper validation of application privacy settings before allowing users" to register.

Two smaller problems made it easy to exploit:

• An identifier was treated like a secret. A random ID isn't access control if it's in every URL.
• Undocumented isn't hidden. The endpoints weren't in the normal docs, but exposed Swagger-UI pages led researchers to them.

This is a platform bug, not a mistake by individual app builders. But the pattern, where the UI promises a restriction the API doesn't enforce, is one of the most common findings in AI-generated apps. Agents happily hide a "Sign up" button while leaving the signup endpoint wide open.

How to check your own app

Only test apps you own.

1. List your auth endpoints. Look at the network tab during signup, login, password reset and OTP flows. Note every URL.
2. Call them directly, outside the UI. If signups are meant to be invite-only, try registering with curl. If it works, the restriction exists only in the front end.
3. For Supabase apps: Dashboard → Authentication → Sign In / Providers. If "Allow new users to sign up" is on, anyone with your anon key can create an account, even if your UI has no signup page:

curl -X POST "https://YOUR-PROJECT.supabase.co/auth/v1/signup" \
  -H "apikey: YOUR_ANON_KEY" -H "Content-Type: application/json" \
  -d '{"email":"test+probe@yourdomain.com","password":"a-long-test-password"}'

If that returns a user, then any RLS policy that says to authenticated really means "anyone on the internet who signs up".

4. Search your bundle for IDs used as gatekeepers: tenant IDs, workspace IDs, "secret" invite codes. If knowing one is enough to get in, treat it as public.
5. Look for exposed API docs: /swagger, /api-docs, /openapi.json, /docs on production domains.

Fix steps

1. Enforce access rules on the server, every time. Registration, OTP verification and login should all check the app or tenant's settings (invite-only, SSO-only, allowed email domains) before acting.
2. Turn off public signup in your auth provider if your app is invite-only, and use invitations instead.
3. Don't write RLS for "authenticated" when you mean "member". Check membership:

create policy "members read"
  on public.documents for select
  to authenticated
  using (exists (
    select 1 from public.memberships m
    where m.org_id = documents.org_id
      and m.user_id = (select auth.uid())
  ));

4. Remove or protect API docs in production.
5. Write a test for each restriction: "an uninvited email can't register", run against the API, not the UI.

The takeaway

Base44 fixed this in under a day, and nobody appears to have been harmed. But "the UI hides it" isn't security, and an ID in a URL isn't a password. If your AI-built app has invite-only or private areas, try getting in through the API this week.

Abbi Labs checks Supabase projects from the outside for open signup and tables that anyone can read. The manual checks above are free either way.

Scan your app free

Sources

• Wiz Research, "Critical Vulnerability in AI Vibe Coding platform Base44"
• The Hacker News, Wiz uncovers critical access bypass
• SecurityWeek, Flaw in vibe coding platform Base44 exposed private enterprise applications
• Infosecurity Magazine, Authentication flaw in Base44
• Dark Reading, Critical flaw in vibe-coding platform Base44 exposed apps

Related

• Breakdown: how 170 Lovable apps left their Supabase data open (CVE-2025-48757)
• Tip: can a stranger sign up to your "private" app?
• Is the Supabase anon key safe to expose?
• How to check if your Supabase tables are readable by anyone