r/Wordpress • u/hackrepair • 1h ago
An Open Letter to WordPress.org: It’s Time to Make Security a Core Feature
2027 will be an exponentially challenging year for WordPress.
For most of WordPress’s history, building and maintaining the PHP code that powers plugins, themes, and WordPress itself required a real skill set. It required experience, patience, and a special kind of concentration.
That has changed.
In 2026, WordPress entered what I would call its unveiling year.
By unveiling, I mean that the barrier to both creating WordPress code and finding weaknesses in WordPress code has collapsed. Pretty much anyone with a basic education, a few dollars, and access to modern AI tools can now generate plugins, build themes, review PHP, test code paths, and discover vulnerabilities that previously required years of specialized experience.
That shift is not coming someday. It is already here.
This past week made that painfully clear. WordPress Core received an emergency security release after serious vulnerabilities were discovered and patched. Reporting around the issue indicated that AI tooling was involved in developing or validating the exploit chain. Whether one prompt or many, whether cheap or expensive, the larger point remains the same:
The old assumptions no longer hold. The ability to find exploitable PHP vulnerabilities is now available to everyone.
For years, WordPress security has depended on a mix of responsible disclosure, plugin developer responsiveness, managed hosting protections, security plugins, vulnerability databases, and the quiet assumption that finding exploitable bugs still required enough expertise to slow attackers down. That assumption is disappearing.
The Avalanche Problem
The greatest threat to WordPress is not only the next vulnerability in Core. It is the vast installed base of old plugins and themes.
WordPress has succeeded because it made publishing easy and extensibility nearly unlimited. That same success has created a security problem of historic scale.
There are millions of WordPress sites running plugins and themes written years ago, often by developers who have moved on, businesses that no longer exist, or maintainers who never expected their code to be reviewed by AI powered vulnerability testing tools.
Many of these plugins work fine. Many of them are useful. Many of them also contain insecure patterns that were common, unnoticed, or simply not understood at the time they were written.
In the past, those weaknesses were discovered slowly. A researcher found one. A botnet found another. A security company published a notice. A plugin developer released a patch, or did not. That pace is about to change.
As AI assisted code review and exploit generation become built into everyday tools, WordPress will face an avalanche of vulnerability reports, emergency patches, abandoned plugins, active exploitation campaigns, and confused site owners who have no idea which warnings matter and which actions are safe.
This is not a future where security remains a side concern. This is a future where security becomes the main feature WordPress must deliver.
WordPress Needs Security as a Native Product Feature
WordPress cannot depend forever on every site owner installing the right security plugin, choosing the right host, subscribing to the right vulnerability feed, understanding CVEs, reading patch notes, and manually deciding what to do when a plugin becomes dangerous. That model does not scale.
WordPress needs a native security layer that treats plugin and theme risk as a first class part of the platform.
In plain terms, WordPress Core should know when installed code is vulnerable, understand the likely severity, communicate clearly to the site owner, and take safe protective action when possible.
This does not mean WordPress needs to replace Patchstack, WPScan, Wordfence, hosts, researchers, or the existing security ecosystem.
It means WordPress needs to learn from them and bring the most essential protections into the platform itself.
What WordPress Core Should Build
1. A Native Vulnerability Intelligence Feed
WordPress should maintain or integrate a signed, trusted vulnerability feed for plugins, themes, and Core.
Every WordPress site should be able to answer basic questions without requiring a third party plugin:
- Is this installed plugin known to be vulnerable?
- Is the vulnerable version currently installed?
- Is there a safe update available?
- Is the plugin abandoned?
- Is exploitation active in the wild?
- Is this vulnerability remotely exploitable?
- Does it require authentication?
- Is there a temporary mitigation?
This information should appear directly in the WordPress admin, in Site Health, in Updates, and in a dedicated Security screen.
Site owners should not have to understand the difference between a theoretical vulnerability, a patched vulnerability, and an actively exploited vulnerability by reading scattered blog posts. WordPress should tell them plainly.
2. Vulnerability Aware Automatic Updates
WordPress already supports automatic updates, but security updates need a more intelligent model.
When a plugin or theme has a serious known vulnerability, WordPress should be able to prioritize that update differently from a routine feature release.
A modern security update system should include:
- automatic backup before high risk security updates
- compatibility checks where possible
- staged update attempts
- automatic rollback if the update breaks the site
- clear owner notification
- emergency update escalation for critical vulnerabilities
- host level coordination where available
If a vulnerability is being actively exploited, WordPress should not treat the update as just another available plugin update. It should treat it as a site safety event.
3. Temporary Virtual Patching
WordPress should explore a native virtual patching layer for known plugin and theme vulnerabilities. This is one of the most important ideas we should consider.
When a vulnerable plugin cannot be updated immediately, WordPress should be able to apply narrow, temporary protections that block known exploit patterns until the real patch is installed.
That could include protections around:
- dangerous request parameters
- unauthenticated AJAX actions
- vulnerable REST routes
- unsafe file upload paths
- known option changes
- privilege escalation patterns
- SQL injection signatures
- cross site scripting payloads
This does not need to become a full web application firewall inside Core.
But WordPress should be able to receive signed mitigation rules for known vulnerabilities and apply limited, targeted protection.
Patchstack has already shown that vulnerability intelligence and virtual patching can be productized. I'm not saying that WordPress should not copy a commercial service wholesale, but it should recognize the model as essential infrastructure.
4. A Plugin Permission Model
One of WordPress’s deepest security problems is that plugins generally receive enormous trust.
A simple plugin can often touch the database, create users, handle uploads, register REST routes, add AJAX actions, modify options, and execute powerful code.
WordPress needs a permission model that makes plugin capabilities visible and, over time, controllable. Site owners should be able to see what a plugin is allowed to do.
For example:
- Can this plugin create administrator users?
- Can it write files?
- Can it process uploads?
- Can it expose public REST API endpoints?
- Can it modify site options?
- Can it send email?
- Can it execute scheduled tasks?
- Can it access customer or user data?
This would be a major architectural challenge, but WordPress needs to start moving in this direction.
The plugin ecosystem was built for trust. The AI exploitation era requires boundaries.
5. Plugin Isolation and Restricted Execution
WordPress should begin developing ways to isolate risky plugin behavior. Not every plugin needs full access to everything.
Over time, WordPress could introduce restricted plugin modes, stronger sandboxing patterns, safer APIs, and warnings when plugins use dangerous functions or outdated practices. Even partial isolation would help.
A contact form plugin should not casually have the same practical power as a backup plugin, a membership plugin, or an ecommerce plugin. The current all or nothing model is too dangerous for the next phase of the web.
6. Continuous AI Assisted Directory Scanning
If AI tools can be used to find vulnerabilities by attackers, they should also be used continuously by WordPress.org. At a minimum:
- Every plugin and theme in the official directories should be scanned regularly using static analysis, dynamic testing, dependency review, and AI assisted code review.
- New submissions should face stronger security review.
- Existing plugins should be rescanned as models improve.
- Abandoned plugins should be flagged.
- High risk code patterns should trigger warnings or required fixes.
The WordPress plugin directory is not just a marketplace of ideas. It is part of the software supply chain for a large portion of the public Internet. It should be protected like critical infrastructure.
7. Clear End of Life Rules for Plugins and Themes
WordPress needs a stronger policy for abandoned plugins and themes.
If a plugin has not been updated in years, has unresolved security issues, or no longer has an active maintainer, WordPress should make that status more obvious.
Possible labels could include:
- actively maintained
- security maintained
- unmaintained
- abandoned
- removed for security reasons
- replacement recommended
These labels should appear inside the WordPress admin, not only on WordPress.org. A site owner should not discover that a plugin is abandoned only after the site is hacked.
8. Signed Updates for Plugins and Themes
WordPress Core has already taken important steps with signed updates. That same thinking should continue across the plugin and theme ecosystem. Every update delivered through WordPress.org should be cryptographically verifiable. Supply chain security is no longer optional.
If attackers can compromise developer accounts, update channels, build systems, or distribution paths, then plugin and theme updates themselves become an attack surface.
WordPress must make authenticity and integrity part of the update system by default.
9. A Security Event Log in Core
WordPress should include a built in security event log.
At minimum, Core should record:
- plugin installation
- plugin activation
- plugin deactivation
- plugin updates
- theme changes
- administrator creation
- role changes
- failed login spikes
- file editor usage
- critical option changes
- vulnerability notices
- emergency mitigations applied
This does not need to be complicated.
But when something goes wrong, site owners, hosts, and security professionals need a reliable record of what happened.
Right now, too much of that visibility depends on optional plugins.
This Is Not a Criticism of the WordPress Security Team
WordPress has benefited from many dedicated people who have quietly protected the project for years. This letter is not meant to dismiss that work. It is meant to say that the threat model, scale, speed, and the economics all changed in 2026.
A vulnerability that once required a skilled researcher may soon be found by a teenager experimenting with an AI coding assistant. A plugin that sat quietly for eight years may suddenly become the target of automated hacking tools. A weakness that once affected a few sites may be weaponized across the internet in literal hours. The WordPress security model must evolve accordingly.
A Request to WordPress.org
I am asking WordPress.org to make security a central product priority, not a side project, not a plugin recommendation, and not a responsibility quietly passed to site owners, web hosts, or commercial developers/vendors.
WordPress should not expect millions of users to assemble their own security model after installation. The platform itself needs to provide native awareness, clear warnings, safer updates, and meaningful protection when known vulnerabilities put sites at risk.
Before more interface experiments or nonessential initiatives, WordPress should publicly commit to a security roadmap for the AI era.
That roadmap should include:
- native vulnerability awareness
- vulnerability aware automatic updates
- rollback safe patching
- targeted virtual patching
- plugin and theme risk scoring
- abandoned plugin visibility
- stronger plugin directory scanning
- plugin permission transparency
- a Core security event log
WordPress made publishing available to everyone. Now it must make security available to everyone.
The next wave of attacks will not wait for every site owner to become a security expert. WordPress has to carry more of that burden itself.
If WordPress wants to remain the operating system of the open web, security can no longer be treated as something users put together from search recommendations after installation.
Security must become part of what WordPress is.
Respectfully,
Jim Walker
The Hack Repair Guy