Replit 员工揭露 Lovable 平台存在安全漏洞，引发关于氛围编码安全责任的讨论。在这种新兴开发模式下，用户安全谁来保障？
原文标题：Replit 怒锤“欧洲版 Cursor”：造出百款“高危”应用，普通开发者一小时内黑入，氛围编码成了黑客“天堂”？
原文作者：AI前线
冷月清谈：
怜星夜思：
2、文章提到“氛围编码用户面对的则是一群经验老到、甚至有国家支持的专业黑客”，那么对于普通的氛围编码用户来说，在缺乏专业安全知识的情况下，应该如何保护自己和用户的数据安全？
3、文章最后提到了 Replit 正在探索沙箱方法，你认为沙箱技术能否有效解决氛围编码带来的安全问题？它的局限性又在哪里？
原文内容
近日，一位来自 AI 编程助手公司 Replit 的员工报告，号称“欧洲版 Cursor”、热门氛围编码应用开发商 Lovable 虽在几个月前就已收到相关通报，但至今仍未修复一处关键安全漏洞。
据撰写这份报告的 AI 编程助手厂商 Replit 员工 Matt Palmer 称，他和一位同事扫描了 Lovable 网站上 1645 款由其开发的 Web 应用程序。经过审查核实，其中 170 款应用程序允许任何人访问网站的用户信息，包括姓名、电子邮件地址、财务信息以及 AI 服务的 API 密钥。
当前，该漏洞已经被列入国家漏洞数据库，也凸显出 AI 让任何人都能参与软件开发所带来的日益严重的安全隐患：新手创建的每款新应用或者新网站，都有可能成为黑客的活靶子。
Lovable 是一家来自瑞典的初创企业，其产品定位为“软件体系的最后一块拼图”，其提供的服务号称能极大降低开发门槛，帮助客户无需任何技术培训、仅使用自然语言提示词即可创建网站及应用程序。
但据 Replit 的员工 Matt Palmer 介绍，“使用 Lovable 平台开发的应用程序常缺乏安全的 RLS 配置，导致未经授权者可访问敏感用户数据并注入恶意数据。”
Lovable 的应用程序以客户端驱动为主，依赖外部服务完成身份验证和数据存储等后端操作。这种架构将安全责任转移给了应用程序的开发者。然而，客户端逻辑与后端权限控制（RLS）策略的错位经常引发漏洞，攻击者可绕过前端控制直接访问或修改数据。
3 月 20 日，Palmer 注意到，Lovable 创建的一个名为 Linkable 的网站（该网站能够自动将用户的 LinkedIn 页面资料转化为个人网站）存在一项漏洞——对网络请求的检查显示，修改查询参数就能访问项目“用户”表中的所有数据。据悉，Palmer 能够看到约 500 名该应用用户的电子邮件地址。
“当我们在 Lovable 的官方账号回复中指出这一问题后，该公司先是否认存在漏洞，随后删除了相关推文和网站。不久后，Linkable 重新上线并开始收取 2 美元费用。”Palmer 表示。
他发现，原因在于 Supabase 数据库配置不正确。Palmer 在 X 上发帖向 Lovable 联合创始人兼 CEO Anton Osika 发出通知，但对方却回应称并没有问题。
第二天，Palmer 和他的同事 Kody Low 进行了更深入的分析，总计发现 170 个存在漏洞的 Lovable 网站。他们向 Lovable 通报了该漏洞。Lovable 方面确认收到了，但未回邮件。
随后，他们在 4 月 14 日正式披露了漏洞情况，并启动为期 45 天的披露窗口期。
4 月 15 日，另一位软件工程师 Danial Asaria 也发现了 Lovable 的这一漏洞，并在 X 平台上发帖提醒开发者们：谨慎选择愿意托付个人数据的氛围编码平台。
据称，他“黑入”了 Lovable 推荐页面上的多个网站，并在短短 47 分钟内就找到了大量个人债务金额、家庭住址、API 密钥以及“擦边提示词”。而且，他强调自己“不是以黑客身份——而是以一个用 15 行 Python 代码的好奇开发者身份（发现的）”。
同日，Palmer 结合公开的漏洞利用情况再次通知 Lovable。
这之后，Lovable 就此事回应了外界质疑，宣布已实施一项新功能，并称“会在应用发布前扫描其中的安全问题”。4 月 24 日，Lovable 推出了“Lovable 2.0”，新增“安全扫描”功能。
然而，据 Palmer 称，其仍“未解决底层 RLS 架构缺陷”。
根据漏洞报告，这项安全扫描只会做一件事：确定 Supabase 数据库是否启用了访问控制。也就是说，Lovable 仍然回避了控制选项是否正确配置这个哪怕是经验丰富的软件开发人员也经常会出错的核心问题。
5 月 24 日，Palmer 对 Linkable 网站的漏洞状态进行了再次评估。结果，该网站仍存在数据操纵和注入等严重安全问题，也暴露出 Lovable 生态系统中系统性的 RLS 实施缺陷。
由于 Lovable 未采取有效修复措施或通知用户，他们在 5 月 29 日发布了该漏洞的 CVE 编号（CVE 全称是公共漏洞和暴露，是公开披露的网络安全漏洞列表）。
“氛围编码及类似范式应通过本质上提升安全性来赋能用户，而非催生漏洞或将安全责任完全转嫁给用户（甚至指责用户缺乏安全意识）。”Palmer 在发布 Lovable 的 CVE 编号后表示。
目前代码生成模型尚缺乏良好的全局观，无法详尽审视代码的最终使用方式。它们或许能够就具体问题提供相关指导，但缺乏经验的用户显然很难、甚至根本不知道该提出哪些问题。
例如，Lovable 宣称能使用 AI 模型即时创建网站。但要想实现大部分功能，网站还须接入存储用户账户及支付信息的数据库。Lovable 本身并不负责构建此类数据库，只是为用户提供一种便捷方式，允许他们接入一家名为 Supabase 的初创公司运营的数据库服务。
网络安全公司 SentinelOne 的首席信息安全官 Alex Stamos 表示，Web 应用程序的最佳实践要求完全避免让用户访问数据库。相反，应用程序应当确定用户可以访问哪些信息，再据此执行数据交付。从这个意义上讲，这有点像是快递员把包裹送到用户家中，而不是让他们一股脑涌进快递中转站。
然而，具体实现方法往往非常复杂。Stamos 表示，在担任 Facebook 公司首席安全官期间，计算资源的最大消耗就集中在访问控制上——即确定用户可以看到哪些数据，再据此向他们交付相关内容。
在他看来，允许用户直接接入数据库显然有着巨大风险。“虽然也有正确处理之道，但往往成功率极低。”
Lovable 在一则 4 月的 X 讨论帖中告诉用户，使用他们服务构建的网站“几乎都能保证安全”。但该公司也承认，如果配置不当，使用 Supabase 可能导致数据泄露。对于敏感数据，Lovable 建议进行“人工安全审查”，意味着使用氛围编码的客户自己也需要承担一定责任。
有外媒报道称，Lovable 最大的问题并不在于安全漏洞本身，而在于他们与客户间的沟通方式。该公司承诺用户可以安全使用其服务创建各类应用，但同时又把保护应用安全的责任推卸给了客户。
但作为一家氛围编码公司，Lovable 这种明确承认自己无力负责所创建应用安全的态度，倒也有一定合理性。毕竟自 Web 诞生以来，安全、隐私及各类问题的责任就一直是由在线服务的所有者来承担，而非由用于创建这些在线服务的工具承担。
5 月 30 日，Lovable 在 X 上公开回应道，“与几个月前相比，Lovable 现在在构建安全应用方面有了显著提升，并且还在快速改进。话虽如此，我们的安全水平尚未达到预期，我们将致力于持续提升所有 Lovable 用户的安全状况。”
也许氛围编码该被视为一种新的软件类别，而不只是一种软件创建工具。支持氛围编码的应用程序，则应当由此建立起沙箱、限制其可能造成的损害。这虽然会限制应用程序的功能，但也会明确责任边界。如果用户将应用程序置于沙箱之外、决定将其转化为商业用途，那么自然需要承担相应后果。
据了解，Replit 公司目前就在探索这种沙箱方法，而这应该也是他们明确抨击 Lovable、反复重申安全问题的根本动机之一。
Replit 公司 CEO Amjad Masad 在一份声明中指出，“氛围编码在软件开发的大众化普及方面做出了巨大贡献。我们不可能指望新手开发者理解并玩转底层安全配置。但如果一款工具号称能轻松部署应用程序，那它也应该有能力防止敏感数据意外泄露。”
值得一提的是，在 Masad 批评 Lovable 的问题时，Lovable 创始人 Anton Osika 则对其进行了反击回应：
1. 出任 Replit 公司创始人；
2. 领先十年；
3. 眼睁睁看着被来自欧盟的后起竞争对手 Lovable 在使用率和氛围编码安全保障方面全面超越；
4. 四周之后抄袭对方功能；
5. 抨击 Lovable 不够安全。
近期，各项 AI 辅助开发的技术进步不仅实现了编程民主化，还降低了复杂开发工具的使用门槛。如今，编码代理可实现数据库搭建、用户授权等服务——这些任务曾需专业开发者耗时数日甚至数周才能完成。
然而，若缺乏强默认安全设置、防护机制，甚至未采用客户端 / 服务器分离等更深度防御的架构模式，这类解决方案可能大规模滋生安全漏洞。不熟悉 Web 开发最佳实践的用户，会在“氛围编码”中不经意间开发出危及自身及用户的应用。
在 X 和 Reddit 上，有不少氛围编码用户们发布了自己开发应用程序之后，因为缺乏安全知识而迅速遭到黑客攻击的帖子。一位氛围编码用户在今年 3 月发帖称，“朋友们，我被黑了……大家都知道，我不是技术出身，所以我花了好长时间才搞清楚到底是怎么回事。”
“这也是当前氛围编码面临的最大挑战，业余人士开发的产品远不够安全。”专注于新型 AI 工具的资深软件开发者兼企业家 Simon Willison 表示，随着第一批氛围编码消费产品即将上市，这个问题可能即将全面爆发。“我们即将迎来一波猛烈的冲击。”
在 20 世纪 90 年代中期，当时消费级 Web 应用尚属于新兴事物，黑客就经常利用如今看来颇为简陋的技术来利用安全体系中的漏洞。随着时间推移，基本安全措施变得司空见惯，黑客们也不得不提升自己的技能水平。如今，黑客通常能得到国家的资助，使用自动化工具扫描互联网、寻找唾手可得的攻击目标——既包括那些尚未修复已知漏洞的计算机，也包括在多个网站上使用相同密码的用户。
随着氛围编码的兴起，应用程序和网站的安全标准再次有所松动，一切似乎又回到了上世纪 90 年代的 Web 青涩期。与此同时，黑客们则使用更先进的工具窥探着攫取利益的机会。
Stamos 指出，“在 90 年代，攻击者和防御者会一同成长。但如今，氛围编码用户面对的则是一群经验老到、甚至有国家支持的专业黑客。”
安全公司 Semgrep 的 CEO Iassac Evans 则表示，这个问题给那些开发自动化氛围编码应用安全层的厂商创造了机会，如 Semgrep 提供一项软件系统漏洞识别服务。Evans 指出，从某种角度上讲，像 Semgrep 这样的工具有望成为氛围编码流程中的重要组成部分。
“也可以说，现在正是安全行业的黄金时代。”
这或许就是 Osika 在 X 上专门发布这样表情图的原因之一：照片中两个男子把砖砌得歪歪扭扭，配的文字则是“继续用氛围编码吧，我们后续将随时修复”。
可以说，氛围编码趋势的兴起，无疑引发了新的担忧：在这个开发者即使没有任何安全知识也能创造出消费级产品的时代，该由谁来保障消费者产品安全？哪怕 AI 编写的代码本身完美无瑕，基于氛围编码的软件仍可能因其实现方式而引发重大安全漏洞。
与此同时，这里也要给氛围编码用户们提个醒：你们创建的内容很可能充满安全漏洞，贸然发布到网络上必然会成为巨大的隐患。
参考链接：
https://www.semafor.com/article/05/29/2025/the-hottest-new-vibe-coding-startup-lovable-is-a-sitting-duck-for-hackers
https://mattpalmer.io/posts/statement-on-CVE-2025-48757/
声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。
6 月 27～28 日的 AICon 北京站将继续聚焦 AI 技术的前沿突破与产业落地，围绕 AI Agent 构建、多模态应用、大模型推理性能优化、数据智能实践、AI 产品创新等热门议题，深入探讨技术与应用融合的最新趋势。欢迎持续关注，和我们一起探索 AI 应用的无限可能！
你也「在看」吗？👇