安全研究人员发现，由大语言模型（LLM）生成的代码存在重大漏洞。研究表明，借助人工智能助手进行 “氛围式编码”（vibe coding，指依赖 AI 生成代码时侧重实现效果、忽视底层安全逻辑的编码方式），可能会给生产环境中的应用程序引入严重安全缺陷。 一项新研究指出，LLM 生成的代码往往优先考虑功能实现而非安全性，由此产生的攻击向量，只需通过简单的 curl 命令即可利用。

核心要点

1. LLM 生成的代码会继承不安全的代码模式，为实现功能而牺牲安全性。
2. 暴露的端点（endpoint）使得攻击者可通过简单的 curl 命令轻松发起攻击。
3. 人为监督（包括威胁建模、代码审查和安全扫描）至关重要。

不安全的训练数据

希曼舒・阿南德（Himanshu Anand）指出，根本问题在于 LLM 的训练数据源自互联网爬取，而这些数据中的大多数代码示例仅以演示功能为目的，并未遵循安全最佳实践。 当开发人员过度依赖 AI 生成的代码，且未进行充分的安全审查时，这些不安全的代码模式会大规模渗透到生产系统中。 研究显示，LLM 无法理解业务风险，也缺乏进行合理威胁建模所需的上下文感知能力。 其训练数据中天然包含大量来自在线教程、Stack Overflow 问答和文档示例的易受攻击代码模式 —— 这些代码模式均以快速实现功能为首要目标，而非采用安全的设计思路。 一个尤为值得警惕的案例是：某款部署在 Railway [.] com 平台上的 JavaScript 应用，其整个邮件 API 架构均暴露在客户端。该易受攻击的代码包含以下问题（原文未列出具体代码，此处为案例背景说明）：

概念验证（PoC）攻击

该研究包含一项概念验证攻击，展示了暴露的客户端 API 如何被利用：

这一简单命令（原文未列出具体命令，此处为攻击原理说明）揭示了三个关键攻击向量：

• 针对任意邮箱地址的垃圾邮件攻击
• 利用逼真的机构名义信息冒充客户
• 通过伪造可信发件人地址滥用内部系统

该漏洞使攻击者能够完全绕过预期的 Web 界面，在无需身份验证、不受频率限制的情况下，直接向后端服务发送无限量请求。 研究强调，尽管 LLM 可作为强大的编码助手，但在安全层面仍需人工监督。 企业不应将 AI 生成的代码直接部署到生产环境，而必须实施规范的威胁建模、安全审查和纵深防御策略。 安全团队应重点制定安全编码指南，对 LLM 生成的代码实施自动化安全扫描，并在安全审查流程中保留人工专业判断环节 —— 以防止这类漏洞被系统性地引入系统。