How To Keep Your WordPress Site Secure in 2026

Last updated: October 2026. WordPress powers a large share of the public web, which means automated bots hammer /wp-login.php and known plugin CVEs all day. For a Johannesburg professional-services firm, a regional retailer with WooCommerce, or a group site with careers and investor pages, the site is not a brochure — it is a credential store, a form collector under POPIA, and sometimes a card-data environment.

Wordfence and other threat feeds still show the same pattern year after year: outdated extensions and weak passwords, not “WordPress core is inherently unsafe.” Core ships frequent security releases; the failure mode we see in rescue projects is a host or marketing team that has not applied them.

Security is a cadence owned by someone with a name on an org chart — not a one-off plugin install. Marketing, IT and procurement should agree who approves plugin updates, who holds hosting credentials, and who speaks to the information officer if forms leak data. Without that owner, “we will update WordPress when we have time” becomes never — until Search Console shows malware or PayFast disables the gateway.

Pair this checklist with website maintenance and support so patches actually ship after QA, and with web development when the theme stack is too old to patch safely.

Major releases add editor convenience; they also move the security baseline. If your board asks “are we on a supported version?”, the answer is the patch number, not “we use WordPress.”

What 6.7 and 6.8 added for operators

WordPress 6.7 improved Site Editor workflows (Zoom Out, Data Views, HEIC conversion to JPEG) and continued hardening in the block library. WordPress 6.8 “Cecil” focused on polish: a clearer Style Book, speculative loading for faster navigation, database optimisations, and — critically for security — bcrypt password hashing for new and rotated passwords so stolen database dumps are harder to crack offline.

Speculative loading preloads linked pages when configured; it is a performance feature, not a firewall. It does not replace patch management. Bcrypt helps when passwords leak; it does not stop an unpatched plugin from granting upload rights to an Author account.

September 2026 security releases you should not skip

WordPress published multiple security-only releases in 2026. Treat these as stop-the-line events for any site that stores leads or payments:

• 6.8.10 (22 September 2026) — fixes an unauthenticated path traversal issue in page-template resolution that could lead to conditional remote code execution. Details: version 6.8.10 notes.
• 6.7.8 (17 September 2026) — a bundle of fixes including REST template path traversal, comment reparenting authorisation, XSS in themes and comments, and other issues. Details: version 6.7.8 notes.
• 6.8.8 (August 2026) — included an Author+ remote code execution path on stacks using Imagick and Ghostscript — relevant if your host processes uploads with that pipeline.

Policy for mid-market teams: stay on 6.8.x at the latest patch unless a plugin chain blocks you; if you must remain on 6.7, run the newest 6.7.x the same week the release ships. Enable automatic updates for security releases where your host allows it, and still run a visual smoke test on staging for WooCommerce checkout and forms.

Managed WordPress hosts often apply security releases faster than shared cPanel accounts where FTP is the only update path. If your IT team insists on “no auto-updates,” document that exception in writing and assign a human who checks the WordPress release blog every Tuesday — the same day WordPress frequently ships security fixes. Delaying two weeks on a template traversal fix is not a budget decision; it is an exposure window.

Every administrator, agency login and integration account should use a password manager and two-factor authentication. Remove shared “info@” admin users. Rename or delete the default admin username if it still exists from a 2014 import.

Serve the entire site — including /wp-admin and REST endpoints — over HTTPS with a valid certificate. Mixed content is not only a browser warning; it trains staff to click through insecure assets. Limit login attempts at the edge (WAF or host rules) and inside WordPress.

Use Application Passwords and scoped API keys for integrations instead of sharing the CEO’s login with a newsletter tool. Map roles honestly: Authors should not install plugins; Shop Managers should not edit theme files. After staff changes, audit users quarterly — ex-agency accounts are a common back door.

Moving /wp-login.php with a hide-login plugin is optional obscurity. It reduces noise from dumb bots but breaks when the plugin is abandoned. Prefer 2FA, strong passwords and Web Application Firewall rules on wp-login.php and xmlrpc.php if you do not need XML-RPC.

Delete inactive plugins — they still execute code if someone reactivates them or if a vulnerability allows file inclusion. Never deploy nulled premium themes or plugins; they are a common malware delivery channel on South African small-business hosts.

Update core, themes and plugins on a fixed weekly or fortnightly window. For WooCommerce and membership sites, clone production to staging, run updates there, test checkout, tax, PayFast or Peach endpoints, then promote. Document the rollback: which backup timestamp you will restore if a payment gateway fails.

One well-maintained firewall or malware scanner (Wordfence, Solid Security, or host WAF) is enough for many sites. Three overlapping “security” plugins increase conflict risk and rarely get updated together. If you sell online, read this alongside ecommerce platform ownership and Shopify vs WooCommerce for South Africa — platform choice does not remove patch duty on WooCommerce.

Use the built-in Site Health screen (Tools → Site Health) after every core update. Resolve critical issues before marketing launches a campaign. Connect Google Search Console and review the Security & Manual Actions report monthly — malware flags often appear there before anyone notices front-end defacement.

Log admin logins and failed attempts where your host or security plugin allows it. If you process personal information in forms or WooCommerce orders, POPIA expects reasonable safeguards: HTTPS, access control, backups, and an incident process when data may have leaked. A hacked contact form that forwards to Gmail is both an IT and an information-officer conversation.

Uptime monitoring (Pingdom, UptimeRobot, or host alerts) should page a human, not only email an unused inbox. Define who can take the site offline during an active compromise — marketing should not keep a malware-serving shop live “because it is month end.”

For corporate teams, export a monthly one-page report: core version, last backup restore test date, count of administrator accounts, and open Site Health items. That document is what you show auditors or insurers when they ask whether the public website is governed like other systems. It also stops the agency from being the only person who knows the hosting login.

Block two hours once a month if you cannot afford a care plan. This sequence is what we walk marketing and IT through on retained WordPress clients:

1. Confirm WordPress core patch level matches wordpress.org releases for your branch.
2. Update plugins and themes from staging; smoke-test login, homepage, primary form and checkout.
3. Review Site Health and disk space; clear old backup zip files from public directories if a plugin misplaced them.
4. Confirm backups completed and download one archive to offline storage.
5. Rotate Application Passwords for any integration that changed staff.
6. Scan Search Console for security issues and crawl anomalies.

If step two fails twice in a row, stop stacking plugins and book a structural review — you may need a rebuild on maintained foundations rather than another year of reactive fixes.

Take the site offline or put it in maintenance mode if it is sending spam, serving pharma links or skimming checkout fields. Rotate every password — hosting panel, FTP, database, all WordPress users, email mailboxes used for forms. Restore from a known-clean backup taken before the infection window, then patch the entry point (plugin, theme, weak login, or outdated core).

Do not “clean” production by deleting random PHP files while the shop stays live. Request a review in Search Console if Google flagged malware. Document the timeline for POPIA if customer or lead data may have been accessed.

Dsignr Digital can audit, harden and recover WordPress as part of a care plan or rescue engagement — often paired with SEO once the property is clean and crawlable again.

WordPress in 2026 is a mature CMS with a steady stream of security fixes and meaningful platform improvements such as bcrypt hashing and clearer Site Editor tooling. None of that helps if your host runs 6.8.0 while 6.8.10 closes a template traversal issue, or if twelve plugins have not been updated since 2024.

Mid-sized South African organisations should treat WordPress like any other business system: named owner, patch window, tested backups, 2FA on privileged accounts, and a written incident path. Book a call if you want Dsignr Digital to run that cadence with your marketing and IT teams, or scope a migration when the current stack cannot be secured without a rebuild.