WordPress Security Checklist for Business Websites

Your business site runs on WordPress. It works, the leads come in, and the dashboard shows a red number next to Plugins that nobody has clicked for a while. Is the site safe, and what should someone actually do each month to keep it that way?

WordPress is still the top choice on hosting in Indonesia, and I still work with it. That is why I treat a plugin update on a live site as real work.

So this is the monthly routine I would run on a business site, with the commands and settings I would use. It starts with two updates that cannot wait for next month.

Which updates do I need right now?

On 22 Sep 2026, WordPress 7.1.2 fixed a flaw in WordPress core. It is CVE-2026-87902, a path traversal through get_page_template(). The flaw has two ratings: WordPress calls it critical, and the NVD record shows 8.1 HIGH (CISA-ADP). NVD data shows fixes back to the 4.7 branch, in 4.7.37. If your site is on 7.1, you need 7.1.2 or later, and if it is on an older branch, take the latest release on that branch.

On 21 Oct 2026, the PHP project fixed two remote code execution flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619. The ratings differ by source. The PHP project scores both 9.2 CRITICAL, while NVD scores CVE-2026-109618 at 9.8 CRITICAL and CVE-2026-109619 at 8.1 HIGH.

These PHP flaws are not in WordPress, and WordPress plans no update for them. Your server needs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The PHP project says the risk is highest for mod_php. PHP 8.1 and older get no project updates, except minimal source backports for 7.4, 8.0 and 8.1, and the release notes say the temporary mitigations do not make an installation safe.

You can see both versions in Tools > Site Health > Info. If you have shell access with WP-CLI, I would check from the server instead:

wp core version
php -v

Why is WordPress a target at all?

WordPress runs 39.6% of all websites, per W3Techs on 27 Oct 2026. It runs 58.3% of sites with a known CMS, per the same page. Anything that common is worth automating attacks against.

Risk comes from four places. Core has its own security releases, as above. Plugins and themes add code from many authors. Hosting decides the PHP version and the server settings. The monthly routine below touches all four.

How do updates work, and what should I update by hand?

WordPress has run background updates since version 3.7, for four types: core, plugin, theme and translation. Since 5.6, new installs auto-update minor and major core releases, while older installs keep their old behavior. So a site set up years ago may not behave like a fresh one. Check your own setting in the update guide.

For plugins and themes, I would update on staging first, click through the pages that make money, then update live.

wp plugin list --update=available
wp plugin update --all

Do my backups actually restore?

A backup you never restored is a guess. Restore one to a staging copy each month, and check that the site loads and that you can log in. The WordPress backup guide covers the files and the database. Both matter, because a database without the uploads folder is a site with no images.

Who still has an account?

Remove accounts nobody uses, and give each person the lowest role that does the job. The intern from two years ago does not need to be an Administrator.

wp user list --role=administrator

Is the login hardened?

Two-factor login is not in core. The wordpress.org Two Factor plugin adds it. Version 0.17.0 has 100,000+ active installs and needs WordPress 7.0 or later. I would also limit failed login attempts, so a password guesser has to be patient as well as lucky.

Which plugins and themes should go?

Delete what you do not use. A deactivated plugin is still code on the server, and it still needs updates you will forget to run. The same goes for the default themes nobody switched to.

Is the PHP version current?

WordPress recommends PHP 8.3 or later. It also recommends MariaDB 10.11+ or MySQL 8.0+, and HTTPS.

Many sites are behind. The wordpress.org stats API shows about 34% of WordPress sites on PHP older than 8.2. That figure is the total of the API values for those versions. Those sites get no fix from the PHP project for the October flaws, except the minimal backports.

Which settings would I harden once?

The Hardening WordPress guide covers file permissions, database security, wp-admin, backups, logging and monitoring. Two settings from that guide go straight into wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

This turns off the theme and plugin editor in the dashboard, so a stolen admin login cannot edit PHP files from the browser. The guide also lets you move wp-config.php one folder above the web root, if your host allows it.

I would also set fresh security keys and salts, serve every page over HTTPS, and add security headers.

What if the site is already hacked?

The wordpress.org FAQ My site was hacked gives the full process. I would start with five steps:

1. Put the site in maintenance mode or take it offline.
2. Change all admin, hosting, database and SFTP passwords.
3. Restore a clean backup from before the hack.
4. Update core, plugins, themes and PHP.
5. Find how they got in before you go live again.

If you skip step 5, the hole that let them in is still open after the restore.

Verdict

WordPress is safe enough for a business site when somebody owns the routine. Update core and PHP for the two flaws above now, then run the same short list each month: updates on staging, a restore test, a user review, a login check, a plugin cleanup and the PHP version. If nobody on your side has the time to own that list, this is how I handle WordPress maintenance.