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.
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.
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.
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.
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.
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.
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.
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.
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.
Sources: Patchstack's 2026 State of WordPress Security report (vibe coding, the 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. Please confirm the latest figures against the primary reports before publishing.
Disclaimer: The experiences and decisions in this post are my own. English isn't my first language, so I use an AI assistant to help draft and edit the writing.
Top comments (8)
Double trust is exactly the right name for it. We've all drilled input sanitization, but model output gets a free pass because the model "wrote" it, when really it's carrying whatever the user typed or whatever a retrieval step scraped off some page. Treating the model's response as just another untrusted user typing into your app is the cleanest way I've seen to put it, and it travels well past WordPress, into every chatbot and RAG feature that renders text straight to the page. The output side is the one that bites, because escaping on the way out feels paranoid right up until the day it isn't.
"Escaping on the way out feels paranoid right up until the day it isn't" is the whole thing. And the reason it feels paranoid for so long is the part that makes the output side so dangerous: it stays invisible until the day it fires. An input-side hole usually breaks something, so you notice. An unescaped model response renders perfectly every single time, looking completely normal, until the one input that carries a payload. That's exactly the bug that survives a review, because "it works" and "it's safe" look identical right up to that day. You nailed the generalization too. The moment a feature renders model text straight to the page, WordPress or not, every chatbot and RAG surface inherits the same thing: the model's output is just another untrusted user, and the only question is whether you treated it like one before or after the day it stops looking paranoid.
The part that reframes this for me is that even your economic point understates it — faster patching isn't the binding constraint, propagation is. The same pipeline that finds the bug can pull every version off the plugin's public SVN, diff it, and read live install counts straight off the wordpress.org API, so attacker targeting is basically free and the "five hours" is mostly scan-and-spray time, not effort. The defender side has a second clock nobody mentions though: even a maintainer who patches within the hour is then at the mercy of how fast that patch actually reaches installs, and plugin auto-updates are opt-in per site and most people never flip them on. So a fixed bug and an exploited bug happily coexist for weeks, which is why the only lever that really compresses the defender side to match the attacker's window is security-only auto-updates being on by default the way core minor updates already are — careful coding protects you, but it does nothing for the long tail of sites still running the vulnerable version after you've shipped the fix.
You're right, and this is the sharper version of my point. I framed it as "who's left to fix it," but propagation is the constraint that actually bites, and the asymmetry is worse than I wrote. Attacker targeting really is close to free: public SVN gives every version to diff, and the wordpress.org API hands over live install counts, so the five hours is scan-and-spray time, not effort. Meanwhile a maintainer who patches inside the hour still waits on a delivery path they don't control, and with auto-updates opt-in per site, a fixed bug and an exploited bug coexist for weeks. Careful coding does nothing for that long tail. Fully agree the real lever is security-only auto-updates on by default, the way core minor updates already are.
The one thing I'd add ties back to the trust theme: speeding up propagation also makes the delivery path itself the new high-value target. The moment security auto-updates are on by default everywhere, that channel becomes the fastest way to push code to every install in hours, which is great for patches and catastrophic if the supply side is what gets compromised. I've written before about wordpress.org now holding even my own commits for review, and this is the other face of that: the same default-on pipe that finally matches the attacker's window is also a single path that, subverted, ships the exploit at patch speed. So I'm fully for default-on security updates, as long as we treat the propagation channel as the next thing that has to earn trust, not assume it because it's the official one.
It's great to see more developers taking security seriously before release—especially in the WordPress ecosystem where vulnerabilities can spread fast. I've worked on automated analysis tools for GPU-accelerated security scans, and the key takeaway is always the same: shifting security left saves time and trust. Kudos for catching those issues early.
This feels like the right lesson: the problem is not using AI to build plugins, it is skipping the review because the code “looks right.”
For WordPress especially, the boring parts are the security parts. esc_html, wp_kses, nonces, capability checks, prepared queries; none of it is exciting, but that is usually where the real damage happens.
Yeah, "looks right" is the whole trap. The worst one in my 11-round review
was an HTML injection where the unsanitized path was the model's own output,
echoed straight onto the page. AI-written code that failed to sanitize
AI-generated content. You trust the code, and the code trusts the model.
A wp_kses on the output would have caught it, but nothing looked wrong
because the happy path was always clean. It only breaks when the model
hands back something you didn't plan for.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.