Base44 Security: What Authentication Bypass Means for Builders

In July 2025, Wiz Research discovered a critical authentication bypass in Base44, a vibe coding platform used by enterprises to build internal tools, HR systems, and customer-facing applications. The vulnerability allowed anyone to register a verified account inside any private application built on Base44 — bypassing SSO, authentication walls, and every access control the application had configured.

The technical requirement: knowledge of an application's app_id. A value that was publicly visible in every Base44 app URL and in publicly accessible manifest files.

The vulnerability was fixed in less than 24 hours. No evidence of exploitation was found. But the incident opened a conversation about vibe coding platform risk that every founder building on Base44, Lovable, Bolt, or any AI development platform should understand.

How Did the Base44 Authentication Bypass Work?

Base44's platform included undocumented API endpoints for user registration and email verification. These endpoints were accessible without any authentication.

The normal flow for a private Base44 application was protected by SSO — users had to authenticate through their organization's identity provider before accessing the app. The vulnerability bypassed this entirely:

1. An attacker visits a private Base44 application's URL
2. The URL contains or exposes the application's app_id
3. The attacker calls the undocumented registration endpoint with that app_id
4. The endpoint creates and verifies an account without any authentication
5. The attacker now has full access to the private application as a verified user

Applications used for HR operations, internal knowledge bases, PII data, and customer-facing tools were all affected — any application where SSO was the intended access control mechanism.

SecurityWeek's reporting noted the flaw was exploitable with "basic API knowledge" — no credentials, no token theft, no sophisticated attack chain. The authentication model assumed that knowing an app_id was sufficient proof of authorization to register. It was not.

What Does Base44 Handle Automatically vs. What Is Your Responsibility?

Base44 handles a significant portion of the infrastructure layer: application hosting, the AI generation environment, initial user authentication UI, SSO integration at the platform level, and deployment. For many builders, this is the value proposition — you do not manage servers, you do not configure authentication from scratch, and you do not deploy manually.

What Base44 does not handle automatically: the authorization logic inside your application (whether a given authenticated user can access a specific piece of data), the correctness of your database-level access policies, the isolation of sensitive credentials in your code, and the rate limiting on your application's endpoints.

The breach showed exactly where this line sits. Base44 handled SSO authentication. What it did not handle was the unauthorized registration endpoint in its own infrastructure — and once that bypassed the platform's authentication, every application's own authorization layer became the last line of defense. Applications that had Supabase RLS correctly configured with auth.uid() scoped policies had a meaningful backstop. Applications that relied entirely on the platform's authentication had none.

Base44 builders did not write the vulnerable registration endpoint. Wix did. The flaw was in the platform infrastructure, not in any individual founder's code. But the consequence landed on each application built on the platform.

This is the second dimension of vibe coding security risk that most guides do not address. The first dimension is what AI tools generate when you prompt them — the RLS gaps, the unprotected routes, the API keys in client bundles — all covered in our vibe coding security risks guide. The second dimension is what the platform itself introduces regardless of your code quality.

Three documented examples from 2025–2026:

The common thread: platform-level vulnerabilities have blast radius proportional to the platform's user base. A single flaw affects every application built on that infrastructure, whether the individual app was built well or not.

This is not a reason to avoid building on platforms — it is a reason to understand that your security posture depends on both your code and the platform's code, and you only control one of them.

What Security Gaps Does Base44 Leave for Builders to Fill?

Even though the specific vulnerability is patched, Imperva's analysis noted that the incident highlights broader questions about authentication architecture in vibe coding platforms. The following checks apply to any Base44-built application:

1. Do Not Rely Solely on Platform Authentication

If your application stores sensitive user data, the platform's authentication should be a first gate, not the only gate. Your application-level code should independently verify that the requesting user is authorized for the specific action and resource — not trust that the platform's auth layer is infallible.

For Supabase-backed Base44 apps, this means RLS policies that enforce ownership at the database level, independent of whether the application's session is valid. If the platform authentication layer were bypassed again, RLS would prevent the attacker from reading rows that do not belong to them.

2. Enable and Verify Supabase RLS

If your Base44 application uses Supabase as its database backend, confirm row-level security is enabled on every user-facing table. Check each policy references auth.uid():

-- Correct: scoped to the requesting user
CREATE POLICY "users can read own records"
ON user_data FOR SELECT
USING (user_id = auth.uid());

-- Dangerous: allows any authenticated user to read all records
CREATE POLICY "authenticated users can read"
ON user_data FOR SELECT
USING (auth.role() = 'authenticated');

See our Supabase security checklist for the full policy validation process.

3. Verify Service Role Key Isolation

Base44 apps that connect to Supabase for data storage should confirm the service role key is not accessible to client code. The service role key bypasses all RLS policies — if it reaches the browser, platform-level authentication controls are irrelevant.

Check every file in your codebase that references service_role or SUPABASE_SERVICE_ROLE_KEY. Each should be server-only code that no client component imports.

4. Audit What Data Your Application Actually Stores

The Base44 vulnerability exposed HR systems, PII data, and internal communication tools. The severity depended entirely on what data each application held. Applications that stored non-sensitive data faced minimal real-world risk. Applications storing employee records, customer PII, or financial data faced a different situation.

Audit what your application stores. Minimize what must be stored. Encrypt what cannot be minimized. The principle of least data means the blast radius of any platform-level failure shrinks proportionally.

5. Monitor for Anomalous Access Patterns

Because platform-level vulnerabilities can exist without your knowledge, monitoring for unusual access patterns provides a detection layer that does not depend on knowing about the vulnerability in advance. Unexpected spikes in authenticated requests, access from unusual geographic locations, and queries for data that normal users do not typically access are all signals worth alerting on.

How Do You Stay Secure When the Platform Itself Can Fail?

The Base44 incident — alongside Lovable's 48-day BOLA exposure and the Moltbook RLS failure — represents a pattern security researchers are beginning to map systematically. All three are detailed in our vibe coding hacks breakdown.

Vibe coding platforms lower the barrier to building production software. That is their value. The same architecture that enables fast building — shared infrastructure, AI-generated scaffolding, opinionated defaults — concentrates risk. A single flaw in Base44's registration system affected every enterprise application on the platform. A single architectural decision by Lovable's API team affected eight million users' projects.

The response to this is not to avoid vibe coding platforms. It is to understand that platform-level security is a shared responsibility, and your contribution to that responsibility is the code you write on top of the platform — not the platform code itself.

Defense-in-depth means your application is still secure even if the platform layer fails: RLS enforces data access at the database level, server-side authorization verifies resource ownership in your code, service role keys are isolated, and no sensitive values are accessible to client-side code.

An automated scan covers the aspects of this that your own review will miss. Run a free Ubserve scan on your Base44 application to check for exposed credentials in your frontend, missing RLS coverage, and authorization gaps in your API layer. The full pre-deploy checklist covers everything to verify before your next production deploy.

The Base44 vulnerability was patched in 24 hours. The lesson about building on platforms — and what your own code needs to handle independently of the platform — does not have an expiry date.

— Mr. Ballaz, Founder of Ubserve