Kimb Jones

AI is finding WordPress vulnerabilities faster. The core team has more work. If you run WordPress, get on 7.x.x.x.x.x (scream).

Don’t panic, this is a good thing, sort of. Let’s see what I mean.

What actually shipped in the recent slew of AI-discovered WordPress releases?

WordPress 7.1.2 was another major security release. The core team said it loud, update ASAP and automatic background updates will do their job where they are enabled. (WordPress 7.1.2 announcement).

This is what happened for 99% of our clients on our managed systems. The 1% that had sites to large, custom or complex to have the updates pushed out automatically had them lined up and ready to go within 24 hours.

So what happened? Well, Robert Ressl was thanked for disclosing that an unauthenticated attacker could, under certain conditions, make page template do some wild things like include readable PHP outside the active theme directories.

So if both the server and the active theme meet these conditions, that can lead to remote code execution.

See the full info here: WordPress.org news, GitHub advisory.

Scary but manageable

My opinion is that this is not a “WordPress is finished” story. It is a “core had a nasty hole in templates and they patched it quickly and effectively.”

The fix was also (as ususal) backported down to 4.7 but the team still recommends that only the most recent version is actively supported in the official 7.1.2 announcement.

So if you are sitting on an old version of WordPress because “it still works,” you now have more to worry about.

Singapore’s Cyber Security Agency has also warned that versions before 7.1.2 are exposed and that a proof of concept is public and that they consider the issue actively exploited. So everyone needs to treat that as a reason to patch, not a reason to go hunting. (CSA Singapore).

Seriously, upgrade ASAP.

Whatabout AI vibepentesting?

The version of this story plastered all over LinkedIn and X is that AI is chewing through WordPress core code and spitting out contributors (and attackers) more bugs.

Some of that is true in a boring way. The AI models are excellent at reading large PHP stack and spotting things that humans would likely never find. But this is a positive, not a negative.

However, I will not do is credit this purely to AI unless the team behind it confirms it was done without human intervention. The WordPress team who reported this credited Robert Ressl and his own write-up presents a HUMAN disclosure via HackerOne, then a public post after the fix.

AI-assisted review will obviously increase the volume of “this looks wrong” findings in core, plugins and custom themes. That is extra work for maintainers. It is also extra noise. A lot of vibe-generated discovery will be wrong, incomplete, or only dangerous on a lab stack that looks nothing like WordPress in real life on your host.

The bit I actually care about

If AI-assisted contributors and researches are going to keep pressure on WordPress, plugins and custom code, the honest outcome becomes simply that “we use AI to secure your site.”

That’s it. We treat WordPress as a system that gets probed, looked at, tested, updated, and recovered. Nothing has changed and all of this just makes the final product more secure and stable in the long run.

Vibepentesting is real but it does not just mean “paste the theme into a chat and hope it finds a problem” because if you try that with any old theme it will likely find some real issues and also a pile of nonsense. It will also generate “findings” that nobody would reproduce on the live stack. It needs a lot more human expertise on top of this right now to really matter.

Think of it as “experienced people using better search over a large codebase, then proving the issue properly and disclosing it in a more frequent and informed way.”

I am not going to say that WordPress is doomed because LLMs can read PHP. Plenty of platforms will get the same treatment. The sites that cope are the ones where someone already had a security path, a recovery point, and permission to use them.

Oh and update your site!

Some clients get nervous about updates. Some don’t. Most don’t really care. Fact is that a plugin update can (and has) taken a site down and if nobody is quite sure what the last person installed then the thing just sits there, looking fine from the outside, while the risk quietly grows.

Immediate release does not mean untested release

A good example is WordPress 7.1.1 was released on 17 September 2026. The official notes had 17 core bug fixes, editor fixes, 11 security issues. And claim that you had to UPDATE ASAP WordPress.org news.

Hosts like WP Engine and Pantheon treated it as a major security event, not a “when we get to it” delay. (Pantheon release note)

The right careplan or SLA service is neither “click update on production because the banner is orange” and it’s certainly not “leave it for a month until we have a 100% perfect test window.” The right answer is far more complex.

Big scary sites need a recovery point and a short list of journeys to check. WooCommerce, RevOps, CRMs, members, operational tools first of all need to be prepped for failure.

If your support plan cannot do that in days, it is not valid support. It is a retainer for when something is already on fire.

I have seen both of these failure actions on inherited sites. One client delayed a security release because the last plugin update had broken a forms formatting (!?). Another applied everything on a Friday with no staging and spent the weekend in ignorant bliss that their online forms were now just showing a [shortcode] script. Fun times.

A worst case plugin exploitation can happen even after a patch

So what about the Wholesale Lead Capture plugin for WooCommerce which was found to have an unauthenticated file-upload issue that opened up a PHP backdoor.

This was “fixed” in version 2.0.3.2 so why was it still being hammered months later? Security blog coverage explained that this was still making waves in June and late summer. (Bleeping Computer, WPScan). Ouch.

This is the new normal pattern:

• A commercial plugin was bought once a while ago
• The licence sits on an agency or freelancer account (or an employee)
• Auto-updates were turned off or just never worked in the first place
• The plugin handles a real business process (B2B registration, in this case), so nobody wants to touch it and just prays it keeps working
• The vulnerability scanner misses the issue and the risk grows for months before anyone notices

WooCommerce and WordPress did not fail here so much as ownership of the system did.

Onboarding should include a licence and dependency register. If we cannot name the owner of a truly critical plugin, we should treat that as a high priority finding not a footnote in a spreadsheet.

Loving what Kinsta are doing

The Kinsta’s API already covers a lot of interesting features and their direction is more into “programmable hosting”. I like this as it is useful for agencies that actually run sites (Kinsta API docs).

It’s a dumb name but “programmable hosting” will really help an agency for repeatable consistent deployments, seamless staging and gives an extra layer to the “Managed WordPress” product.

It is also a reason to treat hosting as part of the engineering system, not a line item on an invoice or just something the client needs to worry about.

System care is a process, not a bucket of hours

Anyway, a lot of WordPress “support” is still sold as a monthly number. That can work for small brochure sites. It falls over the moment the site is connected to sales, memberships, stock or a CRM.

The sort of care we look for looks like this:

• You know what is on the site and why
• You know who owns licences and hosting
• You can take a recovery and backup easily
• You can update without holding your breath
• You can tell a client, in writing, what was checked afterwards with a report

If your WordPress site is still from the dark ages then a rebuild can still be a good idea but it is also an expensive way to dodge the question of who is looking after the current system.

If you want a practical first step rather than a redesign by default, that is what the WordPress 5-Day Reliability Sprint is for.

What would actually have to be true before you trusted the next update on your site?