We take website security incredibly seriously at SoBold, with many of our clients working across regulated sectors.
Every quarter, Wordfence publishes a threat intelligence report drawn from the millions of WordPress sites their plugin sits on.
The Q1 2026 Wordfence report, published in June 2026, highlighted trends that show the extent to which the enterprise security market has shifted and outlines the approach businesses need to take with regard to managing website security.
The scale of the problem
Between January and March 2026, Wordfence added 2,738 new vulnerabilities to its database.
That was a 23.7% jump on the previous quarter, which itself was up 19.2% on the one before.
Across the Wordfence network in Q1 2026:
- Around 16 billion brute force login attempts were blocked, up 15.3% quarter-on-quarter
- Roughly 9.1 billion attacks were stopped at the firewall layer
- About 474,000 sites were flagged as already infected
At a whole-network level, Wordfence now blocks 55 million exploit attempts and 6.4 billion brute force attacks every month.
The single biggest driver of site compromise is unpatched vulnerabilities in out-of-date plugins.
AI has industrialised attacks on websites; ready-made exploit kits are widely available, and vulnerabilities are being weaponised often within hours of being publicly disclosed.
The gap between disclosure and patch, what we call the exposure window, is where compromise happens, and we ourselves have had many of our clients’ websites attacked.
The top WordPress attack types
The Q1 2026 report ranks newly disclosed WordPress plugin vulnerabilities by category.
The top five WordPress attacks, as of March 2026, are:
Missing Authorisation
Missing authorisation means a plugin exposes an action without properly checking that the person triggering it is allowed to.
The permission check is either missing entirely or only enforced in the admin dashboard, while the underlying request the dashboard makes stays wide open.
Cross-Site Scripting (XSS)
XSS means a plugin lets untrusted input – a form field, a URL parameter, a stored setting – get rendered back into a page without being properly sanitised.
That untrusted input can contain executable code, and once it’s on the page, it runs in the browser of whoever loads it.
PHP File Inclusion
PHP file inclusion means a plugin takes user input and uses it to decide which file the server should load and execute, without properly restricting what that file can be.
If an attacker can influence that decision, they can point the site at a file of their choosing, either one already sitting on the server or, in the worst cases, one hosted elsewhere entirely.
SQL Injection
SQL injection means a plugin takes user input and stitches it directly into a database query, instead of treating it as data. An input can then rewrite the query itself, telling the database to return, change or delete records the original query was never meant to touch.
A single SQL injection flaw in an unmaintained plugin is enough to hand an attacker a full copy of it, or in the worst cases, the ability to overwrite it.
Cross-Site Request Forgery (CSRF)
CSRF means an attacker tricks a logged-in user into unknowingly triggering an action on a site they’re authenticated against.
The plugin fails to verify that the request actually came from a legitimate action the user took (usually because a nonce or token check is missing), so a request forged on an attacker-controlled page is accepted as if the user made it themselves.
Attackers are pushing harder at server-side flaws that give them direct code execution or privilege escalation, rather than the browser-side tricks that used to dominate.
Why the shift toward server-side flaws matters
For enterprise site owners the shift toward server-side flaws changed the risk calculus.
The attackers can end up with access to your web server, where the database, form submissions, uploaded files, and the credentials for any connected system all live.
The recovery, the disclosure and the reputational cost are all an order of magnitude bigger than they were five years ago, and the disclosure obligations under GDPR and sector-specific regulation make the second half of the story public.
The attacker economy has changed too
Patchstack and Wordfence both reported through late 2025 and into 2026 that the window between a vulnerability being publicly disclosed and being actively exploited in the wild has narrowed to a handful of hours in some cases.
Automated tooling scrapes vulnerability databases, wires up an exploit, and starts hitting sites at internet scale before most people have opened their email.
A quarterly or even monthly patching schedule enables an exposure window where your site is unpatched and under threat of being exploited.
Our Cyber Shield SLA, means we are patching our clients on the same day any high or critical vulnerabilities are being flagged. This proactive approach enables sufficient risk management where the window between disclosure and fix is measured in hours, and our clients are being actively watched against every published CVE.
What this means for enterprise WordPress security
Plugins remain the primary attack surface
Reducing the number of active plugins on a site is a start, however, this comes with additional cost in rebuilding this bespoke functionality. Plugins are a great way in enabling ‘out-of-the-box’ functionality, and whilst rebuilding this as bespoke code comes at a cost, the less plugins you have on your site, the better: from both a security point of view and SEO perspective.
Knowing which of your plugins have a track record of missing authorization or file inclusion issues is equally incredibly important.
On our own managed WordPress security work we treat plugin selection and ongoing plugin review as a first-order security decision, not a housekeeping task.
Brute force is only solved if you actually solve it
Sixteen billion blocked login attempts in a single quarter tells you the automated tooling is not going anywhere.
Anything sitting in front of /wp-login.php and /wp-admin, whether that is rate limiting, 2FA, SSO or IP allowlisting for admin roles, is working.
Patch cadence matters more than patch coverage
Proactive patching needs to be a benchmark in how you are managing your WordPress site.
That means a guaranteed monthly baseline patching paired with same-day patching for anything high or critical. This cadence runs on our Cyber Shield SLA service.
The risk profile is shifting toward server-side flaws
The vulnerabilities driving disclosures in 2026 are considerably more severe than the ones that dominated a couple of years ago.
The website needs to be pulled inside the same security governance as the rest of the tech stack, with the same reporting standards as the rest of the cloud estate.
Continuous monitoring of the estate against live vulnerability data
A live inventory of every plugin, theme and core version running across the site, cross-referenced daily against published CVE feeds, enables you to act on a vulnerability the day it is disclosed rather than the next time a review is scheduled.
It also gives you a clear, current picture of your exposure at any point, which is what a CISO, an auditor or a regulator will expect to see if they ask.
A practical framework for 2026
For anyone reviewing their own WordPress security posture this year, we tend to work through five questions with clients.
- Do we have a current, accurate inventory of every plugin, theme and core version running across our sites?
- Is that inventory being cross-referenced against a live vulnerability feed?
- When a high or critical CVE lands against something we run, how long until it is patched in production?
- Do we patch on a fixed cycle, or only when something goes wrong?
- If a site is compromised, who owns the response, and how quickly can they be on it?
For anyone running WordPress at any scale, the Q1 2026 Wordfence data is a useful guide to help manage the security of your estate.
The volume of new WordPress vulnerabilities is rising and the sites getting hurt are usually the ones running unmaintained plugins on infrastructure that was set up years ago and is not proactively managed.
At SoBold, we host and maintain websites in a proactive way that closes off the exposure window between vulnerability disclosure and patch, and the vulnerability categories most likely to be exploited within it.
