In short: The main risk to a WordPress site is not WordPress itself but its plugins. According to Patchstack’s 2026 report, 91% of new vulnerabilities in 2025 were in plugins, and for heavily exploited vulnerabilities the first attacks came a median of about 5 hours after disclosure. Hosting alone does not stop most of these attacks. Security comes from regular maintenance: updates, removing what you do not need, backups with restore tests, secure access and monitoring.
Where does the risk to WordPress sites come from?
Patchstack, a company that collects vulnerability data and sells WordPress protection, published its annual report on 25 February 2026. The figures come from a security vendor’s report, so read them as such, but the picture is clear:
- Volume: 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, 42% more than in 2024.
- Plugins: 91% of new vulnerabilities were in plugins and 9% in themes.
- WordPress core: only 6 vulnerabilities, all low priority.
- No fix: for 46% of vulnerabilities, the developer had not released a fix by the time they were publicly disclosed.
- Premium plugins: the report notes a high share of serious vulnerabilities in paid components too, so “paid” does not mean “safe”.
What does that mean for your business? Every plugin is third-party code running with full access to your site. A site with 40 plugins has 40 separate sources of risk, each with its own developer and its own pace of fixes.
How fast are vulnerabilities exploited?
Often faster than the site gets updated. According to Patchstack, around half of high-impact vulnerabilities are exploited within 24 hours of disclosure. When the intensity of attacks is taken into account, the median time to first exploitation for heavily exploited vulnerabilities is 5 hours.
Old vulnerabilities do not go away either. Patchstack’s list of vulnerabilities that saw heavy attack activity in 2025 includes ones disclosed in 2023 and 2024, still being exploited because many sites still run the old plugin versions.
That is the difference. Updating “once a month, when there is time” leaves a site exposed for weeks, and automated attacks do not wait.
Why is hosting alone not enough?
Good hosting matters, but it protects the server, not the application. The official WordPress hardening guide notes that hosting companies are generally responsible for the infrastructure, not for the application you choose to install.
Patchstack tested how many attacks on WordPress vulnerabilities are stopped by common defences such as hosting firewalls (WAF) and services like Cloudflare. In the first test, focused on vulnerabilities known to be exploited, only 12% of attacks were blocked. In the second, broader test, 26% were blocked.
The reason is that many attacks on plugins look like normal traffic. The category of vulnerability exploited more than any other in 2025 relates to access control, where the attacker’s request looks like an ordinary action by a logged-in user.
ScaleLab tip: Ask your hosting company in writing what exactly it covers: does it update plugins, does it keep backups off the same server, and who restores the site after a breach. That way you know which tasks are left to you.
Which maintenance routine protects the site?
No single measure solves everything. What works is a combination of a few simple habits carried out regularly.
1. Set an update policy
Since WordPress 5.5, administrators can switch on automatic updates for each plugin and theme individually. WordPress runs automatic updates twice a day and by default sends an email when an update succeeds or fails.
We recommend splitting plugins into two groups. For simple, widely used plugins, switch on automatic updates. For those that orders or the enquiry form depend on, test the update on a staging copy first, but within hours or days, not weeks. When a serious vulnerability is published, update immediately.
2. Remove unused plugins and themes
The official WordPress guide is clear: if you are not using a plugin, delete it. A deactivated but undeleted plugin stays on the server. Also remove inactive themes, except one fallback, and plugins whose developers have long stopped releasing updates.
3. Back up and test the restore
Keep regular copies of the whole site, files and database, somewhere trusted and off the same server. A backup nobody has ever restored from is just a hope. At least once a quarter, restore the site to a test environment and check that forms and orders work.
4. Secure access
- Passwords: long, generated passwords for every administrator, not reused in other systems.
- Two-factor authentication (2FA): the WordPress guide recommends it as an extra layer. Switch it on at least for all administrators.
- Least privilege: everyone gets only the role they need. Former employees and agencies are removed on the day the work with them ends.
5. Monitor the site
Check that the site is up, whether new administrators or unknown files have appeared, and whether Google Search Console reports security issues. Subscribe to vulnerability alerts for the plugins you use, so you hear about a problem before attackers act on it.
6. Add virtual patching or a web application firewall (WAF)
A web application firewall filters traffic before it reaches the site. Virtual patching adds a rule that blocks a specific vulnerability until the developer releases a fix. It is a useful extra layer, especially for vulnerabilities with no fix yet, but it does not replace updates and backups.
7. Prepare an incident plan
Decide in advance what happens if the site is breached. Who is the first person you call, and how do you reach them out of hours? Which backup do you restore from, and how do you confirm it predates the breach? Which passwords are changed immediately, how are new administrators and unknown files found, and who informs customers if personal data is affected? Write the answers on a single page. During an incident, nobody has time to work them out.
Who is responsible for the site’s security?
Often the problem is not technical but organisational: everyone assumes someone else is taking care of it. Put responsibilities in writing.
| Role | Responsible for |
|---|---|
| Hosting company | Server, network, infrastructure availability |
| Site developer | Code quality and plugin choice during the build |
| Site maintenance | Updates, backups, monitoring, incident response |
| Business owner | Who has access, accepting risks, maintenance budget |
If your company falls within the scope of the new cybersecurity rules, management responsibility becomes a legal matter too. You will find more in the article on NIS2 requirements. If you are not sure what state your site is in today, start with the free audit.
ScaleLab tip: List all your plugins in three columns: what it does, who installed it and when it was last updated. Plugins where nobody can answer the first question are the first candidates for deletion.
That is how work on website hosting and maintenance is organised: software and plugins are updated, security fixes are applied promptly, backups are kept, and the site is monitored around the clock so problems are spotted before customers notice.
Frequently asked questions
Is WordPress secure?
WordPress core has very few vulnerabilities: according to Patchstack, only 6 in 2025, all low priority. The risk comes mainly from plugins and themes, so a site’s security depends on which plugins you use and how quickly you update them.
Is it enough to switch on automatic updates?
Automatic updates shorten the time a site is exposed, but they do not solve everything. Almost half of vulnerabilities have no fix at the time they are disclosed, so you also need backups, monitoring and an extra layer of protection.
Our hosting has a firewall. Why do we need anything else?
Hosting-level defences stop only some attacks on plugins: between 12% and 26% in Patchstack’s tests. The host is responsible for the server, while the application and its plugins remain your responsibility.
How often should we back up?
It depends on how often the site changes: an online store with daily orders needs more frequent backups than a company website. More important than frequency is that the backup is kept off the same server and that restoring from it has been tested.