WordPress Security Hardening: A Business Checklist for 2026

WordPress security hardening is the set of update, access, server and recovery practices that make a site harder to break into and faster to recover when something goes wrong. For a business, the highest-value steps are keeping core and plugins current, enforcing two-factor login for privileged users, putting a firewall in front of the site and keeping tested off-site backups. This checklist is organized so you can assign each section to an owner and verify it.

This article is general information, not a substitute for a professional security assessment of your specific site.

Why WordPress security needs a plan in 2026

The risk is concentrated in plugins and moves fast. Security vendor Patchstack, which sells virtual patching, reported 11,334 new WordPress-ecosystem vulnerabilities in 2025, up 42% from 2024. Of those, 91% were in plugins, 9% in themes and just 6 in core, all low priority (Patchstack, State of WordPress Security in 2026).

Speed is the bigger problem. Patchstack found that 46% of vulnerabilities had no developer fix at the time of public disclosure, that the weighted median time to mass exploitation for heavily exploited vulnerabilities was 5 hours, and that about half of high-impact vulnerabilities were exploited within 24 hours. It also reported that highly exploitable vulnerabilities rose 113% year over year and that 17% (1,966) were high severity (Patchstack).

Core is not immune, either. 2026 brought several significant core security releases:

• WordPress 7.0.2 (July 17, 2026) fixed one critical and one high-severity issue: a SQL injection and a REST API batch-route confusion that could lead to remote code execution. WordPress.org forced auto-updates for affected versions, with fixes also shipped as 6.9.5 and 6.8.6 (CVE-2026-60137 and CVE-2026-63030) (WordPress 7.0.2 release).
• WordPress 7.1.2 (September 22, 2026) fixed a critical unauthenticated local-file-inclusion flaw in template resolution that can lead to remote code execution, backported to all eligible branches through 4.7 (CVE-2026-87902) (WordPress 7.1.2 release).
• WordPress 7.1.3 (October 6, 2026) is the current release, with 7 security fixes and 4 bug fixes (WordPress.org releases).

The takeaway for a business owner: updates are not optional housekeeping, and the window between disclosure and attack can be shorter than a working day.

1. Updates: a nuanced auto-update policy

Updates close known holes, and the right policy balances speed against the risk of breaking something. Only the most recent WordPress version is actively supported, with security fixes backported to eligible branches (WordPress 7.1.2 release).

How WordPress handles updates by default: automatic background updates arrived in WordPress 3.7, minor (security and maintenance) core releases auto-update by default, and major-version auto-updates are on by default only for new installs from WordPress 5.6 onward. Plugin and theme auto-updates can be controlled with the auto_update_plugin and auto_update_theme filters, ideally in a must-use plugin (WordPress Advanced Administration). Since WordPress 5.5, admins can also toggle auto-updates per plugin and per theme in wp-admin (WordPress 5.5 release).

Our recommended split

Published advice disagrees on automatic versus manual updates because both carry risk. A practical middle path for business sites:

Component	Recommendation	Why
Core minor/security releases	Automatic, always	Small, focused fixes; exploitation can be fast
Core major releases	Staging first, then deploy within a set window	New features can affect themes and plugins
Simple, well-maintained plugins	Automatic	Low breakage risk, high exposure if left unpatched
Complex plugins (WooCommerce, builders, memberships, LMS)	Staging first on a fixed short cycle, faster for security releases	Higher chance of breaking checkout, layouts or access rules
Themes	Automatic for well-maintained parent themes when customizations live in a child theme; otherwise staging first	Depends on how much custom code sits on top
Abandoned or unused plugins	Remove	No update can fix code nobody maintains

Set the policy in code (an mu-plugin using the filters above) so it does not depend on someone remembering a toggle. Because many vulnerabilities have no fix at disclosure, updates alone are not enough; that is where the firewall layer comes in.

2. Access: who can log in, and how

Stolen or guessed logins are the other obvious way in, which is why access control matters as much as patching. WordPress's brute-force guidance is direct: "Enable 2FA for all administrators and privileged users." Core has no built-in 2FA, so use a plugin or single sign-on (WordPress brute-force guide).

Access checklist:

