In short: The fastest way to find a WordPress backdoor is to compare core and plugins against the official checksums with WP-CLI, and then look specifically at mu-plugins, uploads, wp-config.php, admin accounts and the database. Important after PHP2Shell: a WordPress update does not close the PHP vulnerability and does not remove an existing backdoor.
Why WordPress operators should look more closely now
With PHP2Shell, two critical vulnerabilities in PHP itself became known in October 2026, CVE-2026-109618 and CVE-2026-109619. They allow the execution of malicious code without authentication, regardless of how well your WordPress installation is maintained. Patches have been available since 21 October 2026, but according to media reports a first attack attempt was already observed on 17 October.
Anyone who was vulnerable during this period should look for traces. WordPress is a typical target, because many installations are built similarly and attackers know the hiding places. What operators have to do about PHP2Shell in general is on the page WordPress and PHP2Shell.
Work through the following checks on a copy if possible, or after a backup. The commands only read and change nothing.
How you notice a backdoor in everyday operation
A backdoor is designed to stay inconspicuous. Still, there are signs that stand out even without technical knowledge. These include redirects to foreign sites that occur only for visitors from Google search or only on mobile devices. Equally suspicious are new pages advertising medicines, gambling or copies of branded products that appear in the search index but not in the WordPress backend.
Further indications are warnings from Google or the browser, customer complaints about spam emails from your domain, a suddenly sharply increased consumption of compute time at the hosting provider, or administrators nobody on the team knows. None of these signs proves a backdoor on its own. If several occur together, you should not postpone the following checks.
The reverse also applies: if none of this stands out, that does not mean the installation is clean. Backdoors created only for later access in particular often show no effect to the outside at all.
Finding a WordPress backdoor: checking core and plugins
WP-CLI can compare the files of the WordPress core and of plugins from the official directory with the published checksums. Every deviation is a concrete item to investigate.
cd /var/www/meine-seite
# Core files against the official checksums
wp core verify-checksums
# Plugins from the official directory
wp plugin verify-checksums --all
# Installed versions and status
wp plugin list
wp theme list
Commercial plugins and themes cannot be checked this way. For them, the only option is comparison with a freshly downloaded original package from the vendor. Unknown plugins that nobody on the team installed are always suspicious, even if they appear deactivated.
Typical hiding places in the file system
A few places turn up again and again in compromised WordPress installations:
wp-content/mu-plugins/: loaded automatically and does not appear in the normal plugin list.wp-content/uploads/: images and documents belong there, not PHP files.wp-config.php: additionalincludeorrequirelines at the beginning or end..htaccessand.user.iniin the web directory and subfolders: unexpected redirects or automatically prepended files.- Files in the root directory whose names resemble WordPress core files but do not belong to it.
# PHP files in the uploads folder
find wp-content/uploads -type f -name "*.php*"
# Contents of the must-use plugins
ls -la wp-content/mu-plugins/
# All .htaccess and .user.ini files with modification date
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Recently modified PHP files
find . -type f -name "*.php" -newermt "2026-10-17" -ls
General search patterns for obfuscated code are described in the guide Detecting and removing webshells.
Checking users, database and scheduled tasks
Many backdoors are not in the file system at all. An additional administrator account is often enough for attackers to come back later.
# All administrators with registration date
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Scheduled tasks in WordPress
wp cron event list
# Site address (tampering leads to redirects)
wp option get siteurl
wp option get home
# Posts with embedded scripts
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Also check options with unusually large contents and widgets with foreign code. Hits do not automatically mean an attack, since tracking codes or embedded maps also use scripts. What matters is whether anyone on the team knows the content.
After a find, change all passwords and the security keys in wp-config.php. Otherwise the attackers' existing logins remain valid.
Closing backdoors and preventing a return
If you have found a backdoor, a fresh installation is usually safer than repairing individual files. This order has proved its worth:
- Preserve evidence: store logs, suspicious files and a database export with the date.
- Bring PHP to a fixed version and restart all PHP processes.
- Install the WordPress core, plugins and themes fresh from original sources.
- Carry over uploads and database after checking them, delete foreign accounts, change all credentials.
- Prevent PHP execution in the uploads folder at server level.
For Nginx, a block in the server configuration is enough:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
On Apache you achieve the same with a rule in the server configuration for the uploads folder. A .htaccess in the uploads folder itself is weaker, because an attacker with write permissions can change it again.
After the cleanup, plan for a few weeks of closer monitoring. New administrators, new PHP files and changes to wp-config.php should be noticed immediately during this time, for example through a regular check with WP-CLI or file monitoring on the server.
How to set the file permissions afterwards so that WordPress may write only where necessary is shown in the guide File permissions on the web server.
How does PHP SOS help?
- We secure the state of the installation before anything is changed.
- We check core, plugins, themes, database, accounts and server configuration for backdoors.
- We rebuild WordPress from clean sources and carry over only checked content.
- We harden the server and the installation and document what was found and fixed.
The process of a cleanup is described in the service Having malware and webshells removed.
Frequently asked questions
Does a WordPress update close the PHP2Shell vulnerability?
No. PHP2Shell sits in the PHP interpreter, not in WordPress. An update of WordPress, themes or plugins changes nothing about that; what matters is the server's PHP status and a restart of all PHP processes.
Does a security plugin find all backdoors?
Not reliably. A plugin runs inside the compromised installation and can itself be tampered with. Complement it with checks from outside, such as WP-CLI checksums and a comparison with clean original files.
What are mu-plugins and why are they suspicious?
Must-use plugins in the folder wp-content/mu-plugins are loaded automatically and do not appear in the normal plugin list. Attackers like to use this because operators rarely look at this folder.
Can a backdoor also be hidden in the database?
Yes. Malicious code or redirects are often stored in options, posts or widgets. Attackers also frequently create their own administrator accounts, which you can find in the users table.