From Slugs to Shells: How Publishing Software Became an Attack Surface
I came to the web from what now feels like another technological era.
When I went to college, my education was still heavily rooted in traditional print and broadcast advertising and marketing. The commercial web existed, of course, but it was still relatively new. My original career plan had less to do with websites than with writing. I imagined myself freelancing, probably starting out as a stringer and working my way into something resembling a writing career.
Then I took a couple of HTML classes.
That changed things.
I started building web pages for fun. Then I started playing with Dreamweaver. Before long, the web had become considerably more interesting to me than the media world I had originally expected to enter.
After college, I wound up working for a large print company that was itself trying to figure out how to move from a predominantly print-based world into the web. Part of my job became maintaining websites and helping get traditional content online.
Eventually, WordPress entered the picture.
I’ve been working with WordPress in one form or another since around 2007. At this point, that means I’ve had a front-row seat to nearly two decades of WordPress evolving from something I primarily thought of as blogging software into something much, much larger.
One tiny piece of WordPress terminology still gives away where it came from.
The final identifying portion of a WordPress URL is called the slug. WordPress still officially uses that term today for the URL-friendly portion of a post or page permalink. WordPress.org
But slug did not originate with WordPress, or even with the web.
In traditional journalism, a slug is a short identifying phrase attached to a story so editors and production staff can quickly identify it. The word also has an older printing meaning connected to strips or lines of type. Dictionary.com
I love that little linguistic fossil.
WordPress still carries vocabulary from the publishing world it grew out of.
The terminology hasn’t changed much.
The thing sitting behind the slug certainly has.
WordPress began in 2003 as what its own history describes as a personal publishing system. Today, the WordPress project says the platform powers more than 43 percent of the web and is used for everything from simple sites and blogs to complex portals, enterprise websites and applications. WordPress.org
A slug that once identified a blog post might now point toward the public face of an ecommerce business, learning-management system, membership platform, corporate lead-generation machine, customer portal or database-driven application.
Behind it might sit payment processing, forms, marketing automation, APIs, analytics, JavaScript frameworks, third-party services and dozens of plugins written by developers scattered across the world.
That evolution is one of WordPress’s greatest accomplishments.
It is also why discussing WordPress security in the age of AI requires thinking about WordPress as much more than a publishing platform.
It has become an application ecosystem.
And application ecosystems have attack surfaces.
WordPress Outgrew Its Original Threat Model
Calling WordPress “insecure” is lazy.
WordPress became dominant because it solved an enormous number of problems extraordinarily well. It is accessible, extensible, open source, inexpensive to deploy and adaptable to wildly different purposes.
Those are strengths.
The WordPress project describes its mission as “democratize publishing,” and its architecture reflects that philosophy. Someone with limited technical experience can get a site online quickly, while a developer can alter and extend the platform almost beyond recognition. WordPress.org
Plugins are fundamental to that model.
WordPress’s own developer documentation explains that plugins are packages of code used to extend WordPress Core. They can contain PHP, CSS, JavaScript and other assets, and they can be as simple as a tiny single-purpose extension or as complicated as a complete support-ticketing system with user interfaces, email notifications and database functionality. WordPress Developer Resources
That extensibility is one of the reasons WordPress conquered such an enormous portion of the web.
It also created a very different security model from a tightly controlled software-as-a-service platform.
With something like Wix or the standard Webflow hosting environment, the vendor controls much more of the underlying software and infrastructure. Wix, for example, describes itself as a SaaS platform where it handles software updates automatically. Webflow describes its standard hosting as a completely managed environment where customers don’t have to apply security patches themselves. Wix Support
Self-hosted WordPress is different.
A real-world business installation might look something like this:
WordPress Core
plus:
- PHP
- a database
- a hosting/server stack
- a commercial theme
- a child theme
- a page builder
- 20, 30 or 40-plus plugins
- JavaScript libraries
- third-party APIs
- custom PHP or JavaScript snippets
- analytics and advertising scripts
- email integrations
- form processors
- security software
- caching systems
- backup software
Some of that software comes from the WordPress project.
Some comes from the hosting provider.
Some comes from commercial theme developers.
Some comes from large software companies.
Some comes from a developer whose name the current site owner has never heard of.
And sometimes a plugin was installed six years ago by an agency that no longer has anything to do with the website.
That creates what security professionals call an attack surface.
What Is an Attack Surface?
NIST defines an attack surface as the collection of points where an attacker can attempt to enter a system, affect it or extract data from it. NIST Computer Security Resource Center
In plainer English:
Your attack surface is everything an attacker can potentially interact with, manipulate or exploit.
For WordPress, that does not simply mean:
/wp-login.php
It could include:
- the login page
- a vulnerable plugin
- an outdated theme
- an abandoned API endpoint
- an upload form
- an old administrator account
- an insecure custom shortcode
- a poorly protected REST endpoint
- an outdated PHP version
- a database credential
- a forgotten staging site
- a third-party integration
- a file-management plugin
- or custom code somebody added years ago and forgot about.
The more capable a WordPress installation becomes, the more potential interaction points it can accumulate.
That doesn’t mean every additional plugin or feature makes a site unsafe.
It means every additional component becomes something that has to be trusted, maintained, updated and eventually retired when it is no longer needed.
This is the fundamental security tradeoff behind WordPress.
The same architecture that lets me turn a basic WordPress installation into almost anything also means that a production WordPress site can become a decentralized application stack assembled from software maintained by dozens of unrelated organizations.
And unlike Wix or Webflow, there may be no single company responsible for maintaining the entire thing.
WordPress maintains WordPress.
The hosting company maintains the server environment.
The PHP project maintains PHP.
One developer maintains the SEO plugin.
Another maintains the page builder.
Another maintains the forms.
Another maintains the backup system.
Another maintains the theme.
And somewhere at the end of that chain is the site owner, agency or administrator who has to make sure all of those pieces remain compatible, supported and patched.
For years, that decentralized model was manageable largely on human time.
A vulnerability would be discovered. Someone would investigate it. A vendor would develop a fix. Security researchers would analyze it. Attackers might eventually weaponize it. Administrators would install the update.
That process was never leisurely, and automated attacks certainly existed long before generative AI.
But the vulnerability lifecycle was still constrained in important ways by human attention, human analysis and human labor.
That is the part AI is beginning to change.
And when one WordPress installation can contain dozens of independently maintained pieces of executable software, making vulnerability research faster does not merely make individual bugs easier to find. It changes the economics of searching the entire ecosystem for them.
Our monkey brains are about to get some competition.
The WordPress Plugin Economy Changed the Equation
WordPress did not become an enormous attack surface because WordPress Core suddenly became riddled with security holes.
The much larger story is the ecosystem that grew around it.
According to Patchstack’s State of WordPress Security in 2026 report, researchers documented 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42 percent increase over the previous year. Ninety-one percent were found in plugins and another 9 percent in themes. Only six vulnerabilities were reported in WordPress Core, and Patchstack classified those as low priority. Patchstack
That distinction matters.
When someone says “WordPress has thousands of vulnerabilities,” the mental image can easily become a fundamentally insecure CMS riddled with holes.
That is not really what the data shows.
The greater security challenge is that WordPress can be extended with an almost limitless collection of independently developed software. Every plugin solves a problem, but every plugin also adds code that somebody has to write, maintain, audit and patch.
And the security attention isn’t distributed evenly.
Patchstack found that premium WordPress components can receive less scrutiny precisely because researchers have less access to their source code. In its 2025 research, Patchstack received 1,983 valid reports involving premium or freemium components. Of those vulnerabilities, 76 percent were considered exploitable in real-world attacks, and premium components had three times as many known exploited vulnerabilities as free components in the dataset. Patchstack
Paying $79 a year for a plugin does not magically make its code safer.
Nor does a plugin remain safe forever simply because it was safe when somebody installed it.
Developers retire. Companies disappear. Products get acquired. Plugins are abandoned. Security researchers move on to other targets. A perfectly reasonable extension installed in 2022 can become technical debt by 2026.
Patchstack found the scale of that problem particularly clearly in 2024, when 1,614 vulnerable plugins and themes were removed from the WordPress repository because of unresolved security problems, including 1,450 with medium- or high-priority vulnerabilities. Patchstack
Removing a vulnerable plugin from WordPress.org does not, however, remotely uninstall it from websites that already have it.
There may still be thousands of copies running quietly around the internet.
And attackers know it.
Patchstack’s real-world exploitation data from 2025 found that six of the ten most heavily attacked vulnerabilities in its dataset had originally been disclosed before 2025. Some dated back to 2023. Attackers were still probing for them because vulnerable versions remained installed on real websites. Patchstack
There is an economic logic to this.
An attacker does not necessarily care whether a vulnerability is new or exciting. If an old exploit can still compromise enough forgotten websites to make automated scanning worthwhile, there is no reason to stop using it.
That exposes one of the least glamorous but most important realities of WordPress security:
WordPress made deploying an internet-facing application incredibly easy. It did not guarantee that someone would still be administering that application five years later.
That problem has existed for years.
AI is about to make finding those neglected installations considerably more efficient.
The Forgotten WordPress Site
Anyone who has worked with WordPress long enough has encountered some version of this website.
It launched in 2022.
The business hired an agency or freelance developer to build it. Everything worked. The invoices were paid. Everyone moved on.
Eventually the agency relationship ended.
The employee who originally managed the project left the company.
Nobody remembers who owns one of the administrator accounts.
PHP has not been upgraded in three years.
The theme developer released fourteen updates.
Three plugins were abandoned.
Twenty more show update notifications.
One old integration still has credentials somewhere.
There is probably a backup.
Somewhere.
Nobody has ever tried restoring it.
And yet the website looks fine.
The homepage loads. The contact form apparently works. Leads still arrive. Google still indexes it.
So everyone quite rationally concludes:
Don’t touch it.
This is where software reliability and software security begin to diverge.
A website can look completely healthy while quietly accumulating vulnerabilities underneath the surface.
The plugin that produces a carousel doesn’t announce that its developer stopped maintaining it eighteen months ago. The abandoned administrator account doesn’t put a warning in the footer. An outdated PHP version doesn’t necessarily make the homepage look broken.
Everything works right up until the moment something finds the weakness.
And increasingly, something does not mean a human hacker personally browsing the site at two in the morning.
It can mean automated infrastructure scanning huge portions of the internet looking for one very specific condition:
Are you running Plugin X, version Y or earlier?
If the answer is yes, the website has just become interesting.
Patchstack found that 46 percent of WordPress vulnerabilities disclosed in 2025 had not received a developer patch by the time they became public. It also observed that roughly half of high-impact vulnerabilities saw exploitation within the first 24 hours after disclosure. Patchstack
That creates a particularly bad mismatch for the neglected WordPress site.
The attacker may be operating on a timeline measured in hours.
The website owner may operate on a timeline measured in:
“I’ll ask whoever handles the website about that when I get a chance.”
Historically, this was mostly a maintenance problem.
Increasingly, it is becoming a time-to-response problem.
And that is where our monkey brains run into machines that do not sleep.
Monkey Brains Meet Machine-Speed Vulnerability Research
Traditional vulnerability research is skilled, painstaking work.
A researcher studies a codebase.
They trace what happens to user-controlled input.
They form a hypothesis.
They test it.
It fails.
They revise the hypothesis.
They inspect another function.
They test again.
Eventually they may find a path from an apparently harmless input to something consequential: unauthorized database access, privilege escalation, arbitrary file upload or remote code execution.
Brilliant researchers can do extraordinary things.
But they still have monkey brains.
So do I.
We get tired. We overlook things. We follow dead ends. We need sleep. We get distracted by email, lunch, children, meetings and whatever notification just appeared in the corner of the screen.
AI changes the economics of that process because it can function as a labor multiplier.
Modern coding models can help researchers navigate unfamiliar codebases, identify potentially dangerous functions, trace data flows, compare vulnerable and patched versions, generate testing hypotheses and assist with building proof-of-concept exploits.
That does not mean someone types:
Hack WordPress.
and the machine immediately produces a working zero-day.
The reality is considerably more interesting.
AI can allow a capable researcher to investigate more code, more hypotheses and more potential attack paths in the same amount of human time.
Wordfence has begun measuring that transition inside its own WordPress bug-bounty program.
In late November 2025, Wordfence started asking researchers whether AI had been used during their vulnerability research. In the first full week of tracking, approximately 16 percent of submitted vulnerabilities involved some form of AI assistance.
By April 2026, that figure had climbed to approximately 66 percent. Wordfence
Those numbers are self-reported, which Wordfence itself emphasizes. Researchers are reporting their own AI use rather than having it independently detected.
But the direction of travel is difficult to miss.
Even more strikingly, Wordfence reported that the overall volume of vulnerability submissions had increased 453 percent since October 2025. That does not prove AI caused the increase. There are too many variables involved to draw that conclusion from correlation alone.
But it does show that vulnerability discovery is accelerating at the same time AI-assisted research has gone from unusual to commonplace. Wordfence
Wordfence itself does not expect AI to replace human vulnerability researchers in the near term. Its security team is instead experimenting with combinations of human researchers and multi-agent AI systems for vulnerability hunting, triage and data processing. Wordfence
That is probably the more useful way to understand what is happening.
This isn’t:
human researcher → replaced by machine
It is increasingly:
human researcher × machine capability
A researcher who might once have manually inspected one suspicious code path can ask models to investigate several. A model can help explain an unfamiliar function, search for related uses elsewhere in the project, compare two versions of the same plugin or generate test cases while the human decides which avenue is actually worth pursuing.
The monkey brain remains very much in the loop.
It just acquired some extremely fast interns.
And the defenders are not the only people with access to them.
That is where AI-assisted vulnerability research begins turning into an entirely different problem: what happens when the same acceleration moves from finding vulnerabilities to weaponizing them?
AI Didn’t Invent Automated Hacking
Before blaming artificial intelligence for every ugly thing happening on the internet, it is worth establishing something important:
Hackers did not wait for ChatGPT to discover automation.
Automated vulnerability scanners have existed for decades. So have fuzzers, exploit frameworks, botnets, credential-stuffing tools, malware kits, patch-diffing techniques and mass internet scanning.
Long before generative AI, an attacker could write a script that effectively said:
Find every website running Plugin X and try exploit Y against it.
Once somebody had done the difficult intellectual work of discovering and weaponizing a vulnerability, computers were already very good at doing the repetitive part.
They could scan thousands or millions of IP addresses, identify vulnerable software versions and fire the same exploit over and over without getting bored, distracted or asking for overtime.
AI did not invent that.
What AI increasingly changes is the reasoning layer between raw information and automation.
Consider a traditional patch-diffing workflow.
A vendor quietly releases Plugin X version 4.2.
A security researcher or attacker downloads versions 4.1 and 4.2, compares the code and asks:
What changed? Why did it change? Is this fixing a security problem? Can I reproduce the underlying bug? Can I turn that bug into something exploitable?
Those are reasoning problems.
Historically, they required substantial human skill and time.
An AI-assisted workflow can increasingly help with several of those steps:
Compare the versions.
Identify security-relevant changes.
Trace the affected code path.
Suggest why the change was necessary.
Generate hypotheses about the original vulnerability.
Develop test cases.
Evaluate failures.
Refine the hypothesis.
A human researcher may still be directing the process, validating conclusions and recognizing when the model is confidently wandering into nonsense.
But the machine can now participate in work that used to sit almost entirely on the human side of the line.
That distinction matters.
Traditional automation was extraordinarily good at:
Try exploit X against every installation of software Y.
AI-assisted systems are increasingly capable of helping answer:
What is exploit X, and how might we build it?
Once that problem has been solved, yesterday’s automation infrastructure can take over again.
That is why I think one of the least sensational but most important ways to describe the shift is this:
AI didn’t invent automation. It is making more parts of the attack chain automatable.
And in 2026, WordPress provided an extraordinary demonstration of what that can look like.
Case Study: The $25 WordPress Exploit
In July 2026, researchers at Searchlight Cyber disclosed wp2shell, a vulnerability chain in WordPress Core that allowed pre-authentication remote code execution.
Those four words deserve translation.
Pre-authentication means the attacker did not first need a WordPress username, password or other authenticated account.
Remote code execution, or RCE, means successful exploitation could allow an attacker to execute code on the affected server.
And this was not a vulnerable third-party plugin somebody downloaded from an obscure developer.
It affected WordPress Core itself.
Searchlight reported that the attack worked against a stock WordPress installation with no plugins required. WordPress versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 were affected, with patched versions released as 6.9.5 and 7.0.2. Searchlight Cyber
That alone would make wp2shell an important security story.
The way it was discovered makes it an AI story.
Researcher Adam Kues used GPT-5.6 Sol Ultra during the vulnerability research process. According to Searchlight Cyber, the model-assisted work took roughly 10 hours and consumed about $25 worth of compute. Searchlight Cyber
That does not mean somebody typed:
Find me a WordPress zero-day.
and went out for lunch while the AI independently hacked the internet.
Searchlight is quite explicit about the continued role of the researcher. Kues had to decide where to investigate, direct the model, interpret its output, validate the exploit chain and then handle responsible disclosure. Searchlight Cyber
The human expertise did not disappear.
It got leveraged.
And that is what makes the economics so interesting.
Searchlight’s own research page framed the contrast starkly: exploit brokers can pay enormous sums for a high-value WordPress RCE, while the model compute involved in this research cost roughly the price of dinner. Searchlight Cyber
The remarkable thing is therefore not simply:
AI found a vulnerability.
The more consequential observation is:
Scarce human security expertise can increasingly be amplified with inexpensive, widely available computational assistance.
A highly skilled vulnerability researcher remains highly skilled.
But if AI lets that researcher inspect more code, test more hypotheses and pursue more potential chains in ten hours than they previously could in several days or weeks, the economics of vulnerability research begin to change.
And defenders do not get the luxury of considering that discovery process in isolation.
What happened after wp2shell was patched is just as important.
Elastic Security Labs reported that public proof-of-concept tools appeared on GitHub within hours of disclosure, with scanning beginning immediately afterward. Elastic subsequently observed exploitation-related host behavior in telemetry, including web server processes spawning shells and new plugin directories appearing on compromised systems. Elastic Security Labs
Searchlight said weaponized exploitation was observed less than two days after the patch shipped. Searchlight Cyber
That sequence captures the problem beautifully:
Vulnerability discovered
↓
vendor develops patch
↓
patch becomes public
↓
other researchers and attackers analyze what changed
↓
public exploit code appears
↓
automated scanning starts
↓
unpatched WordPress installations get tested
All of that can now happen frighteningly quickly.
The $25 figure makes a good headline.
The timeline is the more important story.
The Vulnerability Lifecycle Just Got Faster
Security vulnerabilities have a lifecycle.
It is not always neat, and the order can vary, but a simplified version looks something like this:
Flaw introduced
↓
Vulnerability discovered
↓
Vendor notified
↓
Vendor investigates
↓
Patch developed
↓
Patch released
↓
Vulnerability disclosed
↓
Exploit developed or published
↓
Mass scanning begins
↓
Vulnerable systems are attacked
The process has never been entirely manual.
Automated scanners, static analysis tools, fuzzers and exploit frameworks have occupied parts of that lifecycle for years.
AI potentially accelerates more of it.
Developers are increasingly using AI to write and review software.
Security researchers are using AI to navigate large codebases, search for vulnerabilities and test hypotheses.
Attackers can use similar capabilities to understand newly disclosed weaknesses, analyze patches and assist exploit development.
Defenders can use AI to triage alerts, review code, detect suspicious behavior and prioritize remediation.
That is why treating AI as a magical offensive hacking tool misses half the story.
It sits on both sides of the vulnerability lifecycle.
And that introduces an interesting dynamic.
Suppose AI helps a vendor find and patch a vulnerability three times faster.
Excellent.
But suppose AI also helps attackers understand that patch and develop working exploitation three times faster.
Now the absolute speed of the entire lifecycle has changed.
This is increasingly a race between two operational metrics:
How quickly can the attacker turn vulnerability information into an actionable exploit?
and:
How quickly can the defender identify and remove the exposure?
That brings us to the concept I think matters most for ordinary WordPress administrators.
The patch window.
The Shrinking Patch Window
A patch window is the practical period during which a defender can remediate a vulnerability before successful exploitation becomes likely or widespread.
It is not a universal countdown timer.
There was never some golden era where every WordPress administrator reliably had fourteen days to update a vulnerable plugin.
Some vulnerabilities were weaponized quickly long before generative AI existed. Others remained obscure for months or years.
But there is strong evidence that, for attractive vulnerabilities, time-to-exploit can now be measured in hours.
Patchstack analyzed real exploitation activity across WordPress vulnerabilities disclosed during 2025. Among the vulnerabilities responsible for roughly 95 percent of the observed exploitation activity in its dataset, about half of high-impact vulnerabilities were exploited within the first 24 hours.
When Patchstack weighted the results according to attack intensity, the median time to first exploitation for the heavily targeted group was approximately five hours. Patchstack
Five hours.
That means the clock may already be running while the average website owner is:
in a meeting,
driving home,
sleeping,
ignoring an update notification,
or assuming they’ll deal with it tomorrow.
Patchstack’s conclusion is blunt: ordinary plugin updating is no longer sufficient as the sole defensive strategy when attackers can weaponize serious vulnerabilities within hours. Patchstack
A September 2026 WordPress Core vulnerability provided another very recent example.
Patchstack reported that attackers began probing sites for CVE-2026-87902 only hours after the relevant WordPress patch became available. Within roughly a day, activity had progressed from reconnaissance to attempts involving code execution techniques. Patchstack
That is the environment WordPress administrators now have to plan around.
Two useful terms help describe the race.
Time to Exploit
Time to Exploit, or TTE, describes how quickly an attacker can move from knowledge of a vulnerability to useful exploitation.
That might involve discovering the vulnerability independently, reverse-engineering a security patch, reproducing somebody else’s research or simply downloading a public proof-of-concept.
From the defender’s perspective, shorter TTE is bad news.
Mean Time to Remediate
Mean Time to Remediate, or MTTR, measures how quickly an organization typically fixes or otherwise mitigates a security exposure once it has been identified.
For a WordPress site, remediation might mean:
installing the patched plugin,
updating WordPress Core,
applying a WAF rule,
disabling a vulnerable component,
or deploying a virtual patch while the permanent update is tested.
And this gives us an extremely useful way to think about AI-era security:
Your problem begins when attacker TTE becomes shorter than your MTTR.
If attackers can operationalize a vulnerability in five hours, but your process looks like:
security email arrives Friday afternoon → nobody reads it until Monday → web developer gets ticket Tuesday → staging update Wednesday → production update Thursday
then you do not really have a seven-day patching process.
You have a potentially six-day exposure gap.
AI potentially makes that gap wider by helping attackers reduce the work required to analyze and operationalize newly available information.
At the same time, AI-assisted defense, automated patching, vulnerability intelligence and virtual patching can help defenders compress their own response times.
That is why I increasingly think about modern WordPress security in terms of competing clocks:
AI is squeezing TTE. Your defensive stack has to squeeze MTTR.
This does not mean blindly auto-updating every production component five seconds after a release.
Updates can break sites.
Compatibility testing still matters.
Backups matter.
Human judgment matters.
But the old model of checking WordPress once every couple of weeks and installing whatever updates have accumulated is increasingly difficult to defend for a business-critical website.
If the attacker’s clock is measured in hours, the defender cannot operate comfortably in weeks.
And if humans cannot reliably move that quickly on their own, the obvious next question becomes:
How much of the defensive process should we automate?
That’s where virtual patching, AI-assisted defense and the 5 D’s of WordPress security enter the picture.
Human-in-the-Loop Is Necessary, But Not Sufficient
One of the most reassuring phrases in AI security is:
There is always a human in the loop.
That sounds comforting.
The AI cannot simply delete the production database, disable the security plugin or email every customer. A person has to approve the action first.
That is unquestionably better than giving an autonomous agent unrestricted authority.
It is also not enough.
Humans have a remarkable ability to turn safeguards into reflexes.
Anyone who has clicked through software installation dialogs, cookie banners, security warnings or terms-of-service screens has experienced this. A warning that initially attracts attention can become invisible after the twentieth repetition.
Security professionals have a term for the broader problem: alert fatigue.
Now imagine the same effect inside an AI security system.
Monday morning:
Critical vulnerability detected.
Proposed action: Update Plugin X.
APPROVE?
Approve.
Ten minutes later:
Suspicious administrator account detected.
Proposed action: Disable account.
APPROVE?
Approve.
Then another.
And another.
By Friday, the administrator may have reviewed 43 recommendations.
At some point, the approval process risks becoming cybersecurity’s version of clicking Accept All Cookies.
That creates an uncomfortable possibility.
The system technically has a human in the loop, but the human has stopped functioning as a meaningful security control.
Human-in-the-loop with a giant green APPROVE button is not, by itself, a security architecture.
OWASP’s current MCP security guidance is surprisingly specific about this. For destructive, financial or data-sharing operations, it recommends explicit human confirmation and says the interface should display the full parameters of the proposed tool call, not merely a friendly summary such as “Update WordPress” or “Delete suspicious account.” OWASP Cheat Sheet Series
That distinction matters enormously.
Consider these two approval prompts:
Delete suspicious WordPress user?
versus:
Tool:
delete_user
User ID: 47
Username:jgarcia
Role: Administrator
Reassign content to: none
The second one forces the reviewer to confront what the machine is actually about to do.
This is already showing up in real automation platforms.
n8n, which I use for my own WordPress publishing workflows, supports human review gates for AI tool calls. When an agent wants to execute a sensitive tool, the workflow can pause and show the reviewer which tool it intends to call and the parameters the AI supplied. The reviewer can approve or deny the actual operation before anything happens. GitHub
That is a much stronger pattern than relying on a system prompt saying:
Ask permission before doing anything dangerous.
One is advice to the model.
The other is an enforced checkpoint in the execution path.
There is still a human involved in both cases.
But only one of them creates a meaningful technical boundary.
A Safer Model for AI WordPress Administration
If AI agents are going to help administer production WordPress environments, I would rather design around one assumption:
Eventually the model will be wrong.
Not malicious.
Not possessed.
Not secretly plotting against humanity.
Just wrong.
It may misunderstand the site.
Misclassify a legitimate file.
Misinterpret a plugin’s behavior.
Follow an injected instruction.
Choose the wrong tool.
Or recommend exactly the wrong thing at exactly the wrong time.
The question should therefore not be:
How do we make sure the AI never makes a mistake?
That is probably unrealistic.
The better question is:
How do we make sure one mistake cannot destroy production?
That is containment by architecture.
A safer WordPress security workflow might begin with the production site exposing only read-only information to the agent.
The agent can inspect installed components, versions, vulnerability intelligence, logs and configuration data.
It can investigate.
It can explain.
It can recommend.
But it cannot immediately change production.
If remediation appears necessary, the next step is not:
Go ahead.
It is:
Reproduce the problem somewhere safer.
The production site is cloned to staging.
The AI can then receive broader permissions inside that isolated copy.
Update the plugin.
Remove the suspicious file.
Change the configuration.
Test the proposed fix.
Run security scans.
Load important pages.
Verify forms.
Check the database.
Compare the result against production.
If everything passes, a human reviews what changed and approves a controlled deployment to production.
The basic flow becomes:
Production, initially read-only
↓
AI investigation and recommendations
↓
Human review
↓
Staging clone
↓
AI remediation and testing
↓
Automated functional and security validation
↓
Human approval
↓
Controlled production deployment
That is obviously more cumbersome than giving an AI administrator credentials and telling it:
Keep the website secure.
It is also considerably safer.
The architecture should reinforce that safety with scoped credentials.
The WordPress tool should not necessarily possess the Cloudflare token.
The Cloudflare integration should not inherit database credentials.
A vulnerability scanner does not need permission to delete users.
A database-inspection tool may only need read access.
Credentials can also be short-lived rather than permanent. OWASP specifically recommends narrow OAuth scopes, separate credentials for different MCP servers and short-lived tokens instead of broad, persistent access. OWASP Cheat Sheet Series
Everything the agent does should also be logged.
Not merely:
Security remediation completed.
But:
Which tool ran?
Which account authorized it?
What parameters were sent?
What files changed?
What database records changed?
When did it happen?
OWASP recommends logging MCP tool invocations with full parameters, user context and timestamps, precisely because agentic systems can perform complicated chains of actions that may otherwise be difficult to reconstruct later. OWASP Cheat Sheet Series
And then there is rollback.
Before consequential changes, create a known restore point.
Keep useful retention.
Test restoration.
Do not assume the word Backup on a dashboard means everything is fine.
I have recently acquired some firsthand appreciation for that last point.
The broader principle is simple:
Do not give an AI unlimited production authority merely because you trust the model. Limit the authority so that trust is not the only thing standing between an error and an outage.
That is what containment looks like.
The New WordPress Security Skillset
WordPress security work is starting to broaden.
For years, a competent WordPress administrator could get surprisingly far by understanding the CMS itself, hosting, plugins, themes, PHP, databases and backups.
Those things still matter.
Now another layer is being added.
Increasingly, the administrator working on a modern WordPress environment may also need to understand APIs, automation systems, AI-assisted code analysis, agent permissions and the security implications of connecting models to real tools.
That does not mean every WordPress developer suddenly has to become a penetration tester or machine-learning engineer.
It means the boundaries between disciplines are becoming less tidy.
A WordPress security problem may begin with:
This plugin has a vulnerability.
But resolving it can involve:
vulnerability intelligence, firewall behavior, PHP compatibility, database safety, CDN configuration, identity management, API authentication, staging workflows and backup recovery.
Add AI agents and another set of questions appears.
What credentials does the agent have?
What APIs can it call?
Which operations require human approval?
Where are those credentials stored?
Can web content influence its instructions?
Does it have unrestricted filesystem access?
Can one compromised tool influence another?
What gets logged?
How do we revoke access?
How large is the blast radius?
That is not traditional “install a security plugin” WordPress maintenance.
It is increasingly application security plus automation plus orchestration.
That word, orchestration, matters.
I already use n8n to coordinate publishing across a network of WordPress sites.
Those workflows are not autonomous cybersecurity agents. They mostly solve a much more ordinary problem: moving content through several systems and publishing it efficiently.
But building them changes the way you think about software.
The moment you give a workflow authenticated API access, automation stops being abstract.
An API credential means the workflow can actually do something.
Create the post.
Upload the image.
Change the taxonomy.
Publish the page.
That same architecture can obviously be pointed at security operations.
An AI system can query vulnerability intelligence.
An automation platform can call WordPress.
Another node can talk to Cloudflare.
Another can clone a database.
Another can notify Slack.
MCP can give the agent access to additional tools.
At that point, the skill is not merely knowing each individual system.
It is understanding how authority, data and trust move between them.
That is increasingly what modern WordPress administration looks like.
A capable operator benefits from understanding WordPress administration, vulnerability management, WAFs, malware-remediation basics, databases and backups, PHP lifecycle management, API authentication, workflow automation, AI-assisted analysis, MCP security, least privilege, prompt injection and incident response.
Not because everyone has to become an expert in every one of those disciplines.
Because the systems are increasingly touching one another.
And security tends to break at the seams.
What I Changed After Nearly 20 Years of WordPress
I’ve been working with WordPress since roughly 2007.
For much of that time, my mental model of WordPress maintenance was fairly straightforward.
Install WordPress.
Choose reputable plugins.
Keep things updated.
Back up the site.
Do not do anything obviously stupid.
That advice is still useful.
It just no longer feels sufficient.
The modern version looks more like this:
Know what is installed.
If nobody can explain why a plugin exists, that is worth investigating.
Know who maintains it.
A plugin that worked flawlessly in 2021 may be effectively abandoned in 2026.
Know what privileges it has.
The difference between something that can read data and something that can alter the filesystem matters.
Know whether it is vulnerable.
And increasingly, know whether that vulnerability is theoretical, exploitable, publicly weaponized or already being attacked in the wild.
Know how quickly you can mitigate it.
If attacker time-to-exploit is measured in hours but your maintenance process operates in weeks, you have a problem.
Know whether the backup actually restores.
This one has moved considerably higher on my personal list.
A green checkmark saying Backup Complete is comforting.
A successful test restoration is evidence.
Know which automated systems can change production.
This may be the newest addition.
An automation workflow, AI agent or MCP-connected tool with production credentials is part of the security architecture whether or not anyone thinks of it as a security product.
That is probably the biggest shift in how I now think about WordPress.
The site itself is only part of the system.
The tools that manage the site are part of the attack surface too.
The Slug Survived. The Threat Model Didn’t.
When I first started learning about media and advertising, the world I expected to enter was still dominated by print and broadcast.
A slug was newsroom vocabulary.
A stringer was a freelance reporter.
Websites were becoming important, but they had not yet swallowed enormous chunks of publishing, commerce, advertising, customer service and business operations.
Then I took some HTML classes.
I started building pages for fun.
Dreamweaver followed.
Eventually I found myself helping a large print company get more of its content onto the web.
Then came WordPress.
Plugins.
APIs.
Cloud platforms.
Automation.
Large language models.
Agents.
MCP.
Nearly twenty years later, WordPress still calls the identifying part of a permalink a slug.
I like that.
It is a tiny linguistic artifact from the platform’s publishing ancestry.
But there may now be dozens of independently maintained software components, third-party services, API connections and automated systems sitting behind that slug.
A page is no longer necessarily just a page.
And increasingly, the machines looking for weaknesses in those systems are not operating exclusively at human speed.
Neither are the machines defending them.
That is the promise and the problem.
AI can help developers find dangerous code before it ships.
It can help researchers investigate vulnerabilities.
It can help defenders prioritize alerts, deploy protections and respond faster than a human administrator could reasonably manage alone.
It can also help attackers analyze patches, develop exploits and scale their research.
And when we give defensive AI the authority to act, that defensive system becomes another privileged component we have to secure.
So perhaps the biggest change is not simply that WordPress has a larger attack surface than it did twenty years ago.
It is that the attack surface now includes some of the tools we are building to defend the attack surface.
The AI attack surface isn’t coming to WordPress someday. It’s already here.
The challenge now is making sure our defenses become faster without giving them enough authority to become vulnerabilities themselves.
