If the hosting panel is compromised, the WordPress installation cannot be your root of trust. An attacker with panel access may change files, databases, DNS, mailboxes, cron jobs, backups or SSH accounts outside WordPress, so recovery starts from provider-level identity and a clean control path.
Recover the provider account independently
Use the host’s verified support/recovery process and a known-clean device. If email recovery is suspect, do not rely on that mailbox until it is secured separately.
Inventory control-plane changes
Review new users, API keys, SSH/SFTP accounts, scheduled tasks, DNS zones, mailboxes, backups and recent panel logins. WordPress file timestamps show only part of the incident.
Create new secrets, do not only rename users
Rotate panel credentials, database passwords, deployment keys and other privileged secrets that the panel could expose. Revoke old sessions and tokens where the provider supports it.
Choose a trustworthy rebuild point
A backup stored and controlled by the compromised panel may also be suspect. Prefer a known-good external or provider-versioned backup whose date predates the incident and validate it before use.
Rebuild WordPress under the recovered control plane
Restore clean core/plugins/themes from trusted sources, migrate only verified content/data and then rotate WordPress salts/admin credentials.
Audit after service restoration
Monitor provider logins, file changes, cron, outbound mail and DNS for recurrence. A stable site for one hour is not evidence that panel persistence is gone.
Compare the control-plane recovery with Plesk administrator recovery and then rotate the accounts people often forget.