AI found 300 WordPress plugin zero-days in 72 hours. I build plugins. Here’s what changed for me.

AI 在 72 小时内发现了 300 个 WordPress 插件零日漏洞。作为插件开发者，我的应对之道。

Before I released my own AI chatbot plugin, I ran it through a security review. It came back with 35 bugs, three of them critical, and the one that made my stomach drop was an HTML injection coming straight out of unsanitized model output. At the time, that felt like my low point as a developer. Then I read this year’s ecosystem numbers, and 35 started to look quaint. 在我发布自己的 AI 聊天机器人插件之前，我对其进行了安全审查。结果显示有 35 个漏洞，其中 3 个是严重漏洞，最让我心惊肉跳的是一个直接源自未经清理的模型输出的 HTML 注入漏洞。当时，我觉得这是我作为开发者的低谷。然而，当我读到今年整个生态系统的数据时，那 35 个漏洞看起来反而显得微不足道了。

The numbers got loud in 2026. A pipeline built by security researchers, reported by Help Net Security, paired AI static analysis with automated verification and surfaced more than 300 critical zero-days across the WordPress plugin ecosystem in about 72 hours of scanning, with every finding manually verified before disclosure. Patchstack’s 2026 report puts a name on one of the causes: vibe coding, where developers ship LLM-generated plugin code they can’t actually audit. One agency reported finding 100 distinct security issues in a single vibe-coded plugin. 2026 年的数据令人震惊。据 Help Net Security 报道，安全研究人员构建的一套流程将 AI 静态分析与自动化验证相结合，在约 72 小时的扫描中，在 WordPress 插件生态系统中发现了 300 多个严重零日漏洞，且每个发现都在披露前经过了人工验证。Patchstack 的 2026 年报告为其中一个原因命名为“氛围编程”（vibe coding），即开发者发布了他们根本无法审计的 LLM 生成的插件代码。一家机构报告称，在一个“氛围编程”生成的插件中发现了 100 个不同的安全问题。

AI moved both sides of the board at once. It writes plugins fast, and while it’s writing it skips the boring security parts: escaping, capability checks, nonce validation. Then it finds those exact holes fast, including on the attacker’s side. The two things that used to protect a small plugin, obscurity and time, are both gone. Patchstack measured the weighted-median time from public disclosure to mass exploitation at roughly five hours. The standard advice, keep your plugins updated, assumes you have a window to react. Five hours is not a window. AI 同时推动了棋盘的两端。它编写插件的速度很快，但在编写过程中却跳过了枯燥的安全环节：转义、权限检查、Nonce 验证。随后，它又能迅速发现这些漏洞，包括攻击者也在利用这一点。曾经保护小型插件的两大屏障——“默默无闻”和“时间差”——如今已荡然无存。Patchstack 测得从公开披露到大规模利用的加权中位数时间约为 5 小时。传统的建议是“保持插件更新”，但这假设你有反应的时间窗口。5 小时根本算不上什么窗口期。

Why my own plugin had those 35 bugs: This is the part I think solo authors underrate, and it’s the same thing that bit me. AI-written code gets trusted twice. Once because the AI wrote it, so it’s probably fine. And again inside the code, where model output gets treated as safe and processed without a check. Both of those trusts were wrong in my codebase. My output-side HTML injection was that double-trust made concrete. I rendered the model’s response straight into the page as HTML because I had quietly assumed that since the model generated it, it was clean. It wasn’t. Model output carries other people’s content inside it: whatever the user typed, whatever a retrieval step pulled off an external page. Treat that as safe and no amount of input-side guarding saves you. It leaks on the way out. 为什么我自己的插件会有那 35 个漏洞？我认为这是独立开发者容易低估的地方，也是我栽跟头的原因。AI 编写的代码被赋予了双重信任：首先是因为 AI 写的，所以大概没问题；其次是在代码内部，模型输出被视为安全并未经检查就直接处理。在我的代码库中，这两种信任都是错误的。我的输出端 HTML 注入就是这种双重信任的具体体现。我将模型的响应直接作为 HTML 渲染到页面上，因为我默认模型生成的内容是干净的。事实并非如此。模型输出中携带了其他人的内容：用户输入的任何信息，或者检索步骤从外部页面抓取的任何数据。如果将其视为安全，那么无论你在输入端做多少防护都无济于事，因为它会在输出时泄露。

What I actually changed as a one-person shop: I stopped treating “it runs” as “it’s safe.” I now read every AI-written handler by hand in three places: input, output, and permissions. On output, I treat the model’s response as untrusted input and neutralize it for wherever it’s going. Escape for HTML, allowlist for Markdown, validate any URL before fetching it. In WordPress terms that’s the unglamorous stuff the model loves to skip: esc_html, wp_kses with a tight allowlist, current_user_can and a nonce check at every AJAX and REST entry point, $wpdb->prepare on every write. None of it is new. It’s the web security we’ve always done, pointed at the half of the code I didn’t write myself. 作为一名独立开发者，我做出了哪些改变？我不再把“能运行”等同于“安全”。现在，我会手动检查每一段 AI 编写的处理程序，重点关注三个方面：输入、输出和权限。在输出端，我将模型的响应视为不可信输入，并根据其去向进行中和处理。例如：对 HTML 进行转义，对 Markdown 使用白名单，在获取任何 URL 前进行验证。用 WordPress 的术语来说，这就是模型喜欢跳过的那些枯燥工作：使用 esc_html，使用带有严格白名单的 wp_kses，在每个 AJAX 和 REST 入口点进行 current_user_can 和 Nonce 检查，以及在每次写入时使用 $wpdb->prepare。这些都不是什么新鲜事，这就是我们一直以来所做的 Web 安全工作，只不过现在针对的是那些并非由我亲手编写的代码。

