The plugin works. Someone asked for a booking form that takes a deposit and sends a confirmation, an assistant wrote a few hundred lines of PHP against the hooks it knows, and the form took a test payment before lunch. I have shipped code this way myself.
The bill arrives around day four hundred, when a vulnerability in that plugin becomes public and the file is sitting on a production server that has no maintainer, no update channel, and nobody who reads the code well enough to change a line without breaking checkout.
- Day one
- the code runs
- Day four hundred
- the advisory is published
- The gap
- nobody owns the file
The day-one test is the easy one
Veracode ran a large batch of models through completion tasks written to bait known weaknesses for its 2025 GenAI Code Security Report, and close to half the samples came back carrying an OWASP Top 10 flaw. The March 2026 rerun over a wider set of models moved the syntax numbers and left the security ones where they were. The code compiles more reliably every year and is no safer.
Read the scope before spending that figure. The tasks are curated for Java, Python, C# and JavaScript, with no PHP, no WordPress and no human baseline to measure against. Veracode sells the scanner too. It is a per-task failure rate on a benchmark your plugins sit outside.
The only catalog that traces bugs to AI code
The Vibe Security Radar dashboard run at Georgia Tech had logged a couple of hundred AI-contributed vulnerabilities by its late-August 2026 cutoff, and its busiest month was the one just before. Set beside a full year of published CVEs, counted in the CVE data review Jerry Gamblin published in January 2026, the entire catalog rounds to nothing.
What the radar counts, and what it leaves out
The entries are GHSA and CVE advisories across public open-source repositories in every language, none of them a WordPress plugin. The maintainers call the index an observed public set, and the repository calls the count a lower bound. May and June 2026 came in below April, so the count climbs across the year without climbing every month.
That is the floor for everything below. No dataset attributes a single WordPress plugin vulnerability to AI authorship, because nobody records who or what wrote the code. What follows is an argument about mechanism.
I have already written about what generated code looks like at the moment it is written. This post is about the years after: the standing promise to patch something for as long as it stays installed.
The clock a plugin has to survive
Patchstack logged a little over eleven thousand new WordPress vulnerabilities in 2025, around 40% more than the year before, and nine in ten of them sat in plugins. Core accounted for six, all filed as low priority by the State of WordPress Security in 2026 report, which is roughly where core has sat for years. Some of that jump is one vendor adding researchers and CNA capacity rather than the web getting suddenly worse.
Themes doubled their share off that longer list. Plugins stayed where the overwhelming majority get found, which is exactly where anything you generate is going to live.
Volume is the dull half. The clock is the half that decides whether a plugin needs an owner. Patchstack runs the firewall that produced the next number, and the median is weighted by attack intensity, so a handful of mass-exploited bugs carry it. For the vulnerabilities attackers hit hardest, it measured a weighted median of five hours between public disclosure and the first exploitation attempt it saw, and roughly half of high-impact flaws were under attack inside 24 hours. Five hours is shorter than any maintenance schedule I have ever seen a client agree to pay for.
The class Patchstack labels highly exploitable rose 113% year on year, though that label forecasts mass exploitation and records none of it: the tier covers bugs merely expected to be hit at scale. The quieter figure hurts more: 46% of the vulnerabilities disclosed in 2025 got no fix from the developer in time for public disclosure.
Half the time the fix does not exist on the day the hole is published. Every plugin in that half already has a maintainer.
The cost of finding them collapsed in the same period. Researchers from TrendAI and CHT Security told Help Net Security that a pipeline they built in three days surfaced more than 300 critical zero-day vulnerabilities across existing WordPress plugins in 72 hours, at roughly $20 of tokens per vulnerability found. Those are ordinary human-written directory plugins, so what got cheap here is finding a bug in code that already exists.
Plugins with owners break too
An owner prevents none of this by itself. The plugins below all had one.
AI Engine, a plugin with more than 100,000 active installs, listed its MCP bearer token in the public REST index when the No-Auth URL option was enabled. Anyone could read the token and use it to create an administrator account: CVE-2025-11749, CVSS 9.8, fixed in 3.1.4 and disclosed in early November 2025. Jordy Meow shipped that fix and still maintains the plugin, which is the reason the example is here. Set it beside the MountDev AI MCP Connector, about a hundred active installs. It shipped an unauthenticated privilege-escalation flaw handing an attacker an administrator-bound OAuth token through a self-registered client, CVE-2026-15015, CVSS 9.8, in versions up to 1.6.1, and a second, lower-severity access-control bug followed six weeks later.
The Ninja Forms file-upload add-on had no file-type check in any version through 3.3.26. It was reported on 8 January 2026, partially patched in 3.3.25 on 10 February and fully patched in 3.3.27 on 19 March: seventy days from report to complete fix, from a vendor with a support desk and a release process. Disclosure landed on 7 April and, by the count BleepingComputer published, Wordfence blocked more than 3,600 attacks in 24 hours. Slow as that is, it ended in a version to install.
Patchstack found premium components carried three times more known exploited vulnerabilities than free ones. It also documented, in April 2026, more than 20 plugins by EssentialPlugin backdoored after the company was sold to a buyer on Flippa. The code went in during September 2025, sat dormant seven months, and was first used on 5 April 2026. A change of owner on WordPress.org triggers no fresh review, which is a separate question from who patches the file.
The other half of the cliff is a patch nobody applies
All-in-One WP Migration and Backup was patched in version 7.110 on 20 August 2026, closing CVE-2026-19949, CVSS 8.8, exploitable through an archive restore. Two weeks later, on 2 September, about 35% of its five-million-plus installs had updated, leaving roughly 3.25 million sites on a vulnerable release, and that is a floor. BleepingComputer reported the shortfall from the wordpress.org version statistics, which showed close to 40% of installs on 7.110 a week later.
That is the good case: a large vendor, a fast fix, automatic updates available to every install, and two thirds of the base still behind.
The pipeline itself grew a delay in the same year. Since a June 2026 announcement by Matt Mullenweg on WordPress News, every new plugin release waits up to 24 hours before WordPress.org distributes it through auto-updates. Patchstack measured the practical cost at about a full day for the first weeks, then a few hours once the system was tuned, and counted 81 security releases waiting in a single 17-day queue. Some of that window belongs to the distribution system.
A generated in-house plugin has none of that machinery, including the parts worth complaining about: nothing checks its version, so when the advisory lands the file stays as it is until a human opens it.
The volume behind all of this
That clock assumes an author is listening for it. Weekly plugin submissions to WordPress.org have gone up roughly fivefold since 2024, with a record week in May 2026, by the Plugins Team’s own count. WordPress.org has not gained five times as many PHP developers in that period. It has gained assistants that write plugins.
The same team published the number that measures the cliff before a plugin exists. Its review of 2025 reports that “38.7% of the plugins we reviewed received no reply from their authors”, at the one moment those authors still wanted the listing.
The silence carries on after a plugin is listed. Roughly 31,700 of about 68,000 directory plugins, close to 47%, have had no update in two or more years, by a September 2026 scan of the plugin directory published by WP.MD. That figure comes from one maintainer scanning a public API, and WordPress.org publishes nothing like it. No update means no release. Unlike themes, the directory keeps stale plugins listed and installable.
The people who read these submissions for a living report no quality collapse, and I will not pretend otherwise. That same review of 2025 states that AI has lowered the barriers to entry without compromising plugin quality, with approvals rising to 69.5% of reviewed plugins from 63.4% in 2024. I take that at face value. It describes the code at review time, and review ends long before the maintenance question arrives.
Who is holding the tool
A model answers the question it was asked, so the output tracks the ask at least as much as it tracks the model. Somebody who has spent years inside a WordPress codebase asks for the capability check and the nonce without being prompted, names the hook, says what should happen when the payment gateway times out, and says which of those matters most. That person can run a smaller model on a lower effort setting and get back something worth reviewing. Somebody whose entire picture of a plugin is the sentence they typed gets the sentence, built faithfully, with the form wired straight into the database.
None of that is a fact about AI. It was true when the tool was a search box and a folder of snippets, and the people who turned up because the field was busy rather than because they liked the work have always finished second. What changed is the floor. You used to have to get PHP past a parser before you could ship anything at all, so the worst code in circulation still came from someone who had actually written it. Now the same file can come from someone who has never had to reason about boolean logic, or about what a loop costs once the table holds fifty thousand rows. Put the two files side by side and there is not much in it.
The spread in quality did not get wider this year. It got legible. Bad work used to hide behind the effort it took to produce, and effort has stopped being a filter. I think that is a fair trade, on balance. A difference you can see is a difference somebody can check for, and it moves the burden onto whoever is meant to be doing the checking.
The cost lands on everybody selling
All that output has to go somewhere, and in this ecosystem it goes onto the same shelves as everything else. A listing looks like a listing: a title, a screenshot, a version number, a rating from a handful of buyers. Nothing on that page separates a plugin somebody has kept alive for six years from one that was generated on a Tuesday and forgotten by Friday. The maintained one starts to look overpriced, support inboxes fill with questions about somebody else’s code, and the studios still doing the work absorb the cost of the ones that are not.
The layer that is supposed to catch this is review, and review is the part that never scaled. From the vendor side of a marketplace, how much of the outcome depends on which reviewer opens your zip is its own long story.
The commercial half of the market meets the same flood from the other direction, as pressure on price rather than on the review queue.
I am not gloomy about where this ends, and none of it looks permanent to me. A directory that ran the checks a competent reviewer would run, on every submission, is ordinary engineering, and the same generation of tooling that produced the flood happens to be very good at that exact kind of reading. Until somebody builds it, the trail a maintainer leaves is public, cheap to read, and still the most honest thing on the page.
The economics of a plugin that cost nothing
The saving on a generated plugin is small and it lands on day one. It buys an obligation to own the file for as long as the site runs. The three ways that obligation gets met look alike from the outside.
| Maintained | Gone quiet | Generated | |
|---|---|---|---|
| Who writes the fix | A paid maintainer | Nobody at present | You, if you still can |
| How you hear about it | Changelog and update notice | A security feed, if you read one | Your host, after the fact |
| How the fix reaches the site | An update channel | A manual download, if one exists | A developer with server access |
| What the Plugins screen says | Update available | Up to date | Up to date |
The last row catches people. A plugin nobody maintains reports itself as current, because current only ever means matching the newest thing on offer. I wrote about that view of a site in the piece on taking over a WordPress site you did not build.
My own security checklist says outdated plugins are the most common way a site gets taken, and I stand by the ranking. The share is the part worth being honest about: in the last cleanup dataset Sucuri published, just under 40% of the infected installations were out of date when they were hit. Being current only means a fix exists to apply. That is the 2023 Hacked Website and Malware Threat Report, published June 2024, counting the customers Sucuri cleaned.
The problem cannot be pushed out to the perimeter either. In two hosting-environment penetration tests Patchstack ran during 2025, the usual defenses, internal firewalls and Cloudflare among them, blocked 12% of WordPress-specific vulnerability attacks and 26% of attacks overall. Patchstack ran those tests against targets it chose, so the figure describes two hosting environments. Twelve percent is not a substitute for someone applying the patch.
The price of a maintained plugin buys the trail behind it: dated changelog entries, an update channel, and someone who answers when the advisory names it.
What I do with generated code
I still generate plugins. The rule I hold to is that the moment one reaches a client site it is my code, with my name on the advisory.
- A security review before it touches production, by a person who reads PHP, assuming the assistant took the shortest path through the hooks.
- A named maintainer in the plugin header, with a date for the next look at it.
- A changelog from version one, even when the only reader is the version of me who opens this in two years.
- An inventory of what it pulled in. A vendored library is a plugin inside your plugin, with its own advisories.
- A decision, made now, about the day an advisory names something this file depends on.
One header line is worth the trouble on its own, and generators never write it:
/**
* Plugin Name: Booking Deposits
* Version: 1.4.2
* Requires PHP: 8.2
* Update URI: false
*/Setting the update URI to false tells WordPress never to accept an update for this folder name from the directory. It matters on the day somebody publishes a public plugin whose slug matches the one your assistant invented at four in the afternoon.
On the buying side the same trail is public, and you can check it before you spend anything.
- A changelog with dated entries under every version bump.
- An update channel that reaches the site, so a fix does not depend on anyone remembering to download a zip.
- A support address with a person behind it. Test it with a real question before you buy.
- A named author who is still visible somewhere other than the plugin page itself.
- A release inside the last few months, which for a directory plugin is the only public sign that anyone is still at the wheel.
That list is why my studio keeps licenses, updates, changelogs and support in one hub.
The same thinness shows up where security is not the issue at all. Accessibility is the other direction it runs in, and regulators are putting dates on that one.
Last updated
