A site gets hacked. Someone deletes the suspicious files, changes the passwords, and everything looks normal again. Five days later the spam redirects are back.
This happens because file deletion treats the symptom. The attacker got in through something, and that something is still open.
What is usually going on
WordPress itself is rarely the way in. In most of the cleanups we do, the entry point is one of a small handful of things:
- An outdated plugin with a known, publicly documented vulnerability.
- A nulled or pirated premium theme or plugin, with the backdoor shipped in the download.
- A weak or reused administrator password, with no rate limiting on the login page.
- A neighbouring site on the same shared hosting account, cross-infecting through the file system.
- Stale FTP or hosting-panel credentials that were never rotated after a previous compromise.
Until you know which one it was, you are cleaning up after an attacker who still has the key.
The signs people notice first
Malware rarely announces itself. Typically the first symptom is indirect: mobile visitors get redirected to another domain but desktop visitors do not, Google Search Console reports pages you never wrote, outgoing email starts landing in spam because the server is sending bulk mail, or the site suddenly gets slow because it is doing work for someone else.
Admin users you do not recognise, and PHP files with recent modification dates in wp-content/uploads, are the clearer signals. Nothing legitimate writes executable PHP into the uploads folder.
What a proper cleanup involves
The order matters. Done properly it looks roughly like this.
Take a copy before touching anything
Files and database, kept aside. The infected copy is evidence: it tells you when the first malicious file appeared, which is how you narrow down what was exploited.
Compare against known-good code
Core files, and plugin and theme files from the official versions, can be compared byte for byte with a clean copy. Anything that differs is either a legitimate customisation or an injection, and it is usually obvious which. This is far more reliable than scanning for suspicious-looking strings.
Do not forget the database
Injections live in the database as often as in files: scripts in wp_options, redirect code in widget content, spam links inserted into post content, and scheduled cron entries that reinstall the payload after you have cleaned the files. A file-only cleanup on a database-infected site fails within days.
Close the entry point
This is the step that gets skipped. Update or remove the vulnerable component, replace any nulled software with a licensed copy, rotate every credential including database and hosting-panel passwords, remove unknown admin users, and check for leftover backdoors in places people rarely look — mu-plugins, .htaccess, and scheduled tasks.
Then harden
Disable file editing from the dashboard, block PHP execution in the uploads directory, add rate limiting to the login page, keep everything updated, and take backups you have actually tested restoring. Hardening after a cleanup is worth far more than hardening in the abstract, because you now know exactly what was exploited.
What nobody can honestly promise
No one can call a site “100% secure”. Anyone who does is selling something. What is realistic is this: find the root cause rather than only the visible files, clean both the file system and the database, close the way in, and reduce the chance of it happening again.
If your site has been cleaned before and the problem has come back, the entry point was almost certainly never found. Send us the details and we will look at what is actually happening, or read more about security and malware work first.
Add comment