A backdoor is a piece of code an attacker leaves behind so they can come back later, even after the original entry point has been closed. The first compromise is the door. The backdoor is the second key, hidden somewhere on your site, waiting to be used. WordPress backdoors are some of the most common artefacts found during forensic audits, and most owners have never thought about them as a category.
This article walks through how backdoors get planted, where they typically hide, and how to find them on your own site.
Why attackers plant backdoors
Getting into a WordPress site for the first time takes effort. Finding a vulnerable plugin, exploiting it, navigating the site. Once they are in, attackers want to make sure they can come back without doing all that work again. A backdoor is insurance against the original vulnerability being patched.
This is why simply patching the entry point after a compromise is not enough. The attacker is probably still on the server. Until you find and remove the backdoor, every cleanup is temporary.
The classic forms of WordPress backdoor
The most common backdoors fall into a small number of recognisable patterns.
Obfuscated PHP. A small piece of code, often only a few lines, that uses eval combined with base64_decode, gzinflate, or str_rot13 to execute a payload sent as a parameter. The code looks like nonsense at a glance, which is the point. Variants include patterns like eval, assert with user controlled input, preg_replace with the now removed e modifier, and direct calls to shell_exec or system with input from $_GET, $_POST, $_REQUEST, $_COOKIE, or $_SERVER.
Web shells. A dedicated PHP file that gives the attacker a web based file manager or command runner. Names like c99shell, r57shell, WSO, and FilesMan are infamous. A web shell is a tiny administrator panel sitting on your server that you did not put there.
Rogue admin accounts. A new user with administrator role created during the original compromise, often with a username that looks slightly off or an email at a domain you do not recognise. The attacker can return any time by logging in with that account.
Cron based reinfection. A scheduled WordPress task that recreates malicious files if they get deleted. Even if you clean up the bad files, the cron silently puts them back the next time it runs.
Modified core, theme, or plugin files. The attacker edits a legitimate file to include a small block of malicious code. The file still works as expected, but it also executes the attacker’s payload when triggered.
Where they hide
Backdoors prefer the dustiest corners of a WordPress install. Some common hiding places are worth knowing.
The wp-content/uploads tree. Uploads should contain media. PHP files there are almost always suspicious. A recent audit on a Sydney agency site explicitly cleared this folder and found only a handful of trivial WordPress hardening stubs. Anything beyond that should be investigated.
Files with names that look like core. wp-loadx.php, wp-shell.php, wp-cron-extra.php, wp-log.php. A name that almost matches a real WordPress file is a deliberate camouflage choice.
Image files with embedded PHP. A file with a .jpg or .png extension that actually contains PHP code at the start of the file. If something on the server then includes that file as PHP, the payload executes. Rare but real.
Inside legitimate plugin or theme files. The attacker adds a small block at the top or bottom of an existing file. The file still works, but it also runs the backdoor.
wp-config.php and its variants. Sometimes via an auto_prepend_file directive that includes a malicious payload before every request. Sometimes by injecting a constant or include statement directly.
How to scan for backdoors
You do not have to be a security professional to run useful checks. A reputable security plugin like Wordfence will perform a deep scan and report any matches against its signature database. The free version does this well. The paid version updates its signatures faster and adds vulnerability monitoring.
Beyond plugins, you can do a manual sweep. Look at every .php file outside wp-admin, wp-includes, and the plugin and theme folders. Look at recent modification times to spot files changed in the last weeks that you cannot account for. Search the codebase for the suspicious patterns mentioned earlier. Anything matching deserves a closer look.
Compare WordPress core files against the official versions. Several tools do this, including Wordfence and the official wp cli tool. Any differences in core files are red flags.
Cleaning up after finding a backdoor
Finding one backdoor rarely means there is only one. Attackers often plant multiple, in different locations and different forms, so that finding one does not lock them out. After identifying a backdoor, expand the search. Look everywhere similar, look for similar patterns, look at every file modified around the same time.
Rotate every credential. Salts and keys, WordPress passwords, database password, API keys, SFTP keys. Reset every session. Re audit users. Re audit plugins. Move to a clean backup from before the compromise if you can identify the date.
Preventing backdoors in the first place
Backdoors are the second layer of a compromise. Prevention is mostly about preventing the first layer. Keep core, themes, and plugins updated. Remove file managers and shell access plugins you do not need. Limit administrator access. Use 2FA. Run a security plugin that monitors for new files in unexpected places.
If you do those things consistently, the chance of a backdoor being planted on your site drops dramatically. Once a site is well defended, attackers move on to easier targets.
Need a hand?
If you suspect there might be a backdoor on your WordPress site, or if you have just completed a cleanup and want a second pair of eyes to verify, Smart Coding can run a forensic scan and tell you exactly what we find. Get in touch and we will give you a clear answer either way.
