Sites under one cPanel user commonly share filesystem permissions, cron, mail limits and control-panel access. Cleaning only the most visible domain leaves sibling sites able to reinfect it or preserve the same stolen credential.
Treat the cPanel account as the initial incident boundary until evidence proves a narrower scope.
Inventory the whole account
List addon domains, subdomains, parked domains, document roots, WordPress installations, staging copies, databases, cron tasks and mailboxes. Include abandoned sites and hidden development folders.
Record owners and business criticality. Do not browse infected sites while logged into cPanel or another administrator account.
Preserve the account layout before moving directories.
Contain public exposure
Disable checkout, login or public routing for affected sites according to risk. Serve static maintenance outside the compromised WordPress roots where possible.
Restrict outbound mail if the account is sending spam. Keep an approved alternative route for critical enquiries and orders.
Do not delete the entire account before backups and logs are secured.
Preserve account-level evidence
Snapshot files, all related databases, cPanel access logs, FTP/SFTP/SSH logs, mail queue, cron and recent file changes. Record common usernames, permissions and shared configuration.
Store evidence outside the account, because the attacker or cleanup process could modify it. Limit access and minimise customer data.
Note log-retention deadlines with the host.
Find shared access paths
Check cPanel users, FTP accounts, SSH keys, API tokens, file-manager activity and the primary email account. One stolen control-panel credential can explain changes across every document root.
Review database users reused across sites and deployment tools with account-wide write access. Rotate them from a clean device after evidence collection.
Do not assume a vulnerable plugin is the sole cause merely because all sites use WordPress.
Compare indicators across sites
Look for identical filenames, code patterns, scheduled tasks, administrator accounts, redirect domains and modification times. Common indicators help locate lateral movement and persistence.
Also check for different payloads; attackers may deploy spam on one site and redirects on another. Use trusted checksums for maintained components.
Do not execute or upload samples to public scanning services without authorisation.
Separate database and backup exposure
Check whether every installation shares one database user or stores backups from sibling sites inside a public document root. Rotate and restrict users per application during recovery.
Move backups to protected storage outside cPanel web roots. A clean site can be reinfected or have its data exposed through an abandoned archive belonging to another domain.
Record which backup credentials or encryption keys also require rotation.
Rebuild each site independently
Create clean roots and install WordPress/plugins/themes from verified sources. Validate each site’s custom code and database, import assessed uploads/content and create unique secrets.
Recover the most critical site first only if it cannot be rewritten by still-infected siblings. Keep old roots non-executable and isolated.
Test one site fully before using the process on the rest.
Separate future blast radius
Move unrelated production sites into separate hosting subscriptions/users where practical. Give each unique database, SFTP/SSH, WordPress and SMTP credentials.
Limit developer access to required sites and use managed deployment accounts. Enforce MFA on hosting, email, DNS/CDN and WordPress administrators.
Separation does not replace patching, monitoring and backups, but it prevents one writeable account from owning every site.
Verify the account, not only pages
After recovery, check all cron tasks, mail volume, filesystem changes, administrators, DNS and backups. Test redirects, forms, checkout and scheduled jobs for each reopened site.
Monitor for shared indicators and reconcile leads/orders during downtime. Retire unused domains and old staging installations.
Request emergency multisite recovery when scope crosses document roots or account-wide credentials. Share the inventory and managed cPanel access—never one reused password, full archives or customer databases in chat.