Guide

WordPress security: the practical guide for businesses

By Lucas Weber, CyberSec42 · Updated 22 Oct 2026

Securing WordPress mainly means applying updates reliably, running only necessary and trustworthy plugins, protecting accounts and logins, closing unneeded interfaces, running on current server software and keeping a backup whose restore has been tested. No single security plugin replaces these basics. This guide walks through the eight areas in order, with concrete steps, and ends with a checklist.

Why WordPress sites get attacked

WordPress powers a large share of all websites. That makes it worthwhile for attackers to build tools that automatically scan the internet for sites with a particular flaw. Whether your site belongs to a corporation or a medical practice makes no difference. All that matters is whether the flaw is open.

A compromised site is valuable to attackers in several ways: as a sender of spam links that damage your search rankings, as a redirect to fraudulent pages, as storage for malware, as a source of data from contact forms and customer accounts, and as a stepping stone to other systems on the same server. For you this means downtime, reputational damage, warnings in browsers and search engines and, in some cases, reporting obligations under the GDPR.

The layers of a WordPress site

Every layer is an attack surface of its own. A flaw in a lower layer, like PHP2Shell in October 2026, affects every layer above it.

1. Updates and lifecycle

Most successful attacks exploit flaws for which an update has long been available. The most effective step is therefore a reliable update process, not an additional tool.

• Keep core, plugins and themes up to date. Since version 5.5, WordPress can update plugins and themes automatically. That makes sense for simple sites. For shops and sites with many dependencies, a fixed schedule with a short check after each update works better.
• Use a test environment. Apply larger updates to a copy of the site first. Many hosting providers offer a staging feature for this.
• Spot abandoned plugins. A plugin that has not been updated for years or was removed from the plugin directory no longer receives security fixes. Replace it before a flaw becomes known.
• Delete rather than deactivate. Deactivated plugins and unused themes stay on the server and can still be vulnerable. What is not needed should be deleted.

2. Plugins and their supply chain

Every plugin brings third-party code onto your server with the same rights as WordPress itself. How much the source matters was shown in October 2026 by the Rank Math PRO incident: for several hours, tampered copies containing a backdoor were delivered through the vendor's official update channel. Anyone who updated during that window was affected, despite doing everything right.

• Install only from trustworthy sources. From the official plugin directory or directly from the vendor. "Free" copies of premium plugins from other sources regularly contain malicious code.
• Keep the inventory small. Before each installation, ask whether the feature really needs a plugin. Every plugin saved is one less attack surface.
• Verify files against the original. With WP-CLI, wp core verify-checksums compares core files and wp plugin verify-checksums --all compares plugins from the official directory against published checksums. Premium plugins usually have no such checksums.
• Follow security notices. Keep an eye on the vendor security notices for the plugins you use. An update after an incident fixes the flaw, but does not remove files or accounts that were already injected.

3. Users, roles and login

Stolen, guessed or reused passwords are one of the most common ways into a WordPress site. A few measures have a very strong effect here.

• Introduce two-factor login. For every account with administrator or editor rights. This stops most password attacks, even if a password has leaked.
• Grant rights as needed. WordPress has roles from subscriber to administrator. Someone who only writes posts does not need administrator rights. The fewer administrators, the smaller the damage from a stolen account.
• No shared accounts. Every person and every agency gets their own account. Only then can you trace who changed what, and only then can you revoke one person's access.
• Revoke access when people leave. Former employees, freelancers and previous service providers often still have accounts. Review the user list once a quarter.
• Do not expose usernames. By default, WordPress reveals login names through author pages and the REST API (/wp-json/wp/v2/users). This output can be disabled for visitors who are not logged in.
• Limit login attempts. Lock the login briefly after repeated failures, via a plugin or at server level.
• Keep application passwords in view. Since WordPress 5.6, accounts can create application passwords for interfaces. Revoke the ones no longer in use.

4. Interfaces and configuration

