The Rise of Base44

Base44 had one of those startup trajectories that makes venture capitalists misty-eyed. An AI-powered "vibe coding" platform that let non-developers describe what they wanted in natural language and get a working web application deployed in return, Base44 grew rapidly enough to catch the attention of Wix, the established website-building platform, which acquired it. The premise was compelling: describe your app, let the AI build it, click deploy. No coding required, no backend expertise needed, no infrastructure decisions to wrestle with.

The platform handled the architecture, the database, the authentication, and the hosting. Users just described what they wanted and reviewed the results. For internal tools, chatbots, HR management apps, and knowledge bases, Base44 was fast and functional. Organizations used it to build private enterprise applications - apps that handled personally identifiable information, HR operations, and other sensitive data behind authentication walls that Base44 provided.

On July 9, 2025, researchers at Wiz discovered that one of those authentication walls had a door in it that anyone could walk through.

The Vulnerability

The flaw was, as Wiz put it, "remarkably simple to exploit." Base44 hosted all applications built on its platform on shared infrastructure. Each app had an app_id - a unique identifier that was publicly visible in the app's URL and its manifest files. This is normal; application identifiers are typically not considered secrets because access control is supposed to be enforced separately.

The problem was two API endpoints on Base44's backend: user registration and OTP (one-time password) email verification. Neither endpoint required any authentication to call. An attacker who knew an app's app_id - which, again, was public - could call the registration endpoint to create an account on that app, then call the OTP endpoint to verify the account. The result was a fully verified user account on a private application, created without permission from the app's owner and without going through whatever authentication flow the app was supposed to require.

This bypassed everything. If the app used Base44's built-in authentication, bypassed. If the app used Single Sign-On (SSO) through an external identity provider, bypassed. The unauthorized registration happened at a layer beneath the SSO integration, so it did not matter how the app's front door was configured - the attacker was entering through a side entrance that existed in the platform's shared infrastructure.

Shared Infrastructure, Shared Risk

The scariest aspect of the Base44 vulnerability was its scope. This was not a bug in one app built by one developer. It was a bug in the platform's SDK - the shared code and infrastructure that every Base44 app relied on for authentication. Every private application hosted on Base44 was affected. Every one.

Wiz confirmed that the bypass worked against enterprise applications they identified during their research, including internal chatbots, knowledge bases, and apps handling HR data and PII. The researchers used standard reconnaissance techniques - CNAME record tracing (checking which domain names pointed to Base44's servers) and HTML-based platform signatures (identifying Base44 apps by their source code patterns) - to find and verify vulnerable applications in the wild.

The technical barrier to exploitation was almost nonexistent. No specialized tools were needed. No reverse engineering was required. An attacker needed only an app_id (publicly visible), the URL of two undocumented API endpoints, and the ability to send HTTP requests. Given those inputs, they could systematically create verified accounts on private enterprise applications across the entire platform.

The Vibe Coding Security Model Problem

The Base44 vulnerability illustrated a structural issue with vibe coding platforms that goes beyond any single bug. When a non-technical user builds an app on a platform like Base44, they are making an implicit trust decision: they are trusting the platform to handle security correctly. They have no way to audit the authentication implementation, review the API endpoints for access control, or test the authorization logic. Those details are abstracted away - that's the platform's value proposition.

If the platform gets authentication right, this works fine. If the platform gets authentication wrong, every app built on it inherits the same flaw. There is no user-side mitigation, no configuration the app builder could have set differently, no code review they could have performed. The vulnerability existed in the platform layer, below anything a Base44 user could see or control.

Traditional software development distributes this risk. If ten companies each build their own authentication, and one of them gets it wrong, only that company's users are affected. When ten companies build on the same vibe coding platform, and the platform gets authentication wrong, all ten companies' users are affected simultaneously.

Wiz framed this as the defining security challenge of vibe coding platforms: "shared infrastructure, shared risk." The platforms create new attack surfaces that traditional security frameworks may not account for, because the assumption has always been that authentication is implemented by the application developer, not inherited from a shared layer.

Disclosure and Response

Wiz disclosed the vulnerability to both Base44 and Wix on July 9, 2025, following responsible disclosure practices. The response was fast: Wix validated the report and implemented a fix in less than 24 hours. The patch ensured that Base44 properly validated application privacy settings before allowing user registration, closing the unauthorized registration path.

Wix stated that their investigation found no evidence of exploitation during the vulnerable period. Wiz independently verified that the fix resolved the issue - registration attempts on private applications were correctly blocked after the patch.

Base44 and Wix published a joint statement emphasizing their commitment to security and noting that the Wix acquisition had been motivated partly by a desire to bring Base44 under Wix's established security infrastructure. Whether the vulnerability would have been discovered and fixed as quickly if Base44 had still been an independent startup is an open question.

The Simplicity Problem

What makes the Base44 case particularly instructive is how basic the vulnerability was. This was not a novel attack technique, an exotic cryptographic failure, or a complex chain of exploits. It was two API endpoints without access controls. Registration and email verification - two of the most fundamental operations in any web application - were callable without any authorization check.

This is the kind of bug that a security review would catch in the first hour. It is also the kind of bug that an AI code generation tool might produce, because AI tools optimize for functionality ("make registration work") rather than security ("make sure only authorized registration attempts succeed"). Whether Base44's authentication code was written by humans, generated by AI, or some combination of both is not publicly known. What is known is that the result was a platform where the auth bypass was, in Wiz's words, trivially exploitable.

For organizations that had built private apps on Base44 to handle sensitive data, the disclosure prompted an uncomfortable question: what other basic security controls might be missing in the platform layers they depend on but cannot inspect? The vulnerability was fixed, but the trust model that allowed it to exist - non-technical users building apps on shared infrastructure where they cannot verify security claims - remains the fundamental architecture of every vibe coding platform.