WordPress cleanup
Removing infected WordPress files – what is safe to delete?
Removing infected WordPress files – what is safe to delete?
Removing infected WordPress files should not start by selecting every antivirus result. One false deletion can take the site down; one missed loader can rebuild the infection. Classify the finding first: a modified official file, a newly added malicious file, or legitimate custom code that merely looks suspicious.
Quarantine before deletion
Capture file and database backups and preserve logs. Record the path, hash, size and timestamps of each suspect file, then copy it to a non-public quarantine. Remove the live copy only when you understand what calls it and what clean component will replace it.
sha256sum wp-content/uploads/2026/08/suspect.php
stat wp-content/uploads/2026/08/suspect.php
Timestamps are not proof. Attackers can forge them, while legitimate updates modify many files together.
Core files: compare and replace
Official WordPress versions have known checksums:
wp core verify-checksums --include-root --version=$(wp core version)
Do not manually carve an injection out of a modified wp-admin or wp-includes file. Replace it from the exact official version. WordPress's hacked-site documentation explains that these directories can be reinstalled, but overwriting files does not remove extra files created by the attacker. Search for files that should never have existed after replacement.
Plugins and themes need a clean source
For WordPress.org plugins:
wp plugin verify-checksums --all --strict
Missing checksums for premium or custom software do not prove infection. Obtain the exact release from the vendor or compare it with a verified clean installation. WebShield can also compare components across protected sites when no official repository baseline exists.
Theme files such as functions.php, header.php and footer.php are common targets, but may contain legitimate customizations. Blind replacement can remove functionality.
Strong indicators of compromise
Treat these as high-priority findings:
- PHP under
uploads; - an unknown file in a core directory;
- randomly named PHP disguised as a system file;
- encoded data passed into dynamic execution;
- code downloading and executing remote content;
- an image extension with PHP content;
- an unexplained mu-plugin;
- a file created immediately after a suspicious POST request.
file wp-content/uploads/*/*
find wp-content/uploads -type f -iname '*.php' -o -iname '*.phtml'
rg -n "base64_decode|gzinflate|eval\(|preg_replace.*\/e" wp-content
No pattern is complete. Malware can split payloads, store them in the database, or use ordinary-looking PHP.
What file deletion cannot fix
Inspect administrators, cron events, wp_options, injected scripts in content, .htaccess and compromised credentials. A scanner can say clean while the mechanism that recreates the payload remains; see why Wordfence can miss an active compromise.
Professional response also correlates file creation with incoming HTTP requests. If a backdoor appears seconds after a request to a vulnerable plugin endpoint, you can close the cause rather than repeatedly deleting the result.
Verify after cleanup
Run checksums and searches again, clear caches, and monitor new file changes. Rotate credentials and salts, then patch or remove the vulnerable component. If a deleted file returns, active persistence remains.
The professional WordPress cleanup process treats the complete state and reinfection path, not just files. On a business site, that distinction prevents the next outage.