Incident
Base44 is a platform where people build working apps by describing what they want in plain language, and it was acquired by Wix. Companies had used it to build internal tools: chat helpers for staff, knowledge stores, and systems holding personal and staff records. Wiz Research, a security research team, set out to examine how platforms of this kind handle logging in.
The researchers began by listing Base44's public web addresses and found around five, all of them ordinary: the app itself, documentation, and marketing. Two of those addresses served pages that let any visitor browse and try the platform's built-in requests. Among them were a request that creates a new user account for an app, and a request that confirms that account with a code sent by email.
Every app built on Base44 carries an identifier, and it is printed in the app's web address and in a file the app publishes. Base44 offered app owners a choice of access settings, the strictest of which limited an app to invited staff signing in through their company login. Taking the identifier of an app set that way, and which they did not own, the researchers created an account, received the confirmation code by email, confirmed it, and then signed in through the app's own login page.
Wiz Research reported that the same worked across several private apps belonging to the affected enterprises, covering internal chat helpers, knowledge stores, personal details and staff operations. They also located apps in the wild by matching shared traits of the login page and of custom web addresses, and notified some of their own customers.
The report went to Base44 and Wix in July. Wix acknowledged it the same day and said it was working on a fix, which arrived in less than 24 hours; the following day the researchers verified that outsiders could no longer register to private applications. Days later Wix said the issue was resolved and reported no indication of compromise across Base44's user base. Base44's statement said: "We've investigated and, so far, found no evidence that any customer was impacted by an attacker leveraging the vulnerability," and that its investigation is ongoing. Public disclosure followed later that month. Wiz said no action was required from customers, and suggested organisations review their own app records for unusual visits and registrations.
Primary source — S1: https://www.wiz.io/blog/critical-vulnerability-base44Snapshot
Cause of loss
- The sign-up and email-confirmation steps treated knowing an app's identifier as permission to join it, and that identifier is printed in the app's own web address The identifier was never a secret; it shows in the address bar and in a file each app publishes. Because nothing beyond that identifier was weighed before an account was created, reading the address was enough to begin becoming a user of a private app.Technical name: insecure direct object reference
- The account-creation and confirmation steps ran before any login, so nobody had to prove who they were to use them, and the app's privacy setting was not consulted These two steps sat outside the checks that guarded the app's front page. A request carrying an email address, a password and the app's identifier produced a confirmed account, and the normal login then accepted that account like any invited one.Technical name: unauthenticated access
- Every app on the platform ran under the same joining rules, so a weakness in those rules reached every customer's private app at the same time The affected enterprises had chosen the strictest setting their supplier offered, and that choice was applied one level above the step that gave way. No customer could tighten the joining path themselves, because it belonged to the platform and was shared by all of its apps.Technical name: shared prod-dev infrastructure
Finding
A private space is only private if every door checks who is knocking. When the sign-up and email confirmation doors skip that check, the identifier of a private workspace stops being a secret and becomes an invitation; anyone who can see it can join. Guarding the front page while leaving the joining path open protects nothing.
Verification
What only you can answer
- When you set your app to the strictest option and turned on your company login, what did you take that to mean about who could create an account in it, and what did you put inside the app on the strength of that reading?
- Do you know which of the apps you run on a supplier's build-by-prompt platform hold staff records, customer personal details or HR material, and would you keep them there knowing the joining rules are the supplier's and are shared with every other customer?
- If a supplier told you tomorrow that outsiders could have created accounts in your private app, who in your company decides what staff and customers are told, and has that been agreed before it is needed?
What your AI can check
Report only; do not change any code or configuration. Give each answer with file or console references, and state plainly where something cannot be determined from what you can see.
- For each application we run, list every place its application identifier or tenant identifier appears where an outsider can read it: the URL, the manifest or similar published file, page source, sitemaps, and vendor documentation. Then list every server-side route that accepts that identifier as its only meaningful input, and report what authorisation check runs before the route acts on it; cite file or console references.
- Enumerate every route in our own code that can be reached without a valid session or token, paying particular attention to registration, invitation acceptance, password reset, and one-time-code verification. For each, report whether the application's privacy or membership setting is validated on the server before an account is created or confirmed; cite file or console references.
- Report whether the project has an automated test that attempts to register and verify an account against an application the caller was not invited to, asserts that the attempt fails, and runs on every change; cite the file, and say if no such test exists.
- Inventory every third-party build-by-prompt, low-code or hosting platform that runs an application on our behalf. For each, report whether interactive API documentation such as a Swagger-UI page is reachable without login on the vendor's domains, whether the vendor publishes security advisories or a status feed we are subscribed to, and which of our applications hold personal, HR or customer data on that shared platform; cite file or console references.
Prevention
Treat your app's identifier as an address, not a lock. Assume the string that names your app is public, because it sits in the web address. Ask whoever hosts your app to confirm in writing that someone holding that identifier, and nothing else, cannot create an account in it, and ask them to name which paths that promise covers: sign-up, email confirmation, invitations, and password reset.
Get the full list of ways an account can come into existence. Ask your supplier, in writing, for every route by which a new user of your app can be created, and who is checked on each one. Then ask them to send you a monthly list of accounts created in your private apps, and read it against your own staff list; that is a report you can act on without touching the product.
Assume you inherit your supplier's security, and place your data accordingly. Since the joining rules belong to the platform and are shared by all of its customers, decide deliberately what may live there: keep staff records, customer personal details and HR material off a shared platform until the supplier has answered the questions above in writing, and require in the contract that they tell you directly, and quickly, when a flaw of this kind is found and fixed.
A setting you chose only protects you as far down as your supplier's own doors.