Is Base44 safe? A single flaw exposed every private app on the platform

In July 2025 the cloud security firm Wiz published a flaw in Base44, the vibe-coding platform Wix had recently acquired, that let anyone register a verified account inside a private application. Two endpoints in the shared SDK, the one that creates a user and the one that verifies a one-time password, required no authentication at all. The identifier they keyed off, app_id, was published in every app's URL and in its manifest.json.

That combination meant an attacker needed one number, visible on the page, to get inside an application whose owner had disabled registration and put single sign-on in front of it. Wix shipped a patch within 24 hours and found no evidence anyone had used it. The response was fast and the disclosure was handled properly, which matters, and it still leaves a question you should answer for your own app.

What exactly was broken?

Not your app. The bug lived in the platform SDK that every Base44 app called for authentication, which is why one flaw covered all of them at once.

The mechanics were plain enough to describe in a sentence. Registration and OTP verification were reachable without a session, they trusted an app_id that was never secret, and nothing checked whether the app in question was actually accepting new users. Single sign-on was configured correctly by the owners and simply bypassed, because the bypass ran beside it rather than through it.

That is worth sitting with for a second. The owners of those applications had done the thing security guidance tells them to do, which is put SSO in front of internal tools, and it made no difference to this attack. Controls you configure at the app level only hold if the platform beneath them is enforcing the same boundary.

Does a patched flaw still matter to me?

The specific bug does not; it is closed and you cannot reach it. Two things it demonstrated do.

Shared infrastructure means shared blast radius. On a hosted builder your authentication is one implementation used by every customer, so a defect in it is not your bug and is entirely your problem. This is the trade you make for not writing auth yourself, and for most people it is still the right trade, because the auth you would have written has bugs too. It is a trade to make knowingly rather than by default.

Public identifiers are inputs, not secrets. The app_id was doing security work by accident, and nobody decided it should. If any part of your own app treats an id in a URL, a tenant slug or a project key as though attackers cannot see it, you have built the same class of thing at a smaller scale.

What is still mine to check on Base44?

Everything specific to the app you built. It is the same list every hosted builder leaves behind, and none of it got safer when the SDK was patched.

• Cross-account reads. Make a second account, then load a record belonging to the first by changing the id in the address bar. This is the most common serious flaw in generated apps and it is invisible while you test as yourself.
• Keys in the browser. Open the deployed app, open developer tools, search all loaded files for sk-, secret and token. Anything that looks live is live.
• Server-side plan checks. Call a premium endpoint from a free account with the network tab open. If it answers, the paywall is a CSS rule.
• What you connected. Every third-party integration you wired up carries its own credential and its own scope, and the scope is usually wider than the feature needs.
• What the app collects. A form built in an afternoon collects whatever fields the model suggested. If that includes phone numbers or addresses, you now have obligations that a security check will not cover.

How should I think about platform trust generally?

Assume every hosted builder will have at least one disclosure of this shape, because they all have a shared auth layer and a large surface, and assume most will handle it the way Wix did. That is a reasonable baseline and not a reason to avoid the category.

Then keep the two halves separate in your head. Platform risk is a subscription you pay by keeping up with disclosures and patching quickly, and there is very little else you can do about it. Application risk is yours, it does not get patched by anyone else, and it is where almost every real breach of an AI-built app actually starts.

What should I do this week?

Run the five checks above; they take about half an hour and they cover the flaws people actually get hit by. If a check fails, fix that one before you read further, because a confirmed cross-account read outranks anything else on the list.

Then be honest about what a checklist reaches. It finds what it lists and looks where you point it, and the flaw that gets exploited is usually in the file you did not think to open. That is the gap Sentrint fills: it reads the entire repository, reports what an attacker would reach first in plain English, and gives you a fix you can paste back into the tool that wrote the code. The first scan is free and needs no card, and it reads what you wrote rather than attacking your running site.

The Base44 flaw was closed by somebody else in a day. The one in your own code will wait as long as you let it.