Swain-Tech Studio websites for small businesses and independent creatives

WordPress Security Without Plugins

The usual advice for securing a WordPress site is to install a security plugin. That is not wrong, and it addresses the smaller half of the problem.

The numbers are unusually clear here, so let us start with them. Where payroll depends on clocked time, 7-minute rule for payroll is useful background on how small time increments can matter.

What the data says

Patchstack published its State of WordPress Security in 2026 on 25 February 2026. The headline figures:

11,334 new vulnerabilities in the WordPress ecosystem during 2025 — a 42% increase on the previous year.

91% of them were in plugins, 9% in themes. Six were in WordPress core, all rated low risk.

Highly exploitable vulnerabilities rose 113% year on year, and 1,966 — around 17% of the total — were high severity. For an independent reference beyond this site, OWASP is a useful place to compare approaches.

The weighted median time from public disclosure to mass exploitation was five hours. About half of high-impact vulnerabilities were exploited within a day.

46% had no patch from the developer at the moment of disclosure.

Two conclusions follow immediately, and they are not the ones usually drawn.

WordPress itself is not the problem. Six low-risk core issues in a year, on software running a large share of the web, is a good record.

Your risk is a function of how many plugins you run, and the average WordPress installation runs twenty to thirty of them.

Premium does not mean safer

Worth stating because most people assume the opposite.

Patchstack's research into premium marketplaces produced 1,983 valid vulnerability reports for paid or freemium components — 29% of all reports received — and 76% of those were exploitable in real attacks. Their telemetry showed premium components with roughly three times as many known exploited vulnerabilities as free ones.

The explanation offered is scrutiny rather than quality: researchers cannot easily see premium code, so fewer issues are found, and fewer found does not mean fewer present.

Note the interest. Patchstack sells vulnerability protection, so this is a company reporting research that supports buying its product. The data is well documented and widely cited, and it should be read with that in mind — the same standard applied to any vendor's figures.

What actually reduces risk

Run fewer plugins. The single most effective measure, and the only one that is free. Every plugin is third-party code with deep access to your site. Go through the list and remove anything doing a job you could live without, anything you installed to test, and anything superseded by a feature now in core or your theme.

Delete, do not deactivate. Deactivated plugins still sit on the server and can still be exploited.

Turn on automatic updates. With a five-hour median to mass exploitation, waiting until you have time is not a strategy — though not everything deserves the same urgency.

Prefer plugins that are actively maintained and widely used. Check the last update date and whether the developer responds to reports.

Use decent hosting. Though with a caveat: Patchstack's testing found common host and firewall setups blocked only 12% of known exploited WordPress-specific attacks. Hosting helps with the general noise, not with the specific flaw in your contact form plugin. That figure also comes from a company selling virtual patching.

Keep working backups you can restore. Untested backups are hope, not backups. When something does get through, this is what determines whether it is an afternoon or a disaster.

Use strong unique passwords and two-factor on admin accounts. Unglamorous and it prevents the largest category of successful attacks, which is not clever exploitation but guessed credentials.

The awkward part about auto-updates

Automatic updating is the right default and it is not risk-free.

An incident reported in 2026 involved attackers pushing malicious minor updates to plugins — small version bumps containing obfuscated code that created hidden administrator accounts and contacted external servers. Sites applying updates automatically overnight received the backdoor. Detection came about eighteen hours after the initial push and affected plugins were removed within a day and a half.

That is a real argument against blind auto-updating, and it does not overturn the conclusion. A five-hour exploitation window for known vulnerabilities is a far more likely way to be compromised than a supply-chain attack on a plugin you happen to run.

What it does reinforce is the first rule. Every plugin is a channel through which someone else's code arrives on your server automatically. Twenty-five plugins is twenty-five such channels. Eight is eight.

A practical routine

Once, now: audit the plugin list and delete everything not earning its place. Enable auto-updates for core and plugins. Turn on two-factor for administrators. Confirm backups run and restore one to check.

Quarterly: review the plugin list again — they accumulate. Check backups still run. Test the contact form actually sends.

Annually: remove any plugin whose function you have stopped using, and check whether anything you rely on has gone unmaintained.

That is most of it. No security plugin required — though one is a reasonable addition after the list is short, not instead of shortening it.

The one-line version

A security plugin is a plugin. If your answer to plugin risk is another plugin, you have added to the surface you were trying to reduce. Reduce first, then add protection if the site warrants it.

The short version