Most WordPress security advice starts inside WordPress. Update plugins, remove old administrators, scan the files. Fair enough.
But sometimes WordPress isn’t the entry point. The attacker gets into a control panel with the power to add server access, reach backups and touch every site connected to it. That changes the cleanup completely.
A control-panel incident disclosed at the end of August is a useful example. The lesson isn’t that one platform had a bad month. It’s that your website has doors above the familiar wp-admin screen, and those doors may open far more than one site.
What we know – and what we don’t
FlyWP said an incident detected on 6 August 2026 affected more than 700 customer servers. It published its official incident report on 29 August.
The account used in the attack belonged to a former employee. It had stayed active and still had permission to push SSH keys to customer servers. Once somebody controlled that account, they could create a direct route into the servers below the panel.
There’s a line we shouldn’t cross here. FlyWP identified the account, but the exact way its credentials were stolen remains unknown. Maybe phishing, password reuse, a hijacked session or something else. Those are possibilities, not facts. The confirmed failure was stale privileged access that should have disappeared when the employee left.
The traces were serious: new SSH keys, WordPress administrator accounts, hidden plugins and PHP files able to run remote commands. Search cloaking was observed too, so visitors and search engines could be shown different content. This wasn’t a single defaced page. It was several ways to stay in, run code and quietly misuse websites.
The downloaded backup was a separate problem
The report also describes a second path. A lower-trust marketing environment held credentials with read access to a Cloudflare R2 bucket containing a production database backup. Those credentials were obtained and the backup was downloaded.
Secrets inside the backup were encrypted, with the encryption keys stored separately. FlyWP said it found no evidence that the attacker decrypted them. Good design helped there, but “no evidence of decryption” doesn’t turn a stolen backup into a harmless event. Exposed credentials still need rotation, and the systems they unlock need review.
This matters beyond FlyWP. A newsletter site, campaign tool or forgotten staging box shouldn’t hold a key that can read production backups unless there is a very good reason. Usually there isn’t.
Your control panel is a master key
For a small business, hosting often feels like a cupboard where the website sits. A modern managed WordPress hosting setup can do much more: create sites, open passwordless sessions, run updates, manage backups and place SSH keys. Control that layer and you may control every WordPress installation under it.
So deleting a developer from WordPress isn’t enough. Their access might remain in the hosting panel, cloud account, DNS provider, shared password vault or server itself. Changing the WordPress password won’t remove an SSH key either. Different door.
When an employee, agency or freelance developer leaves, check these on the same day:
- hosting panels, cloud accounts, DNS and CDN users;
- SSH keys, server users, SFTP accounts and deployment tokens;
- WordPress administrators, sessions and Application Passwords;
- backup storage, shared vaults and magic-login links;
- API, SMTP and payment credentials they could reach.
Don’t wait for a quarterly tidy-up. Our guide to administrator-account mistakes covers the WordPress end, but offboarding has to follow the access all the way up. If a person could add a key or reset another account, treat that as privileged access even if the dashboard gave it a friendly name.
SSH access changes the cleanup job
A clean-looking Plugins screen proves very little after server-level access. An attacker can edit files directly, add scheduled tasks, alter configuration outside the web root or hide a loader in mu-plugins. They can create a fresh WordPress admin after you delete the first rogue one. Annoying, but predictable.
Start with a snapshot and triage, not frantic deleting. Preserve the server and database state, useful logs and timestamps. Then build an infection map: which users appeared, which keys changed, where PHP files landed, what persistence exists and which websites show cloaked search results.
A practical recovery order looks like this:
- Audit server users and every entry in
authorized_keys. - Review WordPress administrators, sessions, Application Passwords and the database.
- Inspect scheduled tasks, startup points, redirects,
mu-plugins, drop-ins and changed PHP files. - Replace WordPress core with a matching clean copy and reinstall repository plugins from trusted packages.
- Manually review themes, premium plugins and anything that can’t be cleanly replaced.
- Rotate SSH, database, WordPress, API, SMTP and payment credentials after clean replacement.
That sequence is why hacked WordPress cleanup is more than a scanner pass. If you remove visible malware before mapping access, you may erase clues while leaving the original route open. And if several sites share the same panel or server, checking just the noisy site is a gamble.
A backup may preserve the compromise
Backups are valuable. They’re also snapshots of whatever existed at that moment, including a hidden plugin, rogue administrator, malicious database entry or remote-command file.
Restore a copy made after the attacker arrived and you can bring the compromise straight back. Restore an older copy without rotating access and the attacker may simply return through the same SSH key. This is the difference between having files somewhere and having a tested recovery process, which we covered in why a backup is not a recovery plan.
Before restoring, check the backup date against the known timeline and inspect its contents. Keep backup credentials separate from marketing sites and other lower-trust systems. Use narrowly scoped access, and assume a downloaded production backup needs a response even if sensitive values inside it were encrypted.
Three questions to ask today
You don’t need to abandon managed hosting or learn Linux tonight. Honestly, that would make plenty of small-business sites less safe. You do need a clear picture of who holds the master keys.
Ask your host or developer: Who currently has panel and SSH access? What happens to that access on the day somebody leaves? Can any marketing or staging system read production backups?
If the answers are vague, request an access audit. Then document who owns each account and how it can be revoked. Boring work, yes. It’s still cheaper than discovering that a former team member’s forgotten login can push keys into hundreds of servers.
Your WordPress login is one door. The control panel, SSH layer, backup storage and cloud accounts are others. After a breach, follow every permission the compromised account had, clean each reachable layer and rotate the keys only after the environment is clean. Anything less leaves too much to luck.