Was my app affected by the July 2025 Base44 SSO bypass?

If your app used Base44's SSO-only access mode at any point before the platform patch in late July 2025, assume yes. Wiz disclosed the vulnerability publicly on July 22, 2025. Base44 patched within 24 hours. Any account registered during the exposure window may be unauthorized. There is no automatic remediation; you need to audit your user list manually and remove any account whose email domain is outside your SSO allowlist.

How would an attacker exploit it?

The exploit needed only the public app_id, which is exposed in the URL of any Base44 app. An attacker hit the registration endpoint with a target app_id and an arbitrary email, completed email verification on a domain they control, and ended up with a verified account on a private SSO-only app. Once inside, they could read any data RLS did not lock down per-user. This was the Wiz finding: 'Attackers could create a verified account on private apps using only an app_id.'

Did Base44 notify affected users?

Coverage of the disclosure varied. Securityweek and Dark Reading covered it; some Base44 customers reported they only learned about it through third-party channels. Base44 has not published a public list of affected apps. The conservative assumption is that you were affected if you had an SSO-only app during the window and you should audit accordingly.

Should I rotate JWT signing keys or session tokens?

Rotate any third-party API keys your Base44 app held during the window (Stripe, Twilio, OpenAI, etc.) because the JWT-leakage finding (Imperva) showed user JWTs could be captured by malicious code in user-built apps. The platform's own JWT signing was patched. Your application-level secrets stored in the app's environment should be rotated as a defense-in-depth measure.

Is Base44 secure now?

The specific vulnerabilities disclosed in July 2025 were patched within 24 hours. The structural exposure remains: Base44 is a hosted platform where security is the platform team's responsibility, with no customer SLA, no formal pentest cadence published, and no SOC 2 or comparable attestation publicly available as of May 2026. For apps handling regulated data (healthcare, finance, PII at scale), the structural risk is the binding concern, not any one bug.

Base44 SSO Bypass — Lock Down the Auth Vulnerability Now

What's happening

In July 2025, security researchers at Wiz disclosed 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 published parallel findings on JWT leakage and stored XSS in the same platform. Securityweek, Dark Reading, and Hacker News covered the disclosure.

Wiz's summary: "Attackers could create a verified account on private apps using only an app_id." The exploit was straightforward. The app_id is exposed in the URL of every Base44 app. Hit the registration endpoint with that ID and an arbitrary email. Verify the email on a domain the attacker controls. Land inside the SSO-only app with a verified user.

Base44 patched the platform within roughly 24 hours of disclosure. The patch closed the specific vulnerability. It did not remediate accounts created during the exposure window, did not retroactively notify affected customers in a comprehensive way, and did not publish a list of impacted apps.

If your app was SSO-only during that window, you should still treat your user table as untrusted today.

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 correctly verified that the email belonged to an SSO-allowlisted domain. If you were not in the allowlist, you could not log in.

The registration path did not. The endpoint that created a new user record on the platform accepted an app_id plus an email, sent a verification link, and on click created a verified account associated with that app — without checking the SSO allowlist. The attacker then logged in to that app via the standard email-and-password flow that the platform exposed even on SSO-configured apps.

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 parallel disclosure 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 simultaneously. 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 between approximately January 2025 and August 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 before August 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 parallel finding) means 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.

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.

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 has no published SOC 2, no formal SLA, and no customer-side security control over the platform's auth implementation. For HIPAA, PCI, GDPR-sensitive workloads, the right move is migration to a stack with formal attestations and 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 from before August 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.

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

Stored XSS leads to token theft — the parallel Imperva finding from the same disclosure cycle.
Data loss after returning to your app — RLS misconfiguration is part of the same auth-context fragility.
No SLA — your app is one outage from down — the structural reason platform-side security events hit so hard.