AI 在 72 小时内发现了 300 个 WordPress 插件漏洞
AI 发现漏洞的速度很快，编写代码的速度也很快。这为插件开发者制造了一个危险的缺口。
安全研究人员利用 AI 在 WordPress 生态系统中发现了超过 300 个严重的零日漏洞。他们仅用了 72 小时就完成了这项工作。
问题在于“氛围编程”（vibe coding）。当开发者发布由 LLM 生成但他们无法审计的代码时，就会发生这种情况。其中一个插件因此产生了 100 个独立的安全性问题。
AI 抹去了你以往的两层保护：时间和隐蔽性。
攻击者现在使用 AI 来寻找漏洞，而开发者使用 AI 来编写代码。代码往往会跳过如下安全步骤：
- 数据转义 (Escaping data)
- 权限检查 (Capability checks)
- Nonce 验证 (Nonce validation)
从漏洞报告公开到被大规模利用的时间现在缩短到了 5 小时。这根本不是一个可以反应的窗口期，而是一场你注定会输的竞赛。
我是以惨痛的教训学到这一点的。我曾开发过一个 AI 聊天机器人插件。一次安全审查在我的代码中发现了 35 个漏洞，其中一个是 HTML 注入。
我犯了一个错误：我信任了 AI 的输出。我以为既然是模型生成的文本，它就是安全的。事实并非如此。模型的输出包含来自用户和外部网站的数据，你必须将其视为不可信的内容。
我改变了工作流程。我不再仅仅因为代码能运行就认为它是安全的。我会手动审查 AI 编写的每一个部分，重点关注以下三个领域：
- 输入：数据如何进入系统。
- 输出：数据如何离开系统。
- 权限：谁可以执行该操作。
在输出方面，我现在会使用 esc_html 和 wp_kses 等函数。对于每一次数据库写入，我都会使用 $wpdb->prepare。在每一个入口点，我都会使用 current_user_can 来检查权限。
真正的危机不仅在于漏洞本身，更在于响应时间。
- 52% 的开发者在漏洞公开前无法发布补丁。
- 46% 已披露的漏洞完全没有可用的修复方案。
大多数开发者是独立作者。他们并没有因为快速修复漏洞而获得报酬。AI 让这一差距变得显而易见。
如果你发布插件，不要只是小心编写并寄希望于运气。要假设攻击者会在几秒钟内发现你的漏洞。
构建以下防御措施：
- 手动审查所有输入、输出和权限。
- 对所有模型响应进行清洗 (Sanitize)。
- 创建一种让人们可以私下向你报告漏洞的方式。
在你的 readme 中添加一个简单的安全联系方式只是第一步。在漏洞变成公开威胁之前，你需要一个接收报告的渠道。