1. Enforce 2FA for administrators, editors, shop managers and anyone else with elevated rights.
2. Limit administrators to the few people who manage the site. Give everyone else the lowest role that works.
3. One person, one account. No shared logins, so you can revoke access when someone leaves.
4. Use Application Passwords for integrations. They are built into core, work over HTTPS only and can be revoked individually (REST API authentication).
5. Rate-limit wp-login.php at the WAF, CDN or server level rather than only in a PHP plugin (brute-force guide).
6. Handle XML-RPC. xmlrpc.php is a common brute-force target through system.multicall. "If you don't use XML-RPC, disable it"; if Jetpack or the mobile apps need it, restrict it with WAF rules (brute-force guide).
7. Do not rely on a hidden login URL. It reduces noise but should never be the only defense.
8. Review accounts quarterly and remove ones that are no longer needed.

3. Hardening: server and file settings

Hardening reduces what an attacker can do if they get partway in. These settings come from WordPress's own hardening guide (WordPress hardening guide):

• File permissions: directories 755, files 644, and wp-config.php 400 or 440.
• Disable the dashboard file editor with define('DISALLOW_FILE_EDIT', true); in wp-config.php. This stops admins (or a hijacked admin account) from editing theme and plugin code in the browser, though it will not stop malicious uploads.
• Limit database privileges. Day-to-day, the database user needs only SELECT, INSERT, UPDATE and DELETE. Be careful: revoking DROP, ALTER and GRANT can break upgrades, so coordinate with your developer.
• Moving wp-config.php above the web root is an option, but WordPress describes its benefit as "disputed." Do not treat it as a priority.

Also keep the server stack current. WordPress recommends PHP 8.3 or later and MySQL 8.0+ or MariaDB 10.11+ (WordPress requirements).

Test every hardening change on a staging site first. Permissions and database privilege changes in particular can break updates or uploads in ways that are not obvious until something fails.

4. Network and WAF: stop attacks before they reach WordPress

A web application firewall (WAF) filters malicious requests. WordPress's hardening guide describes WAFs at three levels: a plugin inside WordPress, the server (for example ModSecurity) or a reverse proxy such as Cloudflare or Sucuri (hardening guide).

Do not assume your host already covers this. In Patchstack's penetration test of hosting providers, only 26% of vulnerability attacks were blocked, and just 12% in a separate test using known-exploited vulnerabilities (Patchstack). Patchstack sells a competing protection product, so weigh that context, but the practical lesson holds: ask your host specifically what it blocks, and add a layer if the answer is vague.

A sensible layered setup for a business site:

1. A reverse-proxy WAF or CDN in front of the site, with rate limiting on login and XML-RPC.
2. A lean security or virtual-patching plugin that can cover plugin vulnerabilities before vendors ship fixes (one option among several).
3. HTTPS everywhere, which Application Passwords require anyway.

5. Backups: assume you will need them

Backups are the control that turns a breach from a disaster into an inconvenience. WordPress's hardening guide recommends encrypted, regularly scheduled backups of the full site and the database (hardening guide).

Backup checklist:

• Full-site and database backups on a schedule that matches how often data changes. Stores and membership sites need much more frequent database backups than brochure sites.
• Encrypted, off-site storage in an account the website's credentials cannot reach or delete.
• Several restore points, so you can go back to before an infection that went unnoticed for days.
• A tested restore. Restore to staging periodically and confirm the site actually works.

6. Incident response: decide before it happens

When a site is compromised, decisions made in a panic tend to be the wrong ones. Write a one-page plan now:

1. Who is responsible: the internal owner, the developer or agency, and the host's support contact.
2. Contain: put the site in maintenance mode or block traffic at the WAF.
3. Preserve evidence: take a copy of files, database and logs before cleaning.
4. Rotate credentials: all admin passwords, Application Passwords, database password, hosting and SFTP logins, and the salts in wp-config.php.
5. Clean or restore: restore from a known-good backup, then apply all pending updates before reopening.
6. Find the entry point: a vulnerable plugin, a stolen login or a weak server setting, and close it.
7. Notify customers, payment providers or authorities if personal or payment data may be involved, following legal advice.
8. Review: update this checklist with what you learned.

When this checklist is more than you need

Not every site needs every layer. A small site with few plugins, on good managed hosting, with auto-updates on and 2FA enforced, already covers most of the risk. Start there, then add the firewall, staging workflow and incident plan as the site starts handling orders, members or customer data.

Fewer moving parts also help. Custom code is not automatically more secure, but fewer third-party dependencies means a smaller attack surface. Our advanced WordPress development guide covers how to keep the plugin list short, and custom Gutenberg blocks can replace builder add-ons that each need patching. Going headless with Next.js can reduce what is publicly exposed if the WordPress origin is locked down, but the WordPress back end still needs every item on this list.

If you want this checklist applied and maintained for you, Robustech's WordPress development team handles updates, hardening and backups as part of ongoing site care.