Our research uncovered multiple critical vulnerabilities in Base44, an AI-powered platform that lets you turn any idea into a fully functional custom app. These flaws ranged from an open redirect that leaked access tokens, to stored cross-site scripting (XSS), insecure authentication design, sensitive data leakage, and client-side-only enforcement of premium features.
Together, they represented a broad attack surface with real-world impact. The vulnerabilities were responsibly disclosed to Base44, and the vendor moved quickly to implement fixes.
Background
Platforms like Base44, Loveable, and Bolt are at the forefront of the “vibe coding” movement, where natural language prompts replace traditional programming. Businesses increasingly rely on them to build internal chatbots, automate workflows, and launch customer-facing applications. But with this rapid adoption comes systemic risk.
These platforms handle authentication, data storage, and app hosting at scale. Any flaw in their shared infrastructure cascades across all applications, magnifying the impact of each vulnerability.
- Lovable RLS Misconfigurations CVE-2025-48757: In March 2025, researchers disclosed that Lovable’s Row Level Security (RLS) implementation often left applications with insecure or misaligned access controls. Attackers could bypass frontend checks and directly exfiltrate or corrupt sensitive data.
- Over-Sharing by Default: Services like Lovable and similar platforms have been called out for making it “too easy to expose private data” (per Replit’s CEO Amjad Masad). With minimal guardrails, inexperienced developers can accidentally leak personal information, tokens, or customer records into public endpoints.
Collectively, these failures highlight how vibe coding’s promise of speed and accessibility often comes at the cost of fundamental security.
Open Redirect in Authentication Flow Enabling Account Takeover
The login flow failed to restrict redirects to trusted domains, allowing attackers to supply a completely different domain (such as example.com). As a result, users and their tokens could be redirected straight to a malicious site.
With the stolen token, an attacker could:
- Access the victim’s apps and development workspace.
- Harvest API keys, secrets, and project configs.
- Inject malicious logic into user-generated applications.
- Exfiltrate or even delete critical assets.
The exploit scenario would follow this pattern:
- The attacker crafts and sends a link:
https://app.base44.com/login?from_url=https://example.com - The victim logs in via Google OAuth.
- The access token is appended to the redirect URL.
- The attacker’s domain receives the token, gaining full session access.
Fig. 1: Screenshot of the crafted URL on top of the navigator bar
Fig. 2: Navigator after the open redirect
The issue was partially fixed at first, but the validation only checked whether the redirect started with https://app.base44.com. This left a gap, since domains like app.base44.com.example.com could still slip through. We reported this, and the final fix introduced strict validation of the full redirect URL.
While the open redirect flaw made it possible to steal tokens during login, another weakness let attackers go even further by storing malicious JavaScript inside Base44’s own trusted domain.
Rendering Untrusted Code on app.base44.com Led to Stored XSS
We identified a stored cross-site scripting (XSS) vulnerability in the /apps-show/{app-id} endpoint. This endpoint was designed to render user-created apps inside the trusted app.base44.com domain, the same domain where users authenticate and manage their accounts.
Because premium features like editing the AI generated code were only enforced client-side, it was possible to modify the code of an app to include arbitrary JavaScript. When the app was loaded via /apps-show/, this injected code would execute directly within the privileged context of app.base44.com.
Fig. 3: Stored XSS on app.base44.com
This design flaw created a high-impact scenario. An attacker could craft a malicious app, inject JavaScript, and then trick another user into visiting its /apps-show/ link. Since the payload executed inside the trusted domain, it had access to authentication tokens stored in the browser local storage, and other sensitive data.
In practice, this meant an attacker could hijack user accounts or perform actions on their behalf. By combining the weak premium feature enforcement with this stored XSS, attackers had a clear path full account takeover.
After exploring XSS, the next issue centered on token handling.
Main Platform JWT Leaked to User-Built Apps
When a user logged into an app built on Base44, the platform passed the same JWT used to log into the main Base44 account directly to that app through the URL. The problem is that these apps could run arbitrary JavaScript, meaning the developer of the app, or anyone who could inject code into it, could easily grab the token.
With that JWT in hand, an attacker wouldn’t just control the single app: they could access the victim’s full Base44 account, including other apps and sensitive data.
Key Takeaways
The Base44 vulnerabilities highlight how small design flaws in shared infrastructure can escalate into platform-wide risks. As AI-driven development accelerates, the most pressing threats are often not exotic AI attacks but failures in classical security controls.
To protect the growing ecosystem of “vibe coding” platforms, security must be treated as a foundation, not an afterthought. That means rigorous authentication, careful isolation, and ongoing collaboration between vendors and researchers to prevent single flaws from rippling across thousands of businesses.
Timeline
March 2025
• Vulnerabilities discovered and reported to Base44
• Partial fixes deployed (XSS, open redirect tightened, API leaks)
April 2025
• Additional fixes and architectural changes in progress
August 2025
• Public disclosure (this post)
The post Critical Flaws in Base44 Exposed Sensitive Data and Allowed Account Takeovers appeared first on Blog.
