AI is flooding WordPress with vulnerability reports. Who pays for the patches?

In 90 days the WordPress security program received 2,004 vulnerability reports and paid out over $90,000 for them. That is almost half of everything it has paid since 2017. Until now one party covered the cost: Automattic. On Monday, October 5, 2026, Mary Hubbard, executive director of WordPress, wrote to the heads of more than 30 companies asking them to chip in.

I am basing this on The Repository article of October 8, 2026, which quotes Hubbard’s email (The Repository, October 8, 2026), and on the announcements on wordpress.org. I have not seen the email itself. I checked the figures and quotes against the sources on October 9, 2026.

#What Mary Hubbard asked WordPress companies to fund

The email went out to the CEOs of hosting, plugin and security companies on Monday evening UTC. The Repository writes “Monday evening UTC” in its Thursday, October 8 piece. The main thesis: AI has made finding holes cheaper.

“AI had collapsed the cost of finding, reporting, and exploiting vulnerabilities”

Mary Hubbard, quoted by The Repository, October 8, 2026

According to her, the program received almost 2,000 reports in 90 days, more than ever, “and the pace is still climbing”. The Repository checked the program page on HackerOne: 2,004 reports and over $90,000 in bounties in 90 days, against a little over $200,000 paid out since the start in April 2017.

“Nearly half the program’s lifetime payouts happened in a single quarter, and the curve only goes one direction.”

Mary Hubbard, quoted by The Repository, October 8, 2026

Hubbard also writes that Automattic funded the program 100%: every bounty, triage, verification, fixes and coordinated security releases for all supported branches back to WordPress 4.7. She asks for one of three things: a contribution to a shared bounty pool, sponsoring people for triage and releases, or another arrangement worked out together. She stresses that part of the growth is real research that new tools make faster and that genuinely improves security. The problem, in her view, is the economics, not the program itself: “The economics are what’s broken, not the program”.

#Which companies were asked to fund WordPress security

GoDaddy, Newfold Digital and Hostinger headed the list of recipients. The Repository goes on to name:

Source: The Repository, October 8, 2026.

The email did not go to WP Engine, which has been in a legal dispute with Automattic since 2024, even though WP Engine representatives were thanked in the credits of the 7.0.2 and 7.1.1 security releases. Nexcess was not on the list either.

#How hosts and plugin companies responded

Those who answered The Repository are in favor, but want to know exactly what they would be signing up for.

• Hostinger (Marco Chiesi): considering seconding its own people. Since July it has worked with the security team and deploys WAF rules before patches are published.
• Kinsta (Jon Penland): wants “a clearly defined program” that companies could contribute to.
• Awesome Motive (Syed Balkhi): already sponsors several contributors on the security and plugins teams, but notes that the request is “quite open-ended”.
• Human Made (Tom Willmot): sponsors John Blackbourn, who represents the security team full time. The agency previously tried to rally companies around a security fund, “unfortunately without much traction”.
• Patchstack (Oliver Sild): the company has paid out $600,000 in bounties from its own pocket since 2022, but was never admitted to the WordPress security and plugins teams. In his view “this process needs to be reformed”.

GoDaddy, Newfold Digital and Wordfence had not responded by the time the piece was published.

#WordPress 7.1.4: 22 vulnerabilities and what they mean for your site

Update, 30 October 2026. WordPress 7.1.4 shipped on 28 October. The version page counts 22 vulnerabilities. The most serious is a race condition in the core update process that its reporter, Umut Bayram, says could lead to remote code execution. Most of the rest are stored XSS issues that need at least a Contributor account. Two reports are credited to Anthropic. The fixes were backported to older branches, from 7.0.8 down to 4.7.39, and sites with automatic background updates receive the patch on their own.

It is the seventh core security release since July. In the two-month update on the Core Security Initiative, Rudy Faile writes that the team has received more than 3,000 reports this year, more than the previous twelve years combined, and that 73% of the 109 steps in a security release now have automation. At that pace, leaving a security release until the weekend stops being a safe habit. In my WordPress update service security releases go to staging first, then to production.

#What WordPress 7.1.3 fixes and who reported the bugs

