Why this episode, and why now
The WP Tavern Jukebox episode with Aaron D. Campbell (#232, Aaron D. Campbell on Navigating WordPress Security in the AI Era (opens in new tab)) is worth pulling on because it frames the AI shift in plain operational terms rather than marketing terms. Campbell talks about attacks that used to need a person finding a bug, writing an exploit, and cashing out now being orchestrated by AI agents that chain issues in ways a human would struggle to even connect. That reframing matters to anyone running sites or hosting them. It is the difference between a battle of wits and a battle of compute, and once you accept the second framing, a lot of the old “stay updated and you’ll be fine” advice starts to look thin.
I want to pull on two threads from the conversation. First, what is actually changing in the attacks, because the attackers’ loop has tightened and the cost per campaign has dropped. Second, what defenders, including the hosts running Monarx-style server-side tooling, are doing about it on the detection side. Both threads are visible in the episode, and both have practical consequences for site owners who don’t think about security until something breaks.
Who Aaron Campbell is, and why his view of AI and WordPress security carries weight
Campbell has been in the internet and WordPress space for around 25 years. He ran his own agency, moved into security products, then into hosting at GoDaddy, Newfold, and hosting.com, and now works at Monarx, where the focus is malware detection and remediation aimed at web hosts rather than end users. He also led the WordPress Security Team and has stayed involved with it, which is the part that colors his read on the AI shift. He is not talking about this from a dashboard. He is talking about it from inside the team that triages disclosures, and from inside a product that watches signals from a large chunk of the hosting ecosystem.
That positioning matters because Monarx is a white-label product. Hosts buy it and may or may not surface it to their customers. If you have ever paid for “malware scanning” or “server-level firewall” through a shared host and never thought about what was actually running under the hood, there is a reasonable chance you have touched Monarx or something adjacent without knowing it. The episode is a useful reminder that AI and WordPress security, at the host tier, is being measured against signals from thousands of sites, not from one neat dashboard. The view from that vantage point is messier and more honest than most security marketing.
What is changing: AI on both sides of the WordPress security fight
The clearest thing in the episode is that the attacker’s loop has shrunk. A workflow that used to require a human finding a vulnerability, writing an exploit, and monetising it is now something an AI agent can orchestrate, including the part where it chains issues across plugins or across the stack that no single person would have put together. Campbell is careful not to oversell this, but the direction is unambiguous: the cost of running an attack campaign has dropped because the tooling is cheaper and the feedback loop is faster.
The motivator has not changed. It is almost always money, whether that means cryptominer drop, spam SEO, or straight credential abuse. What has changed is the unit economics. When the marginal cost of probing a million sites for a chained exploit drops toward zero, the attacker can afford to be wrong on 999,000 of them and still come out ahead.
Defenders are not standing still, and this is where the “arms race” framing earns its keep. Monarx and similar products are layering AI onto detection, so the same compute curve that benefits the attacker is also available to the person trying to spot them. The episode does not pretend this is a rout in either direction. It is a race where both sides have new tools, and the winner in any given quarter tends to be the side that ships faster.
The shrinking window and the supply chain problem
Two practical consequences come out of the episode that site owners tend to underestimate. The first is the disclosure-to-exploitation window. The gap between a WordPress vulnerability being publicly disclosed and being actively exploited in the wild has narrowed enough that “patch Tuesday thinking” is now a liability. If you treat plugin updates like a weekly chore, an AI-assisted attacker can sit on a fresh CVE, chain it with something else, and hit installs before the maintenance window you scheduled for Sunday has even opened.
The second is supply chain attacks against WordPress plugins. A single compromised extension fans out to every site running it, which is why this category has been climbing. AI makes finding the weak link faster, whether that is a maintainer whose credentials get phished, a build pipeline that gets tampered with, or a low-traffic plugin that nobody has audited in years. The WordPress “Protect the Shire” initiative comes up in the episode in this context, and it is worth being clear about what it is for. It is the core team’s push to harden plugin security, and it is a direct response to supply chain risk, not a generic best-practice exercise. If you have ever wondered why the WordPress Security Team has been pushing review rigor, signing, and provenance conversations, this is the underlying reason.
A worked example a site owner will recognise: imagine you run a WooCommerce store with 18 active plugins, one of which is a small abandoned slider plugin last updated in 2021. That plugin gets a CVE on a Tuesday. By Wednesday morning, an AI-assisted probe has identified which sites run it, chained it with a second issue in your caching plugin, and is testing whether your host’s WAF catches the chain. Your auto-update runs on a six-hour delay. The window between disclosure and your specific install being a viable target is now measured in hours, not weeks.
Questions site owners and hosts actually ask about AI and WordPress security
How much of the WordPress attack traffic is really AI-driven today? Hard to pin a clean percentage, and anyone claiming a precise number is selling something. The signal from hosts running large-scale detection is that automated, AI-assisted probing has replaced a meaningful slice of the old dumb scanner traffic, and the new probes adapt to what they find rather than spraying the same payload.
If I keep my plugins updated and use a decent host, am I fine? It is the floor, not the ceiling. Updates close the known doors, but supply chain attacks weaponize the moment between disclosure and your update landing, which is exactly where AI-assisted exploitation lives. The floor keeps you out of the easy pile. The ceiling is what determines whether you survive the hard pile.
What should I look for in a host on AI and WordPress security? Ask whether they run server-side malware detection, how they handle the disclosure-to-patch window, and whether they will tell you when your site is part of a campaign rather than waiting for a blackbox from Google. If the answers are vague, the answer is no.
Is the WordPress Security Team actually resourced for this? It has been lean for years, which is why ecosystem-wide collaboration between the core team, hosts, and security vendors matters more than any single product.
What to expect next
My expectation, not a promise, is that attacks chained across plugin boundaries will keep growing as a share of incidents, because AI is particularly good at combining small issues into a working path that no single CVE capture would describe. I also expect continued pressure on the disclosure-to-exploitation window, which forces hosts and plugin authors to ship faster and forces site owners to actually run those updates. And I expect more weight on supply chain integrity for plugins, including signing, provenance, and review rigor tied to Protect the Shire, alongside server-side detection that does not depend on the site owner noticing anything.
What to do this week
Audit your active plugin list and remove anything you cannot justify with a sentence. Each installed extension is a future supply chain entry point, and AI makes a long catalog more dangerous, not less. Then email your host and ask, in writing, whether they run server-side malware detection and how they handle the gap between a CVE drop and your site being patched. Save the reply. Compare it next quarter to the same question, because the honest answer in this space changes fast.