Base44 is an AI app builder: you describe an app and it builds it, including logins and a database. In June 2025 Wix bought it for a reported $80 million. Some companies used it to build internal tools, such as chatbots, knowledge bases and apps handling HR and personal data, and restricted them to employees using single sign-on (SSO).
On 9 July 2025, researchers at Wiz found they could create an account on those private apps anyway.
How it worked
Wiz's write-up describes two API endpoints on Base44's platform: one for registering a new user on an app and one for verifying that user's email with a one-time code. Neither required any authentication. Both took one piece of information to know which app you were joining: its app_id.
That app_id wasn't secret. Wiz noted it was visible in the address of any Base44 app and in the path of its manifest.json file. So anyone who could see an app's login page could read its ID, call the registration endpoint directly, verify the account with the code sent to their own email, and sign in. That worked even for apps set to SSO-only, because the registration endpoint was a separate route that didn't go through the SSO check.
Wix fixed it within 24 hours of the report. Wiz published its findings on 29 July, and Wix said it found no evidence the flaw had been abused.
Why this pattern keeps happening
It's tempting to file this under "platform bug, not my problem". The platform part is true: Base44 users couldn't have fixed it themselves. But the underlying mistake shows up in apps people build every day, including ones built with AI.
The mistake is treating an identifier as if it were a secret. The app_id identified which app you wanted. The system then behaved as though knowing it meant you were allowed in. IDs end up in URLs, logs, screenshots and shared links. They're for finding things, and they don't prove anything about who's asking.
The second mistake is having more than one door and locking only the front one. The login page enforced SSO, and the registration API didn't. Attackers don't use your UI. They call whatever endpoints your UI calls, plus any they can find.
Where this shows up in your own app
Sign-up, password reset, email verification, magic links and team invitations are all ways to get into your app. Each needs to enforce the same rules as the main login. A few things to check:
Invite-only apps. If only invited people should be able to join, try calling the sign-up endpoint directly without an invite. Many AI-built apps hide the sign-up button for uninvited users but leave the API open. In Supabase, check whether public sign-ups are enabled in the Auth settings.
Domain restrictions. If only @yourcompany.com emails should join, check that the restriction is enforced on the server, not only in the form's validation.
Password reset. Request a reset for account A, then check that the link or code can't be used for account B, can't be reused, and expires.
Team or workspace IDs. If users join a workspace by ID or slug, confirm that knowing the ID isn't enough. They should need an invitation tied to their email.
Admin routes. Visit /admin and any internal API routes while signed in as a normal user. We often find admin pages that are hidden from the menu but not protected.
The platform question
This incident also raises a fair question for anyone building on an AI platform: how much of your security depends on the platform getting its own security right?
Some of it always will, whether you use Base44, Lovable, Replit or a traditional cloud provider. You can't audit their internals. You can pick platforms that disclose issues quickly and fix them fast, which Wix did here, keep sensitive data minimal, and test your own app from the outside so you know what an attacker sees. An outside test would have shown a working registration endpoint on an SSO-only app, whoever wrote it.
For the parts that are yours, the pre-launch checklist has an accounts and sessions section that covers every door above.