WordPress Vulnerabilities: The 7 We Find Most Often in Security Audits (and How to Fix Them)

Your website works. Pages load, orders come in, the contact form sends its emails. That doesn't mean it's secure.

A few weeks ago we ran an audit on a WordPress e-commerce store. From the outside, everything looked fine. Looking closer, there were components with vulnerabilities exploitable without even logging in, an admin account belonging to a supplier who hadn't worked with the company in a long time, and a PHP version close to the end of its support. Nothing exotic: it's the picture we find almost every time.

WordPress powers 40% of all websites in the world (W3Techs data, October 2026). That makes it convenient for the people who use it and profitable for the people who attack it: a flaw in a popular plugin is worth thousands of targets in one go. And last year's numbers say the problem is growing.

WordPress vulnerabilities in 2025: the numbers

Patchstack's annual report on 2025 lines up four numbers that should keep anyone running a website up at night:

Five hours. Not exactly "I'll look into it on Monday".

The message is clear: WordPress itself is solid. The risk lies in everything you install on top of it and in how it's configured. Here are the seven vulnerabilities we find most often.

1. Outdated WordPress plugins and themes

This is where almost every attack begins. Page builders, product filters, contact forms, SEO plugins, the payment gateway module: these components sit on a large share of websites, and every one of these categories has seen serious vulnerabilities in recent years.

The most common cause isn't laziness. It's the licence. Many premium themes and plugins only update with an active licence, and that licence has often expired, or it's registered to the agency that built the site years ago. The result: the dashboard flags nothing, the owner believes everything is up to date, and the component stays stuck on a vulnerable version.

This is no minor detail. According to the same Patchstack report, premium components accounted for 29% of vulnerability reports and had three times as many actually exploited vulnerabilities as free ones.

What to do: an inventory of every plugin and theme, with the installed version, the latest available version and the licence holder. Unused ones should be removed, not just deactivated. And every update should be tested on a copy of the site first, one at a time.

2. Forgotten accounts and weak access

Who has admin access to your website today? If the answer is "me and the agency, I think", it's worth checking. In our audits we regularly find accounts belonging to former suppliers, former collaborators, test users nobody ever deleted. Each one is an open door that nobody is watching.

To make things worse, WordPress makes usernames easy to discover by default. Visiting yoursite.com/?author=1 or querying the public API at /wp-json/wp/v2/users is often enough to get authors' usernames. At that point the attacker only needs the password.

And guessing it is often wide open: no limit on login attempts, no second authentication factor, and the XML-RPC interface enabled. The latter is a second door for trying passwords, often missed by the protections placed on the login page, and it has also been used for pingback attacks against other websites.

What to do: revoke accounts that no longer belong to anyone active, block user enumeration, enable 2FA for every administrator (not just yourself), limit login attempts and disable XML-RPC unless an app or integration needs it.

3. WordPress security: configuration left on default

A WordPress installation "out of the box" isn't designed to be locked down, it's designed to run anywhere. Some settings need to be fixed by hand:

• missing HTTP security headers: no protection against clickjacking, content-type sniffing, or resources loaded from unauthorised domains;
• files that reveal versions: readme files, changelogs and meta tags telling anyone which version of WordPress and its plugins you're running, in other words which vulnerability to try;
• cron driven by visitors: WordPress runs scheduled tasks only when someone visits the site. On an e-commerce store that means order emails and queued jobs going out late, or not at all. Moving it to the server's cron makes it reliable, but it has to be done carefully because it touches exactly those functions.

Every hardening measure has a possible side effect. A badly written Content Security Policy, for example, can break the page builder or the checkout. That's why each one has to be enabled, then verified from the outside, then followed by a test purchase.

4. Upgrading PHP on WordPress: the deadline many ignore

PHP is the language WordPress runs on, and every version has an end-of-support date. Today PHP 8.1 and every earlier version no longer receive security fixes. PHP 8.2 will receive them only until 31 December 2026 (official PHP schedule). If your site runs on 8.2 or lower, in less than three months it will be on a platform nobody updates anymore.