And the surface keeps growing. WordPress 7.0’s Abilities API lets plugins expose actions to AI agents in a standard way, which is useful and is also a fresh place for under-scoped permissions to leak. That one I’m watching closely, because a plugin that hands an agent more power than it should is the next version of this same mistake. 攻击面还在不断扩大。WordPress 7.0 的 Abilities API 允许插件以标准方式向 AI 代理公开操作，这虽然有用，但也成为了权限范围界定不足导致泄露的新温床。我正在密切关注这一点，因为如果一个插件赋予了代理超出其应有权限的能力，那将是重蹈覆辙的下一个版本。

The uncomfortable part isn’t the code: Here’s where I think the 2026 conversation is actually pointing, and it’s not a code problem. Patchstack found that 52 percent of plugin developers don’t ship a patch before the vulnerability goes public, and that 46 percent of disclosed vulnerabilities had no fix available at all at the moment of disclosure. So finding bugs is no longer the bottleneck. AI does that in seconds. The bottleneck is everything after. Most plugins are free, maintained by one person between paying jobs, and a plugin earning zero revenue can’t justify the cost of a fast security patch. The ecosystem’s failure mode in 2026 isn’t that bugs are hard to find. It’s that the people who would fix them aren’t paid to. AI didn’t create that gap. It just made it visible at scale and handed attackers a five-hour head start. That reframes what “responsible” means for someone like me. Writing more carefully is necessary and nowhere near sufficient, because careful or not, the holes I miss are now findable in seconds by someone who isn’t on my side. 令人不安的不是代码本身：我认为 2026 年的讨论核心并不在于代码问题。Patchstack 发现，52% 的插件开发者在漏洞公开前没有发布补丁，46% 的已披露漏洞在披露时根本没有修复方案。因此，发现漏洞已不再是瓶颈，AI 几秒钟就能搞定。真正的瓶颈在于后续的一切。大多数插件是免费的，由开发者在工作之余维护，而一个零收入的插件无法支撑快速安全补丁的成本。2026 年生态系统的失败模式不在于漏洞难找，而在于负责修复的人没有获得报酬。AI 并没有制造这种差距，它只是将其大规模地暴露出来，并给了攻击者 5 小时的领先优势。这重新定义了像我这样的人何为“负责任”。写代码更谨慎是必要的，但远远不够，因为无论是否谨慎，我遗漏的漏洞现在都能被那些心怀不轨的人在几秒钟内发现。

The deadline nobody’s talking about enough: There’s a clock on this too. By September 2026, plugin and theme developers distributing to EU users are required by law to have a vulnerability disclosure program. For a solo author that sounds like overhead, but it’s the one structural fix that matches the threat: a real channel for someone to report the bug AI found, quietly, before it becomes a public CVE with a five-hour timer attached. Standing one up doesn’t have to be heavy. For a solo author, the minimal version is a security contact in the plugin readme or a SECURITY file, a place for reports to land that isn’t the public issue tracker, and a stated response window so the reporter knows the message won’t sit unread. The point isn’t ceremony. It’s that the person who finds the bug has somewhere to send it before it turns into a public CVE with a five-hour timer attached. 一个被忽视的最后期限：这背后还有一个时间限制。到 2026 年 9 月，向欧盟用户分发插件和主题的开发者在法律上必须建立漏洞披露计划。对于独立开发者来说，这听起来像是额外的负担，但这是应对威胁的唯一结构性修复方案：提供一个真正的渠道，让人们在 AI 发现的漏洞变成带有 5 小时倒计时的公开 CVE 之前，能够私下报告。建立这个渠道并不复杂。对于独立开发者，最简版本是在插件的 README 或 SECURITY 文件中提供一个安全联系方式，一个非公开的问题追踪器，并声明响应时间窗口，让报告者知道他们的反馈不会石沉大海。重点不在于形式，而在于让发现漏洞的人在漏洞变成带有 5 小时倒计时的公开 CVE 之前，有一个可以发送报告的地方。

A note to my next self: The 35 bugs taught me to distrust the code I didn’t write. This year taught me the rest of it. The window to fix what I miss is shorter than it has ever been, and obscurity was never protecting me in the first place. If you ship plugins, AI-assisted or not, the move isn’t to write more carefully and hope. It’s to assume the holes are already findable in seconds, and to build the parts that catch them first: the hand review of input, output, and permissions, the output sanitization, and a disclosure channel that lets a friendly stranger reach you before an unfriendly one does. 给未来的自己：那 35 个漏洞教会了我不要信任非我所写的代码。今年则教会了我剩下的部分。修复遗漏漏洞的时间窗口比以往任何时候都短，而“默默无闻”从来都不是我的保护伞。如果你发布插件，无论是否由 AI 辅助，仅仅写得更谨慎并祈祷是不够的。你应该假设漏洞在几秒钟内就会被发现，并预先构建防御机制：手动审查输入、输出和权限，进行输出清理，并建立一个披露渠道，让友好的陌生人能在恶意攻击者之前联系到你。

Sources: Patchstack’s 2026 State of WordPress Security report (vibe coding, the five-hour mass-exploitation median, the…) 来源：Patchstack 2026 年 WordPress 安全状况报告（氛围编程、5 小时大规模利用中位数等）