The 2026 WordPress security math flipped, and I build plugins for a living
AI can surface 300 plugin zero-days in 72 hours, and the window from disclosure to mass exploitation is now about five hours. The scariest part isn't finding the bugs. It's who's left to fix them.
Before I shipped my own AI chatbot plugin, I put 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 flowing straight out of unsanitized model output. For a while that was my personal low point. Then I sat with this year's ecosystem data, and 35 started to feel small.
Both sides of the board got faster at once
Security researchers, in work reported by Help Net Security, wired AI static analysis to automated verification and turned up more than 300 critical zero-days across the WordPress plugin ecosystem in roughly 72 hours of scanning, each one checked by hand before disclosure. Patchstack's 2026 report names one of the drivers directly: vibe coding, where a developer ships LLM-written plugin code they can't actually read closely enough to audit. In one case an agency pulled 100 separate security issues out of a single vibe-coded plugin.
The uncomfortable symmetry is that the same technology sits on both sides. AI writes the plugin quickly, and as it writes it quietly drops the unglamorous safety work: escaping, capability checks, nonce validation. Then AI finds those exact gaps quickly, attackers included. The two things that used to keep a small plugin safe, being obscure and having time, are both gone. Patchstack put the weighted-median gap between public disclosure and mass exploitation at around five hours. "Keep your plugins updated" assumes you get a chance to react. Five hours is not a chance.
Where my own 35 bugs came from
This is the part I think solo authors discount, and it is exactly what caught me. Code an AI writes gets trusted twice over. First because an AI produced it, so it must be roughly right. Then a second time inside the code itself, where the model's output is handled as if it were safe and passed along without a check. Both of those assumptions were false in my plugin.
The output-side HTML injection was that second trust made visible. I was dropping the model's reply into the page as HTML because I had decided, without ever saying it out loud, that model-generated text was clean. It is not. What the model returns is a blend of other people's content: whatever a user typed, whatever a retrieval step scraped off some page. Mark that blend as safe and your input-side defenses never get a vote. It escapes on the way out.
What a one-person shop can actually do
The first change was a mindset one. I stopped reading "it runs" as "it is safe." Now I read every AI-written handler by hand, and I read it in three specific places: input, output, and permissions.
On the output, I treat the model's reply as untrusted input and neutralize it for wherever it lands. Escape it for HTML, run Markdown through an allowlist, validate any URL before fetching it. In WordPress that is the plain, boring work the model skips: esc_html, wp_kses against a tight allowlist, a current_user_can and nonce check on every AJAX and REST entry point, $wpdb->prepare on every write. There is nothing clever in that list. It is the ordinary web security we have always done, aimed at the half of the codebase I did not write myself.
The surface is still widening, too. WordPress 7.0's Abilities API gives plugins a standard way to expose actions to AI agents. That is genuinely useful, and it is also a brand new spot for under-scoped permissions to leak out. I am watching that one closely, because a plugin that grants an agent more authority than it needs is just the next version of the same mistake I already made.
The real bottleneck is economic, not technical
Here is where I think the 2026 picture actually points, and it is not a coding problem. Patchstack found that 52 percent of plugin developers do not ship a fix before the vulnerability goes public, and that 46 percent of disclosed vulnerabilities had no patch available at the moment of disclosure.
So finding the bug stopped being the hard part. AI does that in seconds. The hard part is everything downstream. Most plugins are free, kept alive by one person in the gaps between paying work, and a plugin earning nothing cannot justify the real cost of a fast security patch. The failure mode of the ecosystem in 2026 is not that bugs are hard to find. It is that the people positioned to fix them are not paid to. AI did not invent that gap. It exposed it at scale and gave attackers a five-hour head start through it.
That changes what "responsible" has to mean for someone in my position. Writing more carefully is necessary and nowhere close to enough, because careful or not, the holes I miss are now discoverable in seconds by someone who is not on my side.
The deadline hiding in this: VDPs by September
There is a clock attached as well. From September 2026, plugin and theme developers distributing to users in the EU are required by law to run a vulnerability disclosure program. To a solo author that reads like pure overhead, but it happens to be the one structural fix that fits the threat: a real channel where a finder can quietly hand you the bug before it becomes a public CVE with that five-hour timer running.
Standing one up does not 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 is not the public issue tracker, and a stated response window so the reporter knows the message will not sit unread. The point is not ceremony. It is that the person who finds the bug has somewhere to send it first.
What I'm carrying forward
The 35 bugs taught me to distrust the code I did not write. This year taught me the rest of it. The window to fix what I miss is the shortest it has ever been, and obscurity was never the thing keeping me safe.
If you ship plugins, AI-assisted or not, the move is not to write more carefully and hope. It is 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.
Sources: Patchstack's 2026 State of WordPress Security report (vibe coding, the roughly five-hour mass-exploitation median, the 52% and 46% patch figures, and the EU disclosure-program requirement). The 300-plus zero-days in 72 hours pipeline was reported by Help Net Security. The single-plugin "100 issues" figure and the WordPress 7.0 Abilities API note come from hosting.com's 2026 plugin-security writeup. Confirm the latest figures against the primary reports before publishing.