The problem is that moving to PHP 8.4 is rarely one click in the hosting panel. Custom themes, child themes, bespoke shortcodes and older plugins can stop working, or worse, half work: the page shows up, the cart doesn't.

What to do: a compatibility analysis before the switch, a staging copy running the new version to compare behaviour, and a plan to roll back within minutes if something goes wrong. If you want to know more about how we handle migrations, it's all on our Modernisation page.

5. Backups nobody has ever tested

"We have a backup." Good. Have you ever restored it?

A backup that has never been restored isn't a backup, it's a hope. We find incomplete backups (files without the database, or the other way round), backups stored on the very server they're supposed to protect, or in formats nobody knows how to bring back to life anymore.

What to do: test a full restore on a separate environment, count the rows of critical tables before and after (users, orders, products), open a real order and check it reads correctly. And time it: that's the number you'll need at the worst possible moment.

6. WooCommerce security: orders, keys and the payment page

On an e-commerce site the stakes go up. Three checks we always run.

Order reconciliation. Compare orders marked as paid with the actual transactions on the payment gateway. Paid orders with no transaction, transactions with no order, or mismatched amounts are a signal not to ignore: they can point to a configuration error, or to something worse.

Key rotation. Gateway API keys, integration tokens, WooCommerce REST keys: if they've been the same for years and have passed through the hands of several suppliers, they need to be changed.

Scripts on the payment page. Skimming attacks (known as Magecart) inject JavaScript into checkout pages to steal the data customers type in. The PCI DSS 4.0.1 standard requires merchants to inventory and authorise every script on payment pages and to detect unauthorised changes (requirements 6.4.3 and 11.6.1, mandatory since 31 March 2025). Even merchants using a bank-hosted payment page or an iframe must confirm their site is not susceptible to script-based attacks. Few online stores know they have to answer that question.

7. The server underneath the site

You can have WordPress configured to perfection and a server that leaves ports, services and access wide open. On a VPS, the operating system, exposed services, SSH access and file permissions are somebody's responsibility. It's often unclear whose.

On shared hosting there's less room to act, but you still need to check the available PHP version, folder permissions and who has access to the control panel.

How we run a WordPress security audit

An audit isn't an antivirus, and it isn't an automated scanner spitting out a list of 200 warnings. It's a reasoned analysis, in three stages.

External, non-intrusive analysis. We look at the site the way an attacker would, without touching anything: components and versions, exposed accounts, configuration, headers, payment page.

A prioritised report. Every finding has a severity and a fix. Vulnerabilities exploitable without authentication come first, then everything else. So you know what needs doing now and what can wait.

Changes with no risk to production. If you decide to go ahead, nothing touches the live site without first going through an isolated staging copy. Updates are applied one at a time, with a test after each. And before every change there's a rollback plan that has been tested, not just written down.

The shop stays open while we work. That's the point.

Compliance (cookies, privacy, consent) is a separate chapter, which we covered in GDPR and cookies in 2026.

Frequently asked questions

Is installing a security plugin enough?

No. A security plugin helps, but it won't update a component with an expired licence, revoke a former supplier's account or migrate PHP. It's one piece, not the solution.

How often should plugins be updated?

As soon as a security fix comes out, and in any case with at least a weekly check. Given how fast exploitation happens, waiting a month is too long. What matters is having a staging copy where you can test the update before applying it to the real site.

How can I tell if my WordPress site is vulnerable?

Some signs you can spot yourself: premium plugins that haven't offered an update in months, admin users you don't recognise, a PHP version of 8.2 or lower. But most vulnerabilities show no symptoms until someone exploits them.

What is a WordPress security audit?

It's an analysis of components, access, configuration, server and, for e-commerce sites, the payment flow. The result is a report that tells you what's at risk, how serious it is and how to fix it.

Security isn't something you add to a website, it's something you build into it. And a site that "works" can keep working right up until the day it stops, usually at the worst possible moment. That's why we offer a free check-up of your WordPress site: an external, non-intrusive analysis that tells you whether you're one of the sites described above. If everything is clean, great. If it isn't, you'll know where to start.

Request your free check-up · Discover our Security Audit service