The day after the email, on October 6, 2026, WordPress 7.1.3 shipped with 7 security fixes and 4 other bug fixes. The announcement credits the reporter for each fix:

Sources: reporters per WordPress.org, October 6, 2026, exploitation conditions per Patchstack, October 6, 2026.

Only one of the seven holes works with no account and no victim involvement: the leak of comments from private posts. Patchstack explains the mechanism: in the comment feed of a single post, WordPress first fetched the comments and only then checked whether the visitor was allowed to see the post. The check hid the post but not the comments, and feeds do not return a 404, so the comments ended up in the feed. Three of the other six require a Contributor or Author account.

Four of the seven reports come from companies building AI models or their partners. That illustrates Hubbard’s thesis well: AI is now finding holes too, and someone has to pay for each of them with triage, a fix and a release for every supported branch. The announcement says the fixes are being backported to all branches covered by security patches, currently back to 4.7, and will be released as they become ready.

#WordPress 7.1.1 and 7.1.2 security fixes

According to Patchstack, release 7.1.2 came out two weeks before 7.1.3 and fixed one vulnerability (CVE-2026-87902). It let an unauthenticated visitor trigger a local file inclusion and, with the right PHP configuration, led to remote code execution (Patchstack, October 6, 2026).

Earlier, in September, Patchstack also described a remote code execution vulnerability patched in 7.1.1. If your site is on 7.1.0, it is missing the fixes from three subsequent releases.

#What is the WordPress Core Security Initiative

On August 28, 2026 the security team announced the Core Security Initiative on make.wordpress.org (Make WordPress Security, August 28, 2026). The announcement ties a “substantial increase” in reports to the rapid development of frontier AI models. It describes this as a good problem that nonetheless requires scaling triage, verification and fixing.

The initiative covers WordPress core. It does not cover plugins or themes. Reports are accepted through the HackerOne program, while vulnerabilities in WordPress.com and the mobile apps go separately, through the Automattic program.

#How Patchstack and Wordfence filter AI-generated plugin vulnerability reports

The HackerOne figures cover core only. Plugin and theme holes go through other programs, and those show the same curve. In March 2026 the Wordfence Bug Bounty Program received 1,718 vulnerability submissions, 59.4% more than in February, from 321 active researchers, and paid $62,174 in bounties that month (Wordfence, March 2026 report). The report does not say how many of those submissions were written with AI help.

Patchstack names the cause directly. On May 29, 2026 Dave Jong, its security research lead, wrote that since AI-assisted research took off, “especially throughout 2026”, the program has been getting more lower-impact reports that only narrowly meet the criteria, more duplicates (one vulnerability drew more than 20 duplicate submissions from different researchers) and reports built on incorrect AI-generated assumptions (Patchstack, May 29, 2026). From June 1, 2026 Patchstack:

• removed the Contributor role from scope, so a hole has to be reachable by a guest, Subscriber, Customer or a similar low role,
• attached conditions to each vulnerability class, for example XSS has to have site-wide or reflected impact,
• limited the monthly bounty pool to the top 5 researchers,
• bans for one week anyone who submits incorrect AI-generated assumptions or a report not tested against the actual plugin or theme.

The guidelines as published on October 13, 2026 also require a step-by-step text proof of concept with raw HTTP requests and exact payloads, and a component with 1,000 or more active installs (Patchstack bug bounty guidelines).

For a plugin author this filter matters more than the core budget. A report that passes a platform’s triage still lands on the author, who has to reproduce it and ship a fix, usually without any bounty money of their own.

#Who handles plugin vulnerabilities and CVEs on WordPress.org

The plugin directory has its own route. The Plugin Handbook asks reporters to contact the developer first, and only if that fails to email [email protected], without posting about the issue publicly. The plugins team then acts on the listing: “Most plugins are closed to prevent new downloads until the issue is resolved.” The same page says the team does not help with filing CVEs “due to a lack of resources” (Plugin Handbook, Reporting plugin security issues, last modified January 2, 2026).

So the CVE identifiers for WordPress plugins come largely from security companies registered as CVE Numbering Authorities. The CVE Program’s partner list gives Wordfence the scope of plugin, theme and core vulnerabilities discovered by or reported to its team, WPScan “WordPress core, plugins, and themes”, and Patchstack vulnerabilities found by its own team and its bug bounty participants (CVE Program, list of partners).

