WordPress Security Checklist for October 2026: 10 Things to Check Before Your Website Gets Hacked

Learn how to secure your WordPress website in 2026 with our practical checklist covering updates, plugins, backups, malware scanning and hosting security.

WordPress 7.1.3 shipped on 6 October 2026 with seven security fixes and four bug fixes. Two weeks earlier, 7.1.2 (22 September) patched a critical-severity issue in core (CVE-2026-87902). If your site is still on 7.1.1 or an unpatched older branch, you are behind two security releases.

This is not a “panic and click Update Now” post. It is a WordPress security checklist you can reuse for months: confirm the version you actually run, patch on a supported path, then lock down plugins, admins, backups and the host. You can follow every item without buying anything. Fast2Host WordPress hosting and WP Toolkit simply make the same jobs faster.

October 2026 WordPress security snapshot: 7.1.3, 7.1.2, ten checks

1. Why WordPress security matters in 2026

WordPress remains the default CMS for UK SMEs, WooCommerce shops and agency client sites. Attackers do not need a clever 0-day when they can:

  • Hit thousands of sites still running last month’s core
  • Abuse an abandoned contact-form or page-builder plugin
  • Guess admin / reused passwords with no 2FA
  • Find a host with no WAF, no account isolation and backups that have never been restored

Core hardening in 7.1.2 / 7.1.3 only helps if you install it. Plugin and account hygiene is still where most real compromises start.

Typical WordPress attack surface: plugins, themes, admins, core, host

Bar length is qualitative. Check plugins and admin access first — then core and hosting.

A UK host still matters: data residency, a real telephone NOC, and a stack that includes Imunify360, ModSecurity, daily Acronis backups and edge DDoS — not a security plugin pretending to be a data centre. See DDoS protection for UK businesses and why Cambridge still matters.

2. The latest WordPress security updates explained

Official notes:

Timeline of WordPress 7.1.2 and 7.1.3 security releases

7.1.2 — critical-severity (do this if you skipped September)

WordPress described an unauthenticated issue in page-template resolution: under certain server and theme conditions, template lookup could include a local PHP file outside the active theme directories, which can lead to remote code execution. Details: CVE-2026-87902. We will not walk through exploit mechanics here.

Patched 7.1 line: 7.1.2 (and therefore 7.1.3). WordPress also shipped backports on supported older branches (through 4.7 as a courtesy). Only the latest WordPress version is fully supported — backports are a bridge, not a strategy.

7.1.3 — seven security fixes, four bugs (6 October)

WordPress.org lists:

AreaWhat was fixed (high level)
Comments adminStored XSS via pending comments
HTTP helperDenial-of-service in WP_Http::make_absolute_url()
Tools → ExportSecond-order SQL injection in WXR export
AuthorsAuthors could sticky posts they should not
Comment feedsUnauthenticated disclosure of comments on private / unpublished posts
EmbedsXSS in Imgur embeds
HooksForgeable {status}_{type} hook parameters (action-name collision; relevant if a plugin passes raw status/type)

Patchstack’s read of 7.1.3 is useful: update promptly, but this is not the same class of emergency as 7.1.2. Two issues start unauthenticated; several need Contributor/Author or an administrator running an export.

Bug worth knowing: 7.1.3 also addresses a critical (severity of the bug, not a CVE) image-upload fatal on hosts missing PHP’s DOM extension. If media uploads died after 7.0, this release is for you as well as for security.

What to install

What you run todayAim for
7.1.0 – 7.1.27.1.3
7.0.xLatest 7.0 security package that includes these backports (check Dashboard → Updates), then plan a move to 7.1
6.x / 5.x / 4.7+The backport build WordPress lists for that branch, then schedule a supported major
4.6 or olderNo security updates. Rebuild or migrate — do not “harden” a dead branch

Always verify the installed version and the upgrade path WordPress offers you before you click Update. A jump from 5.8 to 7.1 is not a one-click security patch; it is a project (PHP version, theme, WooCommerce, page builder).

3. How to check your WordPress version

Pick one — they should agree:

  1. wp-admin — Dashboard → Updates, or the version in the footer (if that display is not hidden).
  2. WordPress Toolkit (Fast2Host cPanel / WordPress plans) — the site card shows core version and an update badge. Guide: WordPress Toolkit for cPanel.
  3. Front end — view source for generator meta (easy for attackers too; Toolkit hardening can hide it, which is fine).

Write the number down. “We updated last year” is not a version.

PHP: Toolkit shows PHP per install. 7.1 expects a current PHP 8.x line your plugins actually support. Change PHP in cPanel MultiPHP on a clone first if you are unsure.

4. Why outdated plugins and themes are dangerous

Core news is loud. Plugin CVEs are the daily grind. Abandoned “donationware”, nulled “Pro” zips and a page builder three minor versions behind are how most agency sites get a webshell.

Checklist

  • Update everything with a current, trusted upstream.
  • Delete unused plugins and themes (not “deactivate and forget”).
  • Replace anything with no update in 12+ months, or a broken wordpress.org listing.
  • Never install zip files from “nulled” shops.
  • After updates, browse checkout, forms, membership login and wp-admin.

Toolkit Updates and Vulnerabilities (Patchstack / Wordfence intelligence, depending on Toolkit version) flag this without a separate scanner plugin. You can still run Wordfence or similar in wp-admin if you prefer — do not stack three overlapping security plugins.