WordPress ships with features that many sites do not need, but that help attackers.

• Disable XML-RPC if nobody uses it. xmlrpc.php is an older interface that lets many passwords be tried in a single request. If it is not needed, for example for an older app or certain extensions, block it.
• Disable the file editor in the admin area. With define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php, plugin and theme files can no longer be edited from the admin area. A stolen administrator account then cannot insert malicious code in three clicks.
• Turn off error output in production. WP_DEBUG belongs on false on the live site. Otherwise error messages reveal paths and versions.
• Set security keys. The salts in wp-config.php must be unique. After an incident they are renewed so that all existing logins become invalid.

5. Server, PHP and hosting

WordPress is only as secure as the server it runs on. How important that is was shown in October 2026 by PHP2Shell: two critical flaws in PHP itself that affect every WordPress site, regardless of plugins.

• Run a supported PHP version. Which branches still receive security updates is listed on php.net. WordPress shows the version actually running under Tools, Site Health, Info, Server. Your hosting panel may differ.
• No PHP execution in the uploads folder. wp-content/uploads is for images and documents, not programs. A server rule that forbids PHP execution there neutralises many uploaded backdoors.
• Encrypted access. HTTPS for the whole site, SFTP instead of FTP for file access. Plain FTP sends passwords in clear text.
• Separate sites from each other. If several websites share one hosting account, a compromised site can take the others with it. Important sites belong in separate accounts or environments.
• Do not open file permissions too wide. Write access only where WordPress needs it. wp-config.php should not be readable by other users on the server.

6. Backups and restore

A backup is the insurance for when everything else fails. But it only helps if it meets three conditions.

• It is stored elsewhere. A backup on the same server is lost with the server and can be altered by the attacker. At least one copy belongs in a separate location.
• It goes back far enough. Many intrusions are only noticed after weeks. If you keep only the last seven days, you may be left with nothing but compromised copies.
• The restore has been tested. Once a year, better after every major change, actually restore the backup into a test environment. Only then do you know it is complete and how long a restore takes.

7. Monitoring

No protection is complete. What matters is noticing an intrusion quickly, not when customers call or the browser shows a warning.

• Monitor file changes. New or changed PHP files outside an update are the clearest warning sign.
• Get alerts for new administrator accounts. An attacker almost always creates an account of their own.
• Check availability and content. A monitor that checks not only whether the site responds but also whether the expected content is served will notice redirects and injected spam pages.
• Set up Search Console. Google reports security issues and hacked content it finds on your site there.

8. The incident plan

When it happens, order matters: preserve evidence first, then clean up, then change all credentials and return to a clean state. We describe the individual steps, including the question of reporting obligations, in the section "Suspected compromise". Decide in advance who makes decisions in an emergency, who has access to hosting and backups, and how to reach your provider. There is no time for that during an incident.

The checklist

Do it yourself or have it managed?

Much of this list is one-off work: cleaning up plugins, introducing two-factor login, closing interfaces, checking server settings. Other parts never stop: updates with checks, monitoring, restore tests and a quick response when a warning like PHP2Shell arrives.

For companies that do not want to keep track of this themselves, we offer both. A one-off hardening that checks and secures your site against this checklist, within a scope agreed in writing. And ongoing care that takes over updates, monitoring and restore tests, and checks whether your site is affected when new security warnings appear. We tailor the scope to your site and prepare an individual offer.

Frequently asked questions

Further reading

• Content Security Policy and security headers
• Website hacked? What to do first, a guide for small businesses
• Small business website security: a checklist you can run yourself
• PHP2Shell: What the critical PHP flaws mean for WordPress sites
• Vulnerability Assessment: what it is and when you need one
• Penetration Testing: Process, Duration and What It Costs
• Service: penetration testing with verified findings

Sources

• WordPress Developer Resources: Hardening WordPress
• WordPress Developer Resources: Backups
• WP-CLI: wp plugin verify-checksums
• php.net: Supported Versions