WordPress Isn't a Website. It's a Patch Management Emergency With a Blog Attached.
Tuesday 7 April 2026
I moved away from WordPress years ago. Not because I am precious about open-source software. Not because I have something against Matt Mullenweg. Because when I sat down and honestly priced what running a WordPress site securely actually costs, the numbers only made sense if someone, somewhere, was eating the risk without telling the client.
This week, that risk has a name: CVE-2026-0740.
What Actually Happened
The Ninja Forms File Upload plugin, installed on approximately 50,000 WordPress sites, contains a critical vulnerability that allows anyone on the internet to upload a malicious PHP file to your web server without a username, without a password, and without any prior access to your site whatsoever.
The technical term is Unauthenticated Arbitrary File Upload. The practical translation is: a stranger types a URL, your server obediently hands over the keys, and they now own it.
The CVSS severity score is 9.8 out of 10. Maximum is 10. This is not a medium-risk edge case that requires a chain of unlikely conditions. This is a straightforward, reliable, widely automatable attack against a contact form plugin.
Here is the timeline that should bother you. The vulnerability was discovered by security researcher Sélim Lanouar, who earned a $2,145 bug bounty for reporting it to Wordfence. Wordfence rolled out firewall protections for premium users on 8 January 2026. Free users got those protections on 7 February 2026. The plugin developers released a partial fix in version 3.3.25, then a complete patch in version 3.3.27 on 19 March 2026.
Today is 7 April 2026. Approximately 50,000 sites are still running the vulnerable version.
That gap between “patch available” and “patch applied” is not a mystery. It is WordPress working exactly as designed.
The Structural Problem Nobody Wants to Name
I want to be precise here, because the lazy version of this conversation is “just keep your plugins updated” and that is not sufficient, honest, or useful advice.
The WordPress plugin ecosystem contains over 59,000 plugins in the official repository. A fresh WordPress installation typically runs somewhere between 10 and 30 of them. Each one is a separate codebase, maintained by a separate developer or team, with its own patching cadence, its own security practices, and its own relationship with disclosure.
Patchstack, which operates the largest WordPress vulnerability disclosure programme in the world, identified 6,700 new vulnerabilities in the WordPress ecosystem in just the first six months of 2025. That is not 6,700 across the entire year. That is six months. 41% of those vulnerabilities were classified as exploitable in real-world attacks based on their own priority scoring, up from 30.4% the previous year.
Data from thousands of WordPress installations confirmed that 92% of all successful WordPress breaches in 2025 originated from plugins and themes, not the core software itself.
Let that sink in. Nine out of ten successful attacks on WordPress sites come through the add-ons. The base platform could be bulletproof, and it would not matter, because the attack surface is not WordPress: it is the 15 plugins your web agency installed when they built your site three years ago and have not comprehensively audited since.
The Recent History Is Not Ambiguous
This is not the first time we have had this conversation. It will not be the last.
In January 2026, CVE-2025-14533 was disclosed in the Advanced Custom Fields Extended plugin, used on over 100,000 WordPress sites. Privilege escalation to full administrator access. CVSS 9.8. Unauthenticated. Nearly half of the installed base reportedly remained exposed at the time of reporting, despite a patch being available within four days of disclosure.
In late 2025, CVE-2025-8489 in King Addons for Elementor allowed unauthenticated attackers to register as administrators. Wordfence blocked over 48,400 exploit attempts after the flaw was publicly disclosed, with mass exploitation beginning on 9 November 2025. Over 10,000 active installs. The attacks were automated. The scanning started within days of public disclosure.
Before that: WP File Manager, 700,000 active installations, unauthenticated RCE, CVSS 9.9. Elementor Pro, 5 million active installations, unauthenticated RCE, CVE-2024-28847.
This is not a list of unlucky one-offs. This is a recurring pattern across the most popular plugins in the ecosystem. The plugins with the most users are the most attractive targets. They are attacked first and hardest. And the window between disclosure and mass exploitation is measured in hours, not weeks.
What “Keeping Plugins Updated” Actually Means in Practice
Here is what responsible WordPress management genuinely looks like, since nobody seems to want to say it plainly.
You need automated vulnerability monitoring across every plugin and theme installed on the site. You need a web application firewall, configured correctly, with rules updated in near-real-time. When a critical vulnerability is disclosed, you need to be applying the patch or mitigation within 24 to 72 hours, not at the next quarterly review. You need to be auditing your plugin list regularly and removing anything that is unused, abandoned, or unmaintained. You need staging environments so you can test updates without breaking the live site. And you need someone who knows what they are doing reviewing all of the above on an ongoing basis.
That is not a website. That is a security operations programme that also publishes your blog.
How many small businesses have that? How many web agencies are delivering that to their clients? How many business owners were told, when they signed up for their “affordable WordPress website,” that this was the ongoing commitment they were taking on?
I know what the answer is, because I have spent years clearing up the mess when that conversation did not happen.
The Uncomfortable Question for Your Web Agency
If your website runs on WordPress and you have a web agency managing it, I would like you to ask them three questions this week.
First: how do you monitor for critical plugin vulnerabilities, and how quickly do you apply patches when CVSS 9.0 or above flaws are disclosed?
Second: is a web application firewall configured in front of our WordPress installation, and who manages its rule updates?
Third: when did you last audit the complete plugin list on our site and remove anything that is unused or no longer actively maintained?
If the answers are vague, involve a quarterly schedule, or include the phrase “we check when we can,” you have the information you need about the actual security posture of your website. Your website is either a liability you do not fully understand yet, or your web agency is eating a risk they have not priced correctly.
Neither of those is a comfortable situation.
The Alternatives Actually Exist Now
I want to head off the “but what else would we use” objection, because it is a reasonable question and deserves a straight answer.
For a typical UK SMB website: a content-managed, editable, professional business site with contact forms, service pages, and a blog, the realistic alternatives to WordPress are not a compromise. Managed website platforms with no plugin ecosystem, static site generators with a content management layer, and modern hosted website builders have all matured significantly. They do not carry an attack surface made up of tens of thousands of third-party codebases. Updates are handled at the platform level. There is no plugin repository to monitor.
The objection I hear most often is that switching is expensive. It can be. But compare it honestly to the cost of a properly managed WordPress installation including security tooling, monitoring, and emergency incident response. Then compare it to the cost of a successful attack on an unmanaged one.
The economics of WordPress make sense for organisations with dedicated development resource and security tooling. They make less sense for a fifteen-person professional services firm running a site that someone’s nephew set up in 2021 and nobody has properly looked at since.
How to Turn This Into a Competitive Advantage
If your business website is secure and well-maintained, and your competitors’ are not, that is a differentiator you can actually talk about.
Increasingly, B2B procurement processes include questions about the security of an organisation’s digital infrastructure. Regulated sector clients want to know about your website security posture as part of supplier due diligence. Cyber insurers are starting to ask about CMS platform and patch management cadence as part of underwriting.
Being able to say “our website is built on a platform with no third-party plugin ecosystem and managed updates” is a simple, verifiable, non-technical statement that positions your business as one that takes its digital security seriously. That is worth something.
How to Sell This to Your Board
The board conversation about website security tends to go one of two ways. Either the website is treated as a marketing asset with no security implications, or security is treated as the IT department’s problem with no business implications. Both framings are wrong.
A compromised WordPress website can be used to deliver malware to your site’s visitors, including your clients. It can be used to exfiltrate any data stored in or accessible from the web server. It can be used to send spam at scale using your domain name, destroying your email deliverability and reputation. And the ICO has been clear: if a breach occurs through inadequate technical measures on a platform under your control, including your website, you may have a notification obligation under UK GDPR.
Three arguments that land at board level:
First, reputational risk is not abstract. A compromised website that serves malware to clients is not an IT incident. It is a client relationship incident with potential legal consequences.
Second, the liability question is real. If your web agency has been charging for “maintenance” without delivering genuine vulnerability management, the conversation about who bears responsibility for a breach is an uncomfortable one. Get the answer before you need it.
Third, the cost of doing this properly is knowable and bounded. The cost of recovering from a successful attack is neither knowable nor bounded.
What This Means for Your Business
1. Check your CMS and plugin versions now. If your site runs WordPress and includes the Ninja Forms File Upload plugin, confirm you are running version 3.3.27 or above. If you do not know how to check this, ask your web agency in writing and document the response.
2. Ask your web agency directly about their vulnerability management process. The questions are above. Get written answers. If the answers are unsatisfactory, you have a conversation to have about whether the current arrangement is fit for purpose.
3. Run a plugin audit. Ask for a complete list of every plugin installed on your WordPress site, when each was last updated, and when each was last reviewed for active maintenance. Deactivate and delete anything that is unused. Unmaintained plugins with no active developer are a standing risk with no corresponding benefit.
4. Implement a WAF if you do not already have one. Wordfence provides protections for premium subscribers faster than free users, as this incident demonstrated. The gap between premium and free protection during the Ninja Forms window was 30 days. A web application firewall is not optional infrastructure for a business WordPress installation.
5. Have the platform conversation properly. If your website is due for a redesign in the next 12 to 24 months, evaluate non-WordPress alternatives seriously. Ask your agency or developer to present the security maintenance requirements of any platform they propose, alongside the build cost. If they cannot or will not answer that question, that is useful information too.
Related Posts: