Replit Slams "Europe's Cursor": Hundreds of "High-Risk" Apps Created, Ordinary Developers Hacked in an Hour, Vibe Coding Becomes a Hacker's "Paradise"?

image\nimage\n

Edited by |Hua Wei, He Zi Ke Le

\n

Recently, an employee from AI coding assistant company Replit reported that Lovable, the developer of "Europe's Cursor" and a popular "vibe coding" application, has yet to fix a critical security vulnerability despite being notified several months ago.

\n

According to Matt Palmer, an employee of Replit, the AI coding assistant vendor who authored this report, he and a colleague scanned 1645 web applications developed by Lovable on their website. After verification, 170 of these applications allowed anyone to access user information, including names, email addresses, financial details, and API keys for AI services.

\n

Currently, this vulnerability has been listed in the National Vulnerability Database, highlighting the growing security risks when AI enables anyone to participate in software development: every new application or website created by a novice could become a direct target for hackers.

\n

Multiple Engineers Successfully "Hacked" Lovable

\n

Lovable is a Swedish startup positioned as "the last piece of the software puzzle," claiming its services greatly reduce development barriers, helping clients create websites and applications using only natural language prompts without any technical training.

\n

However, according to Matt Palmer, a Replit employee, "Applications developed using the Lovable platform often lack secure RLS configurations, leading to unauthorized access to sensitive user data and injection of malicious data."

\n

Lovable's applications are primarily client-driven, relying on external services for backend operations like authentication and data storage. This architecture shifts security responsibility to the application developers. However, the misalignment between client-side logic and Row-Level Security (RLS) policies often leads to vulnerabilities, allowing attackers to bypass frontend controls and directly access or modify data.

\n