These companies pay for plugin triage out of their own revenue and sell protection on top of it. Wordfence writes that Premium, Care and Response users get firewall protection in real time, while free users get it after 30 days. That is the second answer to “who pays”: in plugins, the cost of triage already sits with security vendors, and two of them, Wordfence and Patchstack, are on Hubbard’s list.

#What the EU Cyber Resilience Act requires from WordPress plugin vendors

Since September 11, 2026 part of this cost is also a legal duty in the EU. The Cyber Resilience Act, Regulation (EU) 2024/2847, applies in full from December 11, 2027, but Article 71(2) brought its Article 14 on reporting forward to September 11, 2026 (Regulation (EU) 2024/2847, EUR-Lex). A manufacturer that becomes aware of an actively exploited vulnerability in its product has to notify the designated CSIRT and ENISA through a single reporting platform:

Article 3(13) defines a manufacturer as someone who develops a product and markets it under its own name or trademark, “whether for payment, monetisation or free of charge”. A company that sells a premium plugin under its brand reads straight onto that wording. Article 13(6) adds that a manufacturer who finds a vulnerability in an integrated component, open source included, has to report it to whoever maintains that component and share the fix. Breaching Articles 13 and 14 can cost up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)). Micro and small enterprises are spared fines only for missing the 24-hour early warning (Article 64(10)).

Open-source software stewards, legal persons that systematically support free software intended for commercial activities, get a lighter regime: a documented cybersecurity policy (Article 24) and no administrative fines at all (Article 64(10)(b)). The regulation does not say who pays for a steward’s triage, which is the same question Hubbard’s email puts to the companies on her list.

#What WordPress site owners should do after 7.1.3

Hubbard’s email changes nothing on your site overnight. But the HackerOne numbers and the 7.1.3 list translate into a few concrete things:

1. Install 7.1.3 if you have not yet. The announcement recommends updating immediately. Check under Dashboard, Updates that the site really is on 7.1.3, even if you have automatic updates enabled.
2. Older branches get patches later. According to Patchstack, on release day the fixes reached branches from 6.6 upward, while branches 4.7 to 6.5 were still waiting. A site on 7.1 was protected from day one.
3. Clear the cache after updating. Patchstack warns that 7.1.3 does not remove oEmbed embeds already stored in the database, so a malicious Imgur embed added earlier keeps displaying until you clear the cache.
4. Review user roles. Patchstack recommends this explicitly, because three of the seven holes require a Contributor or Author account. Accounts of former authors and agencies that finished work long ago are worth removing or downgrading.
5. Core is not everything. The Core Security Initiative does not cover plugins. If you have not reviewed your plugins in a long time, start with an audit of outdated plugins and known CVEs.
6. There may be more security releases. Hubbard writes that the pace of reports is still climbing. If you update once a quarter, you can miss several releases in a row. With ongoing WordPress website maintenance, updates are tested on a copy and deployed within days, not months.

If you want to check the state of your site right now, start with a WordPress security audit.

#When companies are expected to commit funding

Hubbard offered interested companies detailed program data and wrote that she wants a “first group of contributors standing with us this quarter”, meaning by the end of December 2026. So far no company has publicly announced a specific amount. I will add an update when one does.

#Recommended update cadence after WordPress 7.1.3 and patching costs in maintenance agreements. Update 10.10.2026

As of October 10, 2026 I found no public pledge from any company on the list, so the funding picture above stands. The risk picture is easier to pin down. Patchstack rates 7.1.3 like this:

“Update as soon as you can, but this isn’t a drop-everything emergency.”

Patchstack, WordPress 7.1.3 security release, October 6, 2026

One of the seven fixes works with no account and no victim action, and Anthropic reported three. For a site owner that means a rhythm: core patch within days, after a test on a copy, not next quarter.

The money Hubbard asks for covers bounties and triage in core. The work on your own site (testing, deploying, checking plugins) is a separate cost, and the contract has to name it. Ask whoever handles your site maintenance three things: how many days after a security release they ship the core update, whether they test it on staging, and whether an out-of-cycle release is covered by the plan.

Last updated: October 13, 2026.