Unexpected administrator accounts, changed pages, unknown PHP files or suspicious redirects may indicate a compromised WordPress installation. The priority is to contain risk without destroying evidence needed to understand what happened.
Reduce exposure without erasing evidence
Restrict access or temporarily isolate the affected environment, according to business impact. Preserve copies of files, database and relevant server logs before cleaning. Record timestamps and symptoms. Randomly deleting unfamiliar files can destroy evidence or leave hidden backdoors untouched.
Identify the possible entry point
Investigate outdated plugins and themes, weak or reused credentials, compromised FTP access, malicious administrator sessions and vulnerable hosting components. Review file changes and access logs. A damaged page alone does not prove that a particular customer computer was infected; distinguish evidence from hypotheses.
Rotate access in a sensible order
From a trusted device, change hosting, FTP/SFTP, database and administrator credentials and revoke sessions or API keys as appropriate. Use multifactor authentication wherever available. If the workstation itself may be compromised, examine it before relying on newly changed passwords.
Restore only from trusted sources
Use a verified clean backup or reinstall WordPress core and extensions from legitimate distributions. Compare configuration and database content carefully because malicious users, injected content and scheduled tasks may persist beyond file replacement. Test the recovered site away from production.
Check the full scope of the incident
Inspect other sites on the same account, shared directories, database users, mail settings and scheduled jobs. Check whether personal data or customer records might have been affected and assess any applicable notification duties with the relevant professionals.
Prevent recurrence
Patch vulnerable components, remove abandoned accounts and extensions, enforce least privilege and verify backups. Add monitoring for unexpected file and account changes. Keep an incident log so recurring symptoms can be connected to a root cause rather than repeatedly cleaned in isolation.
Frequently asked questions
Does a suspicious file prove a visitor's PC is infected?
No. That is only one possibility. Server logs, credentials and file history are needed before attributing the cause.
Is deleting malicious-looking files enough?
Not reliably. Backdoors, accounts, scheduled tasks and database injections can remain; validate the full environment.
Related guides on Concepty
- Website backups: why practising a restore matters more than having a file
- Updating WordPress with minimal disruption: a dependable process
- WordPress security best practices
For a specific implementation or compatibility question, explore Concepty services or contact Concepty.