What's happening
The Base44 SSO bypass that Wiz reported on 9 July 2025 and published on 29 July 2025 let attackers register verified accounts on private SSO-only apps using only the public app_id, because the platform's registration and email-verification endpoints did not check the app's privacy setting the way the login flow did. The exploit needed only the app_id visible in any Base44 app's URL and an inbox to receive the one-time code. Wix fixed it within 24 hours, Wiz verified the fix on 10 July, and Wix reported no evidence of past abuse. Audit your user table for accounts registered on or before 13 July 2025 whose email domain is outside your SSO allowlist, rotate every API key the app held, and re-test RLS to confirm an outside account cannot read other tenants' data.
On 29 July 2025, security researchers at Wiz published a critical vulnerability in Base44 that allowed attackers to register verified accounts on private SSO-only applications using only the application's public app_id. Imperva had separately reported an open redirect, stored XSS and JWT leakage in the same platform in March 2025, and published its write-up on 27 August 2025. SecurityWeek and Dark Reading covered the Wiz disclosure.
Wiz's summary: "by providing only a non-secret app_id value to undocumented registration and email verification endpoints, an attacker could have created a verified account for private applications on their platform." The exploit was straightforward. The app_id is visible in the URL and manifest path of every Base44 app. Hit the registration endpoint with that ID and an email address. Enter the one-time code sent to that inbox. Land inside the SSO-only app with a verified user.
Wiz's own timeline: reported to Wix and Base44 on 9 July 2025, fix verified by Wiz on 10 July, issue confirmed resolved by Wix on 13 July "while reporting no indication of compromise across Base44 user-base", public disclosure on 29 July. The fix landed within 24 hours of the report, nineteen days before the public post. Wiz's post says "No action required from customers", and it also suggests reviewing registrations to your private apps from the vulnerable period ("July 9th and earlier"). We have not found a Base44 list of impacted apps, so that review is the only way to confirm your own app is clean.
If your app was SSO-only during that window, treat your user table as unverified until you have done that review. For the broader picture of how disclosed flaws affect your trust in Base44, weigh this incident alongside the platform's overall security track record.
Why this happens
The bypass existed because Base44's authentication had two paths to a user account on an SSO-only app, and the two paths had different access checks.
The login path enforced the app's private setting: on a "Private with SSO" app, access was meant to be limited to invited users, with SSO enforced in the sign-in flow.
The registration path did not. The api/apps/{app_id}/auth/register endpoint accepted an app_id, an email and a password, and api/apps/{app_id}/auth/verify-otp accepted the one-time code sent to that email. Together they created a verified account on the app without checking whether the app was private. Wiz reports that after confirming the email it "could just login via the SSO within the application page, and successfully bypass the authentication." The fix, per Wiz, "properly validates application privacy settings before allowing user registration."
The structural cause was a missing guard on a multi-tenant invariant. The platform team had implemented "SSO-only" as a UI gate and a login-path check, but not as a global property of the app's user-creation flow. Multi-tenant SaaS is hard precisely because every endpoint must respect the tenant's policy, and platforms like Base44 that abstract tenancy away from the customer cannot offload that work to the customer.
Imperva's separate disclosure (reported to Base44 in March 2025, published 27 August 2025) on stored XSS in /apps-show/ and JWT leakage to user apps showed that the same architectural pattern — platform-mediated trust without per-tenant enforcement — produced multiple vulnerabilities in the same year. The broader read is that Base44's security model assumed platform code would always be the security boundary, which is fragile in a code-generation product where platform code mutates rapidly.
Sources: wiz.io/blog/critical-vulnerability-base44, imperva.com, securityweek.com/flaw-in-vibe-coding-platform-base44-exposed-private-enterprise-applications, darkreading.com/application-security/critical-flaw-vibe-coding-base44-exposed-apps.
How to test if you're affected
Direct exploitation of the original bug is no longer possible — it was patched. What you can and should test is whether your current Base44 auth config has equivalent gaps and whether your user table contains accounts created during the exposure window.
- Open your Base44 app's user list. Filter or sort by registration date.
- List every user registered on or before 13 July 2025 whose email domain is outside your SSO allowlist.
- For each such user, verify whether the account was created by a legitimate process (a manual invite, a test account, etc.). Anything you cannot account for is suspicious.
- Audit access logs for those users. Note any data they read or wrote.
- Audit your own app's auth config: confirm SSO is currently enforced, confirm the registration endpoint is currently locked, confirm magic-link logins (if any) respect the allowlist.
- Test your RLS policies under a fresh SSO-bypass scenario: create a test user via standard registration, log in as them, and verify they cannot read records belonging to other tenants. If RLS is misconfigured, the bypass becomes worse than originally disclosed.
If step 3 surfaces unexplained accounts, treat the data they touched as exposed and notify your customers per your applicable disclosure obligations.
Step-by-step fix
You cannot patch the platform yourself. The original vulnerability was platform-side. What you can do is harden your app, audit user state, and rotate exposed secrets.
1. Audit and remove unauthorized users
Run a query (in the Base44 data view) listing every user not on your SSO allowlist, registered on or before 13 July 2025. Cross-reference with your invite log if you maintained one. Delete any account you cannot positively account for. Document each deletion with a reason for your security log.
2. Rotate every secret your app held during the window
JWT leakage to user-built apps (Imperva's separate finding, reported in March 2025) meant malicious code inside any Base44 app could capture authentication tokens. Treat every API key your app stored during the window as compromised:
- Stripe API keys
- Twilio, SendGrid, Mailgun, Resend keys
- OpenAI, Anthropic, Hugging Face API keys
- Any partner integration tokens
- Webhook signing secrets
Rotate them all. Update the new values in Base44's environment variables. Test that paid integrations still work post-rotation.
3. Force a password reset (or session revoke) for all users
Even if you only had SSO, force every user back through SSO at next login by invalidating existing sessions. Base44's SDK provides session-management primitives; if not, the simplest path is to bump a global "auth version" stored in user metadata and reject any session whose version is below current.
4. Verify RLS is enforcing per-user (not just per-app)
A SSO bypass is much worse if RLS lets the bypassed user read other tenants' data. For every collection, verify the RLS predicate filters by the authenticated user, not just by app membership. Test with a freshly created user and confirm they see zero records initially. If your app relies on the AI builder for schema changes, the Base44 RLS drift after AI edits failure mode compounds this risk — an SSO-bypassed user reaching a collection with stale RLS is the worst case.
5. Add request-level audit logging
If your app does not already log every authenticated action with the user ID and a timestamp, add it now. Send to an external log sink (Logtail, BetterStack, S3). When the next disclosure happens — and platform-side disclosures repeat — you want forensic data.
6. Subscribe to the Base44 status channel and Wix security advisories
Since the Wix acquisition in June 2025, Base44's security advisories sometimes flow through Wix. Add Wix's security RSS feed and Base44's status page to your monitoring. Set a Slack or email alert on new entries.
7. Reassess platform fit for sensitive workloads
If your app handles regulated data, the July 2025 incident is a structural data point. Base44 states its platform holds SOC 2 Type II and ISO 27001 certification and is independently penetration-tested, with the SOC 2 report and a GDPR DPA available on request (base44.com/security, read 23 Sep 2026). That covers Base44's own controls; it does not attest your app's configuration (row-level security, secrets, auth rules), which a security questionnaire will still ask about. What you still do not get on a self-serve plan is an SLA — Enterprise customers get SLA commitments in their contract — and on no plan do you control the platform's auth implementation itself. For HIPAA, PCI and GDPR-sensitive workloads, the right move is migration to a stack with customer-controlled auth (e.g., Supabase + your own Auth0 / Clerk / WorkOS integration).
DIY vs hire decision
DIY this if: You have a clean user audit trail covering registrations up to 13 July 2025, your app handles non-sensitive data, and you can spend a day on user-list cleanup and secret rotation.
Hire help if: You handle regulated data (healthcare, finance, anything PII-heavy), you have no clean audit trail of pre-window registrations, or you have customers asking for a formal incident report. This is a complex-fix engagement: we audit your full user history, run an RLS pen-test, rotate secrets with verification, and produce a written incident summary suitable for sharing with customers or regulators. A scoped base44 codebase audit is the right starting point if you do not yet know which of the disclosed flaws touched your app.
Need a security audit and remediation?
The auth-bypass remediation is a complex-fix engagement. We audit user history, RLS policies, and secret hygiene, deliver a written incident report, and verify hardening before handoff. Includes structured-evidence package suitable for customer disclosure.
Start a complex-fix engagement for the auth bypass
Related problems
- Stored XSS leads to token theft — Imperva's separate finding, reported in March 2025 and published in August 2025.
- Data loss after returning to your app — RLS misconfiguration is part of the same auth-context fragility.
- No SLA below Enterprise — outage risk — the structural reason platform-side security events hit so hard on self-serve plans.