An admin opens a WooCommerce order to check what a customer bought. A script hidden in that order runs using their logged-in session. That’s the attack Patchstack reported this week, in a campaign seen since October 4, 2026. Attackers planted scripts in Ninja Forms submissions and WPC Product Bundles WooCommerce orders. When an admin opened an affected entry, the script installed a fake plugin called WP Smart Thumbnails. It created a visible admin, another admin hidden from the Users screen, a secret login link and a file manager.
The admin’s password could have been excellent. It wouldn’t have stopped a script acting through an open session. That’s the awkward part of trying to secure the WordPress login in 2026: the login form is only the start. You also need to think about who has admin access, what happens after they sign in and how you’d spot an account you didn’t create.
WordPress login security starts with passwords and passkeys
Give every staff member their own login and a unique password generated by a password manager. If someone uses the same password for their shop dashboard and an unrelated service that later leaks credentials, attackers can try those credentials on your site. They don’t need to guess anything.
Passkeys are a stronger option where your setup supports them. They’re tied to your real site domain, so a convincing fake login page can’t phish a passkey the way it can collect a typed password. WordPress core doesn’t include built-in passkey login; you add that through plugins. Check what your chosen plugin supports, test it with one admin account and make sure you have a recovery method before rolling it out to the whole team.
I’d rather have five people using separate password-manager accounts than one shared admin password everybody claims to remember. Shared logins make it hard to tell who changed an order setting, too.
Use phishing-resistant 2FA for every privileged account
Two-factor authentication adds a second check after the password. The options aren’t equal. For accounts that can change your site, my preference runs like this:
- Passkey or security key: strongest protection against fake login pages.
- Authenticator app (TOTP): a solid, practical choice, though someone can still be tricked into typing a current code into a fake page.
- Email codes: better than a password alone, but weak if the email account is compromised.
- SMS codes: use them if that’s your only workable option, not as your first pick.
Make 2FA mandatory for every administrator and WooCommerce shop manager. Optional 2FA tends to leave exactly the accout you forgot about unprotected. Store backup codes somewhere safe and separate from the site. For the actual setup, use our guide to two-factor authentication for WordPress admins.
And remember the opening example: even good 2FA doesn’t make an already logged-in session harmless. Keep going.
Brute force protection should slow attackers, not customers
Brute force protection covers repeated password guesses, but there’s another common pattern: credential stuffing. That’s when attackers test passwords leaked from other services against your WordPress accounts. A rate limit helps with both, while unique passwords and 2FA deal with the bigger credential-stuffing problem.
Set limits per IP address and per username, with progressively longer delays after failed attempts. Don’t rely only on long, hard lockouts. An attacker could deliberately trigger one against your real admin account just before you need to ship orders. Where possible, block abusive traffic at the server or firewall before it reaches WordPress; that’s cheaper on CPU than making PHP process every attempt.
Run a WooCommerce shop? Test the rules on /my-account/, not just /wp-login.php. Customers mistype passwords, especially on phones. A rule that strands legitimate buyers at checkout isn’t a win. Our WordPress login protection service covers rate limits and firewall rules without treating every forgotten customer password like an attack.
Should you hide the login URL?
Changing the usual login address can cut bot noise and shrink your logs. That’s a reasonable perk. It is not a substitute for 2FA or rate limits.
A targeted attacker can find other ways to test access, and /wp-login.php isn’t the only door. URL-changing plugins can also clash with caching or another plugin. Disable the wrong plugin at the wrong time and you may lock yourself out. If you use one, document the new address somewhere your team can find it, keep an administrator recovery route and test sign-in after changes.
My verdict: nice to have if automated hits are making a mess of your logs. Don’t mistake quiet logs for a secure WordPress login.
Check the other doors: XML-RPC, application passwords and REST
A login page can look well guarded while another route is still accepting credentials. These three deserve a check:
- XML-RPC:
xmlrpc.phpcan allow many password guesses inside one request throughsystem.multicall. Disable it if nothing you use needs it, but check first - Jetpack and some apps rely on XML-RPC. Our XML-RPC guide walks through that decision. - Application passwords: WordPress has offered these since version 5.6 for integrations using REST or XML-RPC. They bypass interactive 2FA by design. Go to
Users > Profilefor each privileged user, review their application passwords and revoke any you can’t identify. If your site uses no such integrations, consider disabling the feature. - REST API user listing: usernames can be visible at
/wp-json/wp/v2/userson many sites. Visit that address while logged out and see what your site exposes. Restrict public user listings if appropriate, but don’t rely on hiding usernames as your password defence.
One detail matters here: an application password is a separate credential, not somebody’s normal dashboard password. Turning on WordPress admin MFA won’t automatically make an unknown application password safe. Check both.
Keep your admin list small - and check beyond the Users screen
Administrator access should be rare. Someone writing product descriptions may need Editor access; someone handling WooCommerce orders may need Shop manager. Neither job automatically calls for full control over plugins, users and site settings.
Once a month, do a quick access audit:
- Remove accounts belonging to ex-staff and developers who no longer work on the site. Reassign their content where needed.
- Replace shared admin logins with individual accounts, and use usernames that aren’t identical to public display names.
- Count administrators and confirm each one has a current reason to be there.
- Turn on alerts for new administrator creation and review the activity log when one appears.
The campaign at the top of this article is a reminder that the Users screen may not tell the whole story. A hidden admin might not appear there. If a new-admin alert fires but you can’t find the account, don’t assume it was a false alarm. Have someone who knows WordPress inspect the database and activity logs, then investigate what created it. Don’t start deleting database rows at random.
Don’t forget active admin sessions
Log out when you’re done on a shared computer, and don’t hand an open admin browser to a colleague as a shortcut. If a device goes missing or you suspect an account was used without permission, change its password and use the session control in that user’s profile to log out other sessions. Review recent activity and other admins at the same time.
That won’t undo a plugin an attacker already installed. If you find a suspicious admin, unexpected plugin or unexplained file manager, treat it as a site compromise rather than a simple password-reset job. You need to find the entry point and remove the persistence, including anything that doesn’t show up in the normal dashboard.
What we enforce on every maintenance site
For the sites we maintain, login security is a set of checks we keep revisiting, not a plugin we install and forget:
- 2FA required for every administrator and shop manager, with recovery codes stored safely.
- Login rate limiting and firewall rules, tested against the shop’s customer login too.
- XML-RPC disabled unless a known integration needs it.
- Application passwords reviewed, with unused credentials revoked.
- Administrator counts audited and alerts set for new admin creation.
- WordPress, plugin and theme updates checked and applied so a known admin-session XSS issue has less chance to linger.
Updates alone can’t guarantee protection from a campaign like this week’s. But leaving a vulnerable plugin in place while carefully hiding your login URL? Wrong priority. Our WordPress maintenance service focuses on the ongoing checks as well as the updates.
Do this ten-minute check today
Open Users and count your administrators. Can you name each person and why they need that role? Then open the privileged accounts’ profiles and check for application passwords you don’t recognise. Finally, confirm 2FA is turned on and required for every admin and shop manager - or start that rollout today if it isn’t.
If one of those checks turns up an account nobody can explain, stop treating it as routine housekeeping. That’s the thing to investigate first.