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 addressThe 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 consultedThese 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 timeThe 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
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.