A WordPress backdoor is hidden code that lets an attacker return after the visible malware is removed. To find one, check changed files and unexpected accounts, verify WordPress core with WP-CLI, inspect common hiding places, and replace trusted files from clean sources instead of editing a few suspicious lines.
A backdoor can be a full WordPress web shell with a command interface, but it is often much smaller. It may accept a request parameter, fetch more code, create an administrator, or quietly inject spam and redirects. That is why a site can look normal after a partial cleanup and then become infected again.
Preserve the site before making changes
The first step is to make a complete copy of the WordPress files and database. Keep it outside the web root and make sure it is not publicly downloadable. Preserve web server, hosting, FTP or SFTP, and WordPress logs if they are available. They may show when a file appeared or which account was used.
If the site is actively redirecting visitors, serving malware, or sending spam, limit public exposure in a way that fits the business. A maintenance page or host-level restriction can be safer than trying to delete files while attackers are still using the site. Work from a clean computer and do not execute a suspicious PHP file to see what it does.
Document the date, full path, permissions, modification time, and a copy of each suspicious file. Those details help you distinguish deliberate custom code from a new addition, and they make it possible to review the cleanup if the problem returns.
Know the patterns, but do not treat one string as proof
Backdoors commonly try to hide their purpose with encoded or compressed text. Searches often find functions such as base64_decode, gzinflate, eval, str_rot13, and assert. Code may join strings together, use variable variables, or hide a payload in a long unreadable blob. A web shell may also accept data from $_GET, $_POST, or cookies and pass it into a dangerous function.
None of those function names proves a file is malicious. A legitimate plugin may use encoding or compression. The evidence becomes stronger when the code is in an unexpected location, has no clear purpose, is heavily obscured, appeared recently, or came from a file you cannot match to a trusted release. Check the full file and its source before deciding.
Attackers also use normal-looking names. A file called cache.php, class-api.php, or wp-update.php is not trustworthy just because it sounds ordinary. Compare it with the correct WordPress, theme, or plugin distribution rather than judging it by filename.
Check WordPress core with WP-CLI
WP-CLI can compare installed WordPress core files with the official checksums for the installed version. From the WordPress root, run wp core verify-checksums. A clean result is useful, and any reported modified, missing, or unexpected core file needs review.
If the command cannot identify the site because of file ownership or configuration, run it as the same system user that owns the WordPress files, or ask the host for help. Do not use a command failure as evidence that the files are clean. Also check that WP-CLI itself is available from the correct site directory, especially on a server that hosts several WordPress installations.
This command only covers WordPress core. It does not check files in wp-content, custom code, a modified wp-config.php, or database injections. Use it to identify core replacements you need to make, then continue the review. Our article on verifying a WordPress installation explains why version and file integrity both matter.
Look in the places backdoors favor
Start in wp-content/uploads. That directory normally contains media uploads, so PHP files there are unusual and should be investigated immediately. Look for nested folders, double extensions, recently modified files, and names that do not fit the site's media workflow. Do not assume a file is safe because it is small.
Next inspect wp-content/mu-plugins. Must-use plugins load automatically, so they are easy to miss in a dashboard review. Inspect all folders under wp-content/plugins as well, including inactive plugins and folders that do not correspond to an installed plugin you recognize. Fake plugin folders are a common persistence point.
Review active and inactive theme folders, with special attention to functions.php and files that run on every page. Also inspect wp-config.php, which is a high-value target because it loads early and contains database settings. If your site has custom drop-ins or server-managed files, identify their owner and purpose before replacing them.
Finally, check WordPress administrators and the database for unfamiliar settings or users. A file backdoor is only one way an attacker persists. The guide on finding hidden WordPress admin users covers the account review.
Search safely and narrow the results
Search the WordPress files from the server shell or through a local copy, but exclude backups, cache, vendor libraries, and large media folders where possible. This reduces noise and avoids spending time on files that do not run as WordPress code. Start with PHP files in wp-content, then expand if needed.
For example, grep -RIn --include='*.php' 'base64_decode' wp-content searches PHP files under wp-content and prints matching line numbers. Repeat the same form for gzinflate, eval, str_rot13, and assert. The -R option searches recursively, -I skips binary files, and -n makes a result easier to review. Use grep -RIn --include='*.php' 'eval[[:space:]]*(' wp-content when you want to focus on calls to eval rather than comments that merely mention the word.
Do not run or paste a matching payload into an online decoder from a production system. First read the surrounding lines with a text editor, identify the file's source, and make a copy for analysis. Searches find candidates, not conclusions. An attacker can avoid these exact functions, and legitimate code can contain them.
Also list recently changed PHP files, but treat file timestamps cautiously because migrations and updates modify legitimate files. If you use a shell, find wp-content -type f -name '*.php' -mtime -14 -print can list PHP files changed in the last 14 days. Adjust the number only after you know the date of the suspected incident.
Replace files instead of repairing them
Replacing a trusted file is safer than repairing it by hand. A backdoor can add a short loader in a second location, alter whitespace to hide a change, or place its code before a normal-looking closing PHP tag. Removing the obvious block does not prove you found every change.
Replace WordPress core with clean files from the same release. Reinstall trusted plugins and themes from their official source, then restore custom themes and plugins from a known-good repository or backup. Do not overwrite wp-config.php blindly because it contains environment-specific settings. Instead, compare it against a clean configuration pattern and remove only verified unauthorized additions after preserving a copy.
Remove unused themes and plugins after confirming you have a backup. Delete fake plugin folders and unauthorized files rather than merely deactivating them. Then update WordPress, plugins, and themes to close the route that allowed the compromise. The WordPress hardening checklist is a useful follow-up once the site is clean.
Close access and verify the cleanup
Rotate WordPress administrator passwords, hosting control-panel passwords, SFTP or SSH credentials, database credentials, and application tokens that could have been exposed. Review access to the domain registrar, DNS, CDN, and code repository as well. Remove users and keys that no longer have a current owner.
Re-run wp core verify-checksums, repeat the targeted searches, and test the public site while logged out. Monitor for new files, strange redirects, unknown users, and repeated modifications. If a suspicious file reappears, stop treating it as a single-file problem and investigate the remaining entry point or persistence mechanism.
When to get help
Get help if you find an unfamiliar web shell, cannot tell whether custom code is safe, or see files returning after replacement. West Oakbridge's WordPress malware removal and automated remediation services can help establish a clean baseline and identify what needs further review.