In 2025, 11,334 new vulnerabilities were published in the WordPress ecosystem, 42% more than the year before. The count comes from Patchstack's annual report: 91% were in plugins, 9% in themes, and WordPress core had just 6, all low priority. 46% went public before a fix existed, and for the most heavily targeted flaws the median time from disclosure to mass exploitation was 5 hours.
WordPress runs 39.6% of all websites (W3Techs, figure as of 22 October 2026), so a flaw in a popular plugin opens up thousands of sites at once. The core holds up; the risk is in what gets installed on top of it and how it's configured.
1. Outdated WordPress plugins and themes
A plugin often falls behind because of its licence. Many premium themes and plugins only download updates with an active licence: if it has expired, or it's registered to the agency that built the site years ago, the dashboard flags nothing and the component stays on a vulnerable version. Patchstack's report also found that premium and freemium components produced 29% of valid vulnerability reports and had three times as many actually exploited vulnerabilities as free ones.
Make an inventory with the installed version of every plugin and theme, the latest available version and who holds the licence. Delete the ones you don't use instead of leaving them deactivated. Test updates on a copy of the site, one at a time, so if something breaks you know which one did it.
2. Forgotten accounts and weak access
Who has admin access to your site today? Accounts belonging to former suppliers and former collaborators stay active until someone deletes them. Usernames are easy to find, too: opening yoursite.com/?author=1 or reading the public API at /wp-json/wp/v2/users is often enough. If the site doesn't limit login attempts or ask for a second factor, the password can be guessed indefinitely, and XML-RPC (xmlrpc.php) offers a second way in that often slips past the protections placed on the login page.
Remove the accounts of people who no longer work with you, block user enumeration and turn on 2FA for every administrator, not just yourself. Then limit login attempts and switch off XML-RPC unless an app or integration needs it.
3. WordPress security: default configuration
A fresh WordPress install is built to run on any host, and some things have to be locked down by hand. HTTP security headers are missing: the ones that protect against clickjacking and tell the browser which domains it may load scripts from. Readme files, changelogs and the generator meta tag tell anyone which version of WordPress and its plugins you're running, which is to say which flaw to try.
WordPress runs scheduled tasks only when someone visits the site. On a shop, that means order emails and queued jobs going out late, or not at all. The official documentation explains how to switch it off with define( 'DISABLE_WP_CRON', true ); in wp-config.php and have the server's cron call wp-cron.php instead. After the change, place a test order, as you should after any hardening work: one badly written Content Security Policy is enough to break checkout.
4. Upgrading PHP on WordPress: the overlooked deadline
PHP 8.1 and earlier no longer get security fixes, and PHP 8.2 gets them until 31 December 2026 (official PHP schedule). What changes on 1 January and which version to move to is covered in PHP 8.2 loses security fixes on January 1.
Moving to PHP 8.4 is rarely one click in the hosting panel. Custom themes, hand-written shortcodes and older plugins can stop working, or half work: the page loads, the cart doesn't. Start with a compatibility check, then try the new version on a staging copy, with a way to roll back within minutes.
5. Backups nobody has tested
A backup that has never been restored may hold the files without the database, or sit on the same server it's meant to protect. Test it on a separate environment: a full restore, a row count of users, orders and products before and after, and a real order opened to see that it reads correctly. Time it: that's how long the site will be offline if it ever breaks.
6. WooCommerce security: orders, keys and payments
On an online shop, compare the orders marked as paid with the transactions on the payment gateway. A paid order with no transaction, or with a different amount, can be a configuration error or something worse. Gateway keys and WooCommerce REST keys that have been the same for years and passed through several suppliers should be changed.
Skimming attacks, known as Magecart, inject JavaScript into the checkout to copy what customers type. That's why PCI DSS requirements 6.4.3 and 11.6.1 call for payment page scripts to be authorised, checked for integrity and monitored for tampering, and they have been mandatory since 31 March 2025. Using the bank's hosted payment page or an iframe doesn't get you out of it: to qualify for the simplified SAQ A questionnaire, you have to confirm your site is not susceptible to script-based attacks (Report URI's FAQ explains it in plain English).
7. The server underneath the site
On a VPS, the operating system, exposed services, SSH access and file permissions are somebody's responsibility, and it's often not written down whose. Shared hosting leaves less to do, but you should still check the PHP version and who can log in to the control panel.
How we run a WordPress security audit
We start from the outside without touching anything, looking at the site the way an attacker would. In the report every finding has a severity and a fix, and flaws exploitable without logging in go at the top. If you go ahead, nothing reaches the live site without first going through an isolated staging copy, updates go in one at a time with a test after each, and we test the rollback before we start. The shop keeps selling in the meantime.
Frequently asked questions
Is a security plugin enough?
It helps limit login attempts and shows you what's happening, but it won't update a plugin with an expired licence or delete a former supplier's account.
How often should plugins be updated?
As soon as a security fix comes out, and in any case with a weekly check: given the exploitation times above, a month is too long.
If you want to know where your site stands on these seven points, get in touch: we'll run a free check-up from the outside, without touching anything, and tell you where to start.
Request your free check-up · Discover our Security Audit service
Get the next article on security and compliance
Flaws to patch, GDPR deadlines, scams going around: you hear about it as soon as we write.