On March 20, Palmer noticed a vulnerability in a Lovable-created website called Linkable (which automatically converts a user's LinkedIn profile into a personal website)—an inspection of network requests showed that modifying query parameters could access all data in the project's "users" table. Palmer was able to see the email addresses of approximately 500 users of the application.

\nimage\n

"When we pointed out this issue in Lovable's official account reply, the company first denied the vulnerability, then deleted the related tweets and website. Soon after, Linkable was relaunched and started charging $2," Palmer stated.

\nimage\n

He discovered that the incorrect Supabase database configuration was the cause. Palmer posted on X to notify Anton Osika, co-founder and CEO of Lovable, but Osika responded that there was no problem.

\nimage\n

The next day, Palmer and his colleague Kody Low conducted a more in-depth analysis, collectively identifying 170 vulnerable Lovable websites. They reported the vulnerability to Lovable. Lovable confirmed receipt but did not reply to the email.

\n

Subsequently, they formally disclosed the vulnerability on April 14, initiating a 45-day disclosure window.

\n

On April 15, another software engineer, Danial Asaria, also discovered this Lovable vulnerability and posted on X, reminding developers to be cautious when choosing "vibe coding" platforms to entrust personal data.

\n

Reportedly, he "hacked" into several websites on Lovable's recommended page and, in just 47 minutes, found a large amount of personal debt, home addresses, API keys, and "suggestive prompts." Moreover, he emphasized that he "wasn't acting as a hacker—but as a curious developer using 15 lines of Python code (to discover this)."

\nimage\n

On the same day, Palmer again notified Lovable, incorporating information about publicly known exploits.

\n

Following this, Lovable responded to external doubts, announcing the implementation of a new feature and stating that it "will scan applications for security issues before release." On April 24, Lovable launched "Lovable 2.0" with a new "security scan" feature.

\n

However, according to Palmer, it still "did not address the underlying RLS architectural flaw."

\n

According to the vulnerability report, this security scan only does one thing: determine if Supabase database access control is enabled. That is, Lovable still avoids the core issue of whether control options are correctly configured, a problem even experienced software developers often get wrong.

\n

On May 24, Palmer re-evaluated the vulnerability status of the Linkable website. The result was that the website still had serious security issues such as data manipulation and injection, also exposing systematic RLS implementation flaws within the Lovable ecosystem.

\n

Since Lovable did not take effective remedial measures or notify users, they published the CVE ID for this vulnerability on May 29 (CVE stands for Common Vulnerabilities and Exposures, a public list of cybersecurity vulnerabilities).

\nimage\n

Should "Vibe Coding" Tools Bear Security Responsibility?

\n

"Vibe coding and similar paradigms should inherently enhance security to empower users, rather than breed vulnerabilities or completely shift security responsibility to users (or even blame users for lacking security awareness)," Palmer stated after publishing Lovable's CVE ID.

\n

Currently, code generation models lack a good global perspective and cannot thoroughly examine how the code will ultimately be used. They might provide guidance on specific problems, but inexperienced users would clearly find it difficult, or even impossible, to know what questions to ask.

\n

For example, Lovable claims to use AI models to instantly create websites. But to implement most functions, websites must connect to databases storing user accounts and payment information. Lovable itself is not responsible for building such databases; it merely provides a convenient way for users to connect to a database service operated by a startup called Supabase.

\n

Alex Stamos, Chief Information Security Officer at cybersecurity company SentinelOne, stated that best practices for web applications require completely preventing users from direct database access. Instead, applications should determine what information users can access and deliver data accordingly. In this sense, it's somewhat like a delivery person bringing a package to a user's home, rather than users rushing into a package sorting facility.

\n

However, specific implementation methods are often very complex. Stamos stated that during his tenure as Chief Security Officer at Facebook, the greatest consumption of computing resources was concentrated on access control—i.e., determining what data users could see and then delivering relevant content to them.

\n

In his view, allowing users to directly access the database clearly carries enormous risks. "While there are correct ways to handle it, the success rate is often extremely low."

\n

Lovable in an April X discussion post told users that websites built with their service were "almost guaranteed to be secure." However, the company also admitted that improper configuration of Supabase could lead to data leakage. For sensitive data, Lovable recommended "manual security review," meaning that clients using "vibe coding" also bear some responsibility.

\n

Foreign media reported that Lovable's biggest problem was not the security vulnerability itself, but their communication with customers. The company promised users could safely create various applications with their service, but simultaneously shifted the responsibility for protecting application security onto the customers.

\n

However, as a "vibe coding" company, Lovable's explicit admission of its inability to be responsible for the security of applications created is somewhat reasonable. After all, since the birth of the Web, responsibility for security, privacy, and various issues has always been borne by the owners of online services, not by the tools used to create them.

\n

On May 30, Lovable publicly responded on X, "Compared to a few months ago, Lovable has significantly improved in building secure applications and is rapidly progressing. That being said, our security level has not yet met expectations, and we are committed to continuously improving the security status for all Lovable users."

\n

Perhaps "vibe coding" should be regarded as a new software category, not just a software creation tool. Applications supporting "vibe coding" should therefore establish sandboxes to limit the potential damage they can cause. While this would limit application functionality, it would also clarify the boundaries of responsibility. If users place applications outside the sandbox and decide to use them for commercial purposes, they would naturally bear the corresponding consequences.

\n

It is understood that Replit is currently exploring this sandbox approach, which is likely one of their core motivations for explicitly criticizing Lovable and repeatedly emphasizing security issues.

\n

Amjad Masad, CEO of Replit, stated in a declaration, "'Vibe coding' has made a huge contribution to the popularization of software development. We cannot expect novice developers to understand and master underlying security configurations. But if a tool claims to easily deploy applications, it should also be capable of preventing accidental exposure of sensitive data."

\n

It is worth noting that while Masad criticized Lovable's issues, Lovable founder Anton Osika retaliated with a counter-response:

\nimage\n

1. Become the founder of Replit;

\n

2. Be ten years ahead;

\n

3. Watch helplessly as Lovable, a rising competitor from the EU, completely surpasses you in usage and "vibe coding" security guarantees;

\n

4. Copy their features four weeks later;

\n

5. Criticize Lovable for not being secure enough.

\n

"Vibe Coding" Users "Battle" Professional Hackers

\n

Recently, various AI-assisted development technological advancements have not only democratized programming but also lowered the barrier to entry for complex development tools. Today, coding agents can perform services like database setup and user authorization—tasks that once took professional developers days or even weeks to complete.

\n

However, without strong default security settings, protection mechanisms, or even deeper defensive architectural patterns like client/server separation, such solutions can widely breed security vulnerabilities. Users unfamiliar with web development best practices may inadvertently develop applications that endanger themselves and their users through "vibe coding."

\n

On X and Reddit, many "vibe coding" users have posted about their applications being quickly hacked due to a lack of security knowledge after development. One "vibe coding" user posted in March this year, "Friends, I've been hacked... As you all know, I'm not tech-savvy, so it took me a long time to figure out what was going on."

\n

"This is also the biggest challenge currently facing 'vibe coding'; amateur-developed products are far from secure," said Simon Willison, a veteran software developer and entrepreneur focused on new AI tools. He believes that as the first batch of "vibe coding" consumer products are about to hit the market, this problem may fully erupt. "We are about to face a fierce impact."

\n

In the mid-1990s, when consumer web applications were still emerging, hackers frequently exploited vulnerabilities in security systems using what now seem like rudimentary techniques. Over time, basic security measures became commonplace, and hackers had to elevate their skill levels. Today, hackers are often state-sponsored, using automated tools to scan the internet for readily available targets—including computers that haven't fixed known vulnerabilities and users who use the same password on multiple websites.

\n

With the rise of "vibe coding," security standards for applications and websites have again relaxed, and everything seems to have reverted to the nascent stage of the Web in the 1990s. Meanwhile, hackers are using more advanced tools to scout for opportunities to profit.

\n

Stamos pointed out, "In the 90s, attackers and defenders grew together. But today, 'vibe coding' users face a group of experienced, even state-sponsored, professional hackers."

\n

Isaac Evans, CEO of security company Semgrep, stated that this issue creates opportunities for vendors developing automated security layers for "vibe coding" applications, such as Semgrep, which offers a software system vulnerability identification service. Evans noted that, from some perspectives, tools like Semgrep are expected to become an important part of the "vibe coding" process.

\n

"One could say that this is currently the golden age of the security industry."

\n

This might be one reason why Osika specifically posted that image on X: a photo of two men laying bricks crookedly, with the caption "Keep using vibe coding, we'll fix it whenever."

\nimage\n

It can be said that the rise of "vibe coding" trends has undoubtedly sparked new concerns: In an era where developers can create consumer-grade products without any security knowledge, who should guarantee consumer product safety? Even if AI-written code itself is flawless, "vibe coding"-based software can still lead to significant security vulnerabilities due to its implementation.

\n

At the same time, it's also a warning to "vibe coding" users: the content you create is likely full of security vulnerabilities, and releasing it carelessly online will inevitably become a huge risk.

\n

References:

\n

https://www.semafor.com/article/05/29/2025/the-hottest-new-vibe-coding-startup-lovable-is-a-sitting-duck-for-hackers

\n

https://mattpalmer.io/posts/statement-on-CVE-2025-48757/

\n

Disclaimer: This article is translated and compiled by InfoQ and does not represent the platform's views. Reproduction without permission is prohibited.

\n

Recommended Articles Today

\n

Redis Creator: Even if I get flamed, I have to say, AI is far behind human programmers! Developer comments: Large models make me want to write code myself with more vigor.

\n

ByteDance reportedly started banning Cursor internally.

\n

1.2 billion model downloads, yet core team is nearly disbanded: Uneven computing power allocation, profit crushing innovation?

\n

India's national-level large model only downloaded 300+ times in two days, investors call it "embarrassing": Korean university student models have 200,000!

\n

Event Recommendation

\n

AICon Beijing on June 27-28 will continue to focus on cutting-edge breakthroughs and industrial implementation of AI technology, deeply discussing the latest trends in technology and application integration around hot topics such as AI Agent building, multimodal applications, large model inference performance optimization, data intelligence practices, AI product innovation. We welcome your continued attention as we explore the infinite possibilities of AI applications!

\nimage

Main Tag:Cybersecurity

Sub Tags:Software DevelopmentDeveloper ToolsVulnerability ManagementAI Code Generation


Previous:Stanford Chinese Team's Surprise Upset! AI Writes Pure CUDA-C Kernels, Outperforming PyTorch?

Next:Sakana AI's New Research: The Birth of the Darwin-Gödel Machine with Self-Encoding Improvement and Self-Referential Open-Ended Evolution

Share Short URL