12 WordPress Security Steps for Business Websites (October 2026)

The first WordPress security step is making sure your server runs a PHP version that still gets security fixes and includes this week's patch: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later release. The PHP project released those on 21 October 2026 to fix two flaws that, in its security advisory, "can allow unauthenticated remote code execution". Singapore's Cyber Security Agency issued its own alert the same day, summed up in two words: "Patch immediately."

Older branches are the problem. PHP 8.1 and older got no release from the PHP project. Its security team published minimal source backports for 7.4, 8.0 and 8.1 for people who compile PHP themselves, some Linux distributions and paid support vendors ship their own, and PHP 7.3 and older got nothing. WordPress.org's usage figures on 23 October showed about 36% of WordPress sites on PHP 8.1 or older, and almost 24% on PHP 8.2, which loses security support on 31 December 2026.

To see your version, go to Tools, then Site Health, then the Info tab, and open Server. Read it as the branch, not the patch. Site Health only checks the branch: on 23 October it still rated an unpatched PHP 8.3.20 as recommended. The number can mislead the other way too, because patched builds from Linux vendors keep their old numbers. Ubuntu 22.04's fixed PHP still reports 8.1.2, and CloudLinux's patched alt-php 8.5 reports 8.5.11-5. The definitive answer is your host's or vendor's changelog, or a written reply from your host. My guide on how to check your website's PHP version covers the other ways to find it, and if you can't get a straight answer, the free check further down is there for exactly this.

WordPress itself recommends PHP 8.3 or greater. On shared hosting, the host installs PHP patches and your job is to keep the site on a supported branch. On a VPS or cloud server, someone has to install the update and restart PHP, and on a lot of small business servers that someone was never named. My guide to updating PHP in WordPress without breaking the site covers the safe order: backup, staging copy, update, test, then switch the live site.

Keeping WordPress core updated means running the current release, 7.1.3 on 23 October 2026, and leaving automatic background updates switched on so security releases install without waiting for you. WordPress has applied minor and security releases automatically since version 3.7, according to its upgrade documentation.

Two habits quietly break that. A developer switches automatic updates off in wp-config.php to avoid surprises, then moves on. Or a site sits two major versions behind because the theme or page builder "isn't ready" for the new one. wp2shell showed why the first habit matters: the fix reached every site that accepted automatic updates and skipped the ones that didn't.

Test major versions (7.0 to 7.1) on a staging copy first if the site runs a shop, bookings or a heavily customised theme. Point releases like 7.1.x are mostly bug and security fixes. Let them install.

WordPress plugins and themes should be updated within a few days of any security release, because they accounted for practically all of the 11,334 WordPress vulnerabilities Patchstack logged in 2025, and attackers move within hours.

Since WordPress 5.5 you can turn auto-updates on plugin by plugin from the Plugins screen. I switch them on for small, well-kept plugins such as a contact form, an SEO plugin or a cache plugin. I leave them off for the parts that can take a business offline: WooCommerce and its payment add-ons, page builders and anything custom. Those get updated on a staging copy first, inside the week.

Paid plugins and themes are the usual blind spot. A premium theme bought in 2019 usually stops updating when its licence lapses, and WordPress barely mentions it. Check that every paid plugin and theme still has an active licence, or plan to replace it.

Delete every plugin and theme you aren't using, and replace any plugin that hasn't been updated in about a year, because unused and abandoned code still sits on your server where an attacker can reach it. WordPress's own hardening guide says it plainly: "if you are not using a specific plugin, delete it from the system."

Deactivating isn't enough. A deactivated plugin's files stay on the server, and some plugin files can be requested directly by URL whether WordPress has the plugin switched on or not. Keep one current default theme as a fallback and delete the other themes you don't use.

To spot an abandoned plugin, open its page on WordPress.org and look for:

• a banner saying it "hasn't been tested with the latest 3 major releases of WordPress"
• a notice that the plugin has been closed and is no longer available to download, which sometimes follows an unfixed security report
• no update in 12 months or more, and support threads nobody answers
• a slider or page builder your developer added years ago that now blocks a PHP upgrade

If a plugin's developer has walked away, every future hole in it stays open. Swap it for a maintained one, or drop the feature.

Two-factor authentication (2FA) means a stolen or guessed password isn't enough to log in, and it should be on for every account that can install plugins or edit pages. WordPress doesn't ship with 2FA, but adding it costs nothing.

• Two Factor, a free plugin maintained by WordPress contributors with 100,000+ active installs, supports authenticator apps, email codes and backup codes.
• Wordfence and Kadence Security both include 2FA in their free versions. If you already run one of them, use its 2FA rather than adding another plugin.

Use an authenticator app over email codes where you can. An emailed code only helps if the inbox is better protected than the website, and for plenty of small businesses the shared office Gmail isn't.

Everyone who touches the site should have their own named account with the lowest WordPress role that lets them do their job, and anyone who leaves should be removed the same week. WordPress has five standard roles: Administrator, Editor, Author, Contributor and Subscriber. One or two people need Administrator. Most need Editor or less.

A common setup on Singapore SME sites: one shared "admin" login created by whoever built the site in 2019, still active, its password known to three former staff and a freelancer nobody can name. Delete it. Create named accounts, make your marketing person an Editor, and keep Administrator for the owner and whoever maintains the site.

Open Users in the dashboard now and sort by role. An Administrator account you don't recognise is one of the clearest signs a site has already been broken into.

