WordPress code execution can often write files owned by its PHP user, while stolen cPanel/Plesk/SFTP access can change multiple document roots, databases, mail and DNS. The distinction determines what must be rebuilt and which credentials need priority.
Start with the account as the boundary, then narrow only when evidence supports it.
Map permissions and ownership
Document the hosting system user, PHP handler, WordPress document root, sibling sites, database users and writable directories. Record whether subscriptions/sites share one operating-system user.
In shared cPanel, one compromised PHP process may write across sites if permissions allow it. In separated Plesk subscriptions, cross-site changes point toward broader access.
Do not change ownership before preserving it.
Review control-panel access
Inspect cPanel/Plesk logins, file-manager actions, API tokens, team/customer users and recovery-email changes. Correlate them with file and database changes.
An unknown successful panel session is strong hosting-account evidence. Absence of panel logs does not prove WordPress-only scope if retention is short.
Preserve account identifiers before revocation.
Inspect SFTP, SSH and deployment activity
Review SFTP/FTP/SSH users/keys, source deployments and backup-restoration history. Compare commands or uploaded paths with malicious changes.
Stolen developer credentials may look like normal deployment access. Verify with the account owner rather than assuming a familiar username is legitimate.
Rotate keys from a clean device after snapshots.
Compare sibling sites
Look for identical payloads, administrators, cron hooks, redirect domains and timestamps across all sites under the account. A simultaneous cross-root pattern suggests shared hosting access or permissions.
Different infection dates may still result from one site spreading laterally. Check abandoned staging sites and backup directories.
Do not clean only the public flagship domain.
Examine WordPress-level indicators
Search web logs for vulnerable plugin/theme endpoints, authenticated administrator actions and uploads. Review WordPress users, application passwords, must-use plugins, cron and database options.
If changes remain inside one installation and align with a public WordPress exploit, WordPress-level entry is more likely—but hosting secrets may still have been read afterward.
Record capability escalation and first persistence event.
Interpret file ownership cautiously
Files owned by the PHP/system user can result from WordPress code execution, legitimate updates or panel/file-manager actions depending on the host. Group ownership and timestamps are supporting evidence, not definitive source attribution.
Compare ownership with known deployments and audit logs. Preserve metadata before changing permissions or copying files.
On containerised or managed hosting, ask the provider how web and control-panel writes are represented.
Check non-WordPress assets
Unknown server cron, altered mail forwarding, changed DNS, modified PHP configuration or files outside any WordPress root point beyond a normal application compromise.
Review database-management tools and server-level auto-prepend configuration. Do not execute suspicious system files.
Escalate root/system-package changes to the infrastructure owner.
Consider secrets readable by WordPress
Even an application-only compromise can expose database credentials, salts and embedded SMTP/API keys from configuration. That may later become database, mail or third-party compromise without a stolen panel password.
Inventory secrets available to the PHP process and rotate them in a controlled order. Restrict future credentials to the minimum service and site.
Choose recovery scope
For WordPress-only evidence, rebuild the affected site and rotate secrets readable by it. For hosting-account evidence, secure primary email, panel, all site users/keys, databases, mail, backups and DNS.
When uncertain, use the broader containment scope while continuing analysis. Narrow convenience must not leave shared access active.
Separate sites/users during recovery where practical.
Verify the boundary after recovery
Monitor panel logins, file changes across roots, WordPress privileged actions, cron and outbound mail. Test every affected site’s business functions.
Document evidence, uncertainty and why the chosen scope is sufficient. Retain snapshots and logs under policy.
Request urgent multi-layer recovery when sibling sites or server configuration changed. Share the topology and redacted events—never master credentials, full backups or private keys.