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 more than a hundred models through 80 completion tasks written to expose known weaknesses for its 2025 GenAI Code Security Report, and 45% of the samples failed the security tests, introducing OWASP Top 10 flaws. The March 2026 rerun across more than 150 models came back flat, with syntax correctness now clearing 95% while the security pass rate has not moved.
Read the scope before spending that figure. The 80 tasks are curated to bait known weaknesses in Java, Python, C# and JavaScript, with no PHP, no WordPress and no human baseline to compare against. Veracode sells the scanner too. The 45% 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 held 262 AI-contributed vulnerabilities at its 26 August 2026 cutoff, with July 2026 the largest month at 54. Against the 48,185 CVEs published in 2025, counted in the CVE data review Jerry Gamblin published in January 2026, the whole catalog comes to roughly half a percent of one year of advisories.
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 recorded 11,334 new vulnerabilities across WordPress plugins, themes and core in 2025, up 42% on the 7,966 the same database recorded in 2024. 91% were in plugins and 9% in themes, and six were reported in core, which the State of WordPress Security in 2026 report calls low priority issues. Some of that increase is one vendor adding researchers and CNA capacity.
| Recorded by Patchstack | 2024 | 2025 |
|---|---|---|
| New vulnerabilities | 7,966 | 11,334 |
| Share found in plugins | 96% | 91% |
| Share found in themes | 4% | 9% |
| Reported in WordPress core | 7 | 6 |
Core has been quiet for years and is quiet still, while the theme share doubled off a longer list. Plugins remain where nine vulnerabilities in ten get found, which is 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 24 hours through mid-July 2026 and about 6.6 to 6.8 hours from 16 July, and counted 81 security releases sitting in one 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 averaged 150 in 2024, about 330 by the end of 2025, roughly 500 in March 2026 and a record of about 700 in May 2026, which the Plugins Team describes as 2.7 times 2025 and five times 2024. WordPress.org has not gained five times as many PHP developers since 2024. 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.
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.
| The day the advisory is published | A plugin with a vendor | A directory plugin gone quiet | The plugin you 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, 39,594 infected sites, 39.1% of the CMS 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