A useful WordPress backup is stored away from your web server, goes back several weeks, and has been restored at least once to prove it works. Backups kept on the same server or hosting account can be deleted or infected along with the site.

Your host's backups are a good start, so find out how many days they keep and whether you can restore one yourself. Then keep your own copy somewhere else. UpdraftPlus in its free version can send scheduled backups to Dropbox, Google Drive or Amazon S3. Keep at least 30 days, because a hack is often noticed weeks after it happened, and last night's backup may already contain the malware.

Once a quarter, restore a backup onto a staging copy and click around. An untested backup is a hope. If your site stores contact form entries or orders, those backups hold personal data under Singapore's PDPA, so keep them in a business account with 2FA on, not someone's personal Dropbox.

A cloud web application firewall (WAF) filters attack traffic before it reaches your server, which is why it was one of the few layers that could act on PHP2Shell before PHP did. Cloudflare says that from 03:02 UTC on 21 October, about 9 hours before public disclosure, customers on its free or paid WAF were protected by default, and Free plan users didn't have to do anything. Sucuri says it added virtual patching rules for known PHP2Shell attack paths to its firewall.

Both vendors still tell you to patch PHP. Cloudflare says request data alone doesn't always tell an exploit apart from normal traffic, and it saw attackers changing their payloads to get past its rules. CISA's alert of 21 October says a WAF "may provide some protection until systems are updated or patched". Sucuri adds a point most guides miss: a firewall only helps if attackers can't reach your server directly, so the server should accept web traffic only from the firewall.

Cloudflare's Free plan includes its free managed rules; on paid plans, check that the Cloudflare Managed Ruleset is deployed and set to block. Pro is US$20 a month billed yearly (US$25 billed monthly) and Business US$200 a month billed yearly. Sucuri's firewall starts at US$9.99 a month. My guide to whether a small business needs a web application firewall walks through the choice.

One well-maintained WordPress security plugin adds login protection, malware scanning and alerts about vulnerable plugins, but it runs inside PHP, so it can't be your defence against a flaw in PHP itself. Pick one and set it up properly. Two security plugins on one site tend to fight each other.

• Wordfence (5 million+ active installs): firewall, malware scanner and 2FA in the free version, which gets new firewall rules and malware signatures 30 days after paying customers. Premium is US$149 a year per site.
• Kadence Security, sold as Solid Security until recently and iThemes Security before that: free 2FA, brute-force protection and a vulnerability scan four times a day. Its paid features, including Patchstack virtual patching, now come inside Liquid Web's Kadence bundles rather than as a standalone plugin.
• Patchstack: free alerts about vulnerable plugins for up to 3 sites. Its protection, which blocks known plugin exploits before you've updated, starts at US$5 a month per site.

Now the PHP2Shell point, because it's easy to get wrong. A security plugin is PHP code that WordPress loads. PHP's advisory says the demonstrated mod_php exploit can trigger "before any application code runs": before WordPress, and before any plugin, including a firewall plugin set up to load ahead of WordPress. Sansec, which sells security for online stores, says the same about its own Shield product: the attack paths "run inside PHP, before your store code and before Sansec Shield". Keep your security plugin. Just don't read its green dashboard as proof that the server underneath is patched.

A handful of WordPress settings make a stolen login far more damaging, and changing them takes about 15 minutes.

• Turn off the file editor. Adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php stops anyone editing plugin and theme code from the dashboard. WordPress says this "might stop some attacks" and won't stop malicious uploads, so treat it as one layer.
• Limit login attempts. Your security plugin does this. Check it's actually switched on.
• Turn off XML-RPC if nothing uses it. It's an old remote-publishing interface that attackers like for password guessing. Jetpack and some mobile apps need it, so check before you block it.
• Force HTTPS everywhere, including the admin and login pages.
• Tighten file permissions: 644 for files and 755 for folders is the usual starting point, with wp-config.php stricter still.

The right host for a business WordPress site patches PHP and the operating system for you, tells you when it has, and keeps backups you can restore yourself. PHP2Shell split hosting into two groups this week.

On shared or managed hosting, the host updates PHP. SiteGround, which has a Singapore data centre, says it rolled out server-level mitigations after PHP's advance notice and applied the fixes across all its servers on 21 October, and that its customers need do nothing. Other hosts may well have done the same, so ask rather than assume. If you're with a local host like Vodien or Exabytes, one support ticket will do it: has the server my site runs on been updated to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched backport, and when?

On an unmanaged VPS or cloud server, nobody patches PHP unless somebody is paid to. These are often the sites set up cheaply years ago and never touched since. How urgent is it? Sources disagree. CISA told organisations that can't patch, or still run PHP 8.1 or older, to take PHP systems offline until they can. Sansec said on 22 October that the public exploits "do not work against a default PHP installation" and that stores don't need to go offline. Both say update PHP, which is the part that matters.

A monthly outside check catches the problems you'd otherwise hear about from a customer: malware injected into pages, a Google "dangerous site" warning, an expired certificate or missing security headers. Free scanners do this in a few minutes, and Google Search Console emails you if Google finds hacked content on your site.

Know their limit. A scanner on the internet can't reliably see which PHP build your server runs, so a clean scan doesn't mean you're patched. My roundup of free website security check tools explains what each one can and can't see.

Signs it has already gone wrong: mobile visitors redirected to gambling or pharmacy sites, strange pages showing up in Google under your domain, admin users you didn't create, or your host suspending the account. If you see any of them, start with what to do in the first 24 hours after a WordPress hack. In Singapore you can also report an incident to SingCERT through CSA's incident reporting page.