What to know about WordPress backdoor hacks

A backdoor is hidden access an attacker leaves so they can return without using the original bug or password. On WordPress that often means a small PHP file, a poisoned theme function, a rogue admin user, or a webshell that runs commands through the browser.

Cleaning one obvious malware file while leaving a backdoor is how sites get reinfected a week later. This guide covers how backdoors get in, where to look, how to remove them, and how to make return visits harder.

What a WordPress backdoor is

Think of normal login as the front door. A backdoor is a quiet side entrance: a file under uploads, an eval chain in functions.php, a must-use plugin you never installed, or a scheduled task that rewrites files.

Attackers do not only chase famous brands. Automated scans hit small sites with outdated plugins, weak admin passwords, or nulled themes. Once inside, the operator may:

• Redirect visitors to spam or phishing pages
• Inject SEO spam or drive-by downloads
• Steal credentials and customer data
• Use the server for outbound spam or further attacks
• Create extra admin accounts (privilege escalation) so access survives a password change

A teaching metaphor for multi-layer persistence (dropper plus hidden shells plus database hooks) is covered in backdoor injection patterns. The practical cleanup path is the same: find every persistence point, not just the first file.

Common places backdoors hide

Themes

Active and abandoned themes both get abused. functions.php is a frequent plant point for code that creates administrators, auto-loads remote PHP, or hooks into init / wp_head. Child themes and unused parent themes in wp-content/themes/ are easy to miss.

Plugins and mu-plugins

Vulnerable or abandoned plugins are a common entry. After exploitation, attackers may drop files inside the plugin folder, add a must-use plugin under wp-content/mu-plugins/, or leave a webshell with a random name. Unused plugins still load code paths attackers can hit. Delete what you do not need.

Uploads and odd PHP

Anything ending in .php under wp-content/uploads/ deserves a hard look. Double extensions (image.php.jpg) and files that only look like images show up often. Compare against a clean backup.

Core and config

Modified index.php, wp-config.php, or core files under wp-admin / wp-includes mean integrity is broken. Prefer restoring known-good WordPress files over hand-editing obfuscated lines. See file integrity monitoring.

Database and users

Not every backdoor is a file. Look for unknown administrators, odd option_value rows that store PHP, and malicious content in posts or widgets that loads remote scripts. If you need emergency admin access while cleaning, use authorized recovery patterns such as creating an admin via FTP or a temporary recovery hook, then remove that code immediately.

Signs you may have a backdoor

• Google Safe Browsing or host abuse notices
• Redirects or popups you did not add
• New admin users or plugins you did not install
• Files modified when nobody was working on the site
• Outbound spam complaints about your server
• Cleanups that “work” for a day, then the same malware returns

Returning malware almost always means a leftover backdoor, stolen credentials, or an unpatched vulnerability still open.

How to find and remove backdoors

1. Contain and back up

Put the site in maintenance mode or take it offline. Snapshot files and the database before you delete anything. You may need the copy for comparison or for your host.

2. Scan and compare integrity

Run a malware scanner and compare WordPress core (and ideally themes/plugins) against clean copies. Checksums and file integrity monitoring surface edits signature scanners miss.

On the server, listing recently changed files helps narrow scope. Example (files modified in roughly the last two weeks):

find ./ -type f -mtime -15

Review the list carefully. Legitimate updates also change files.

3. Hunt persistence, not just one file

Search for suspicious patterns such as eval(, base64_decode(, remote include/require, and unknown admin users. Expect multiple variants. Obfuscation like string concatenation ("e"."v"."al") exists specifically to dodge naive greps.

When you find malicious code, remove it by restoring clean plugin/theme/core packages where possible. Then reset all privileged passwords and keys (including salts in wp-config.php if you rotate them as part of incident response).

4. Who to contact (and who not to)

WordPress.org support cannot clean your infected site. Escalate to:

• Your hosting provider (malware teams, restore from a clean backup, server-level scans)
• A security plugin workflow and logs you already trust
• A professional cleanup if reinfection continues or you lack file/database access (consultation)

Plugin authors can confirm whether a snippet is meant to be in their product. They are not a substitute for full incident response.

Full playbooks: WordPress malware removal and what to do if your site is hacked.

Preventing backdoors

• Unique passwords and two-factor authentication for every administrator
• Keep core, themes, and plugins updated; remove unused code
• Avoid nulled or unknown “GPL club” packages (plugin supply chain risk)
• Limit who has admin rights (least privilege)
• Use a firewall to cut mass exploit traffic
• Keep offsite backups you can actually restore
• Review login security so stolen or guessed passwords are less useful

Keeping the site clean

Backdoors succeed when updates slip, admins share passwords, and “one file delete” counts as cleanup. Scan until findings stay clean, close the entry hole, rotate credentials, and turn on MFA. That is how you stop the quiet return visit.