5. How to secure administrator accounts with 2FA

Stolen wp-admin is still the shortest path in.

  • Do not use the username admin.
  • One person, one Administrator. Editors do not need install_plugins.
  • Unique password in a manager — not the same as cPanel or email.
  • Two-factor authentication on every Administrator (and Shop Manager on WooCommerce). Use a maintained 2FA plugin from wordpress.org, or your SSO if you have it.
  • Limit login attempts / protect wp-login.php (host WAF plus a small plugin, not five).
  • Turn off unused XML-RPC (Toolkit Security hardening). Keep it only if Jetpack or a mobile app truly needs it.
  • Separate cPanel 2FA (control panel) from WordPress 2FA (site). Both.

6. How to configure automatic updates safely

Blind “update everything at 03:00” breaks WooCommerce. Never updating breaks the internet’s scanners.

Sensible Toolkit defaults (same table as our Toolkit guide):

ComponentDefault for most live sites
WordPress minor / securityOn (this is how 7.1.3 arrives if you already auto-update core)
WordPress majorOff until you have tested on staging
PluginsSecurity auto where offered, or a weekly review
ThemesManual unless you fully control the parent theme

If Toolkit offers “deactivate vulnerable plugin instead of updating”, use it on client sites overnight — a broken checkout is better than an open RCE, and you can patch in the morning.

Safe WordPress update order: version, backup, staging, update, browse

7. How to scan your website for vulnerabilities

Three layers, not one plugin:

  1. WP Toolkit → Vulnerabilities — known plugin/theme issues, with update or deactivate.
  2. Check WordPress Integrity — core files vs wordpress.org checksums; reinstall tampered core without touching content.
  3. Imunify360 on Fast2Host cPanel — malware and WAF at the account/server layer (cPanel CloudLinux).

Also: look at users you did not create, wp-content/uploads PHP files, unknown admin plugins, and outgoing spam (that is an abuse problem as well as a hack).

Integrity + Imunify is not a pentest. It is the scan you can actually run this afternoon.

8. Why off-site backups and restore tests matter

A backup you have never restored is a rumour.

On Fast2Host, daily Acronis backups sit in cPanel, separate from Toolkit snapshots. Treat Toolkit as quick WordPress undo and Acronis as account disaster recovery — Acronis Cyber Protect.

Do this once per quarter

  1. Note the last successful backup date in Acronis.
  2. Restore files + database to a subdomain (not over production).
  3. Load the restore, log in, place a test order if you have a shop.
  4. Write down how long it took.

If restore fails, fix the backup job before you need it for 7.1.4.

9. How to use staging before updating a live website

Security releases are still software. Page builders, WooCommerce gateways and custom functions.php can object.

Minimum staging path

  1. Backup.
  2. Clone to a subdomain (Toolkit Clone) or run Smart Update (clone → update → visual compare → promote only if it matches).
  3. Test: home, a post, search, contact form, cart, checkout, wp-admin, cron-ish jobs (subscriptions).
  4. Only then update production — or let Smart Update promote.

Agencies managing many installs: mass-harden and batch-update off-peak from Toolkit. Product detail: WordPress Toolkit.

Moving host at the same time as 7.1.3 is optional but tidy — migrate WordPress to a UK host with a staging cutover, not an in-place gamble.

10. A printable five-minute WordPress security checklist

Do this on every site you are responsible for. Print or copy into your runbook.

Five-minute WordPress security checklist cards

#CheckDone
1Core is 7.1.3, or the official backport for my branch — version confirmed in Updates / Toolkit☐
2PHP version is supported by that core and my plugins☐
3Plugins updated; unused / abandoned / nulled items deleted☐
4Themes updated; extra themes deleted☐
5No admin user; Administrators have 2FA; roles least-privilege☐
6Minor/security auto-updates on; majors only after staging☐
7Toolkit (or equivalent) vulnerability scan clean or tickets raised☐
8Integrity check passed☐
9Off-site backup exists; restore tested this quarter☐
10Staging/Smart Update used for anything bigger than a security bump; HTTPS, WAF, DDoS, UK isolation in place☐

Hosting row (still part of WordPress security): AutoSSL / HTTPS, Imunify360 or equivalent WAF, account isolation (CloudLinux), tested backups, 24/7 humans. Plugins cannot replace that. Compare WordPress hosting and cPanel. SSL context: free vs paid certificates.

FAQs

What WordPress version should I be on in October 2026?
On the 7.1 line: 7.1.3. Older supported branches should show a security package in Dashboard → Updates. Confirm your listed target before updating.

Is 7.1.3 as urgent as 7.1.2?
7.1.2 was a critical-severity core fix. 7.1.3 is a broader security and maintenance release. Install both (7.1.3 includes being past 7.1.2). Do not skip 7.1.3 because “we already patched in September”.

Will automatic updates get me 7.1.3?
If minor/security auto-updates are enabled and the site can reach wordpress.org, usually yes. Check the version anyway.

Can Fast2Host apply this for me?
Yes — open a ticket. We will not blindly major-upgrade a shop without a backup and a staging pass.

I am on WordPress 5.x / 6.x.
Apply the backport WordPress offers for that branch immediately, then plan a supported major on staging. PHP and plugins must move with you.

Next step

Use the five-minute table on every live site this week. Use Toolkit for the operations you would rather not do over FTP.

Share this article

Speak to our UK team — we're here to help