How to Check if a WordPress Backup Has Malware
A WordPress backup is only useful if it is clean.
This guide explains how to check if WordPress backup has malware before you restore it, so you can avoid reintroducing backdoors, malicious code, and hidden phishing pages.
Even if a backup looks normal on the surface, malware can hide in PHP files, database entries, uploaded media, and scheduled tasks.
The safest approach combines file inspection, database review, and offline scanning.
Why a backup can still contain malware
Backups capture the state of a site at a specific moment, including infected code that may already be active.
If an attacker modified core files, injected scripts into the theme, or planted a PHP web shell in uploads, the backup can preserve every trace.
Common places malware hides in WordPress backups include:
- Core files such as wp-config.php, index.php, and modified WordPress includes
- Themes with obfuscated PHP, base64 payloads, or suspicious includes
- Plugins with altered files or rogue add-ons
- Uploads containing PHP, .phtml, or disguised files
- The database with injected JavaScript, spam links, or malicious redirects
- Cron jobs that re-infect files after cleanup
Start with a safe, isolated copy
Never inspect or restore a suspected backup on your live server first.
Download the archive to a separate machine or a quarantined virtual environment and work on a duplicate copy.
This limits the chance of triggering malware or exposing credentials.
If possible, mount the archive read-only and extract it into a clean directory.
Keep the original backup untouched so you can compare versions later or share it with a security specialist.
What file patterns should raise suspicion?
When reviewing the backup contents, pay attention to filenames and code patterns that are common in WordPress malware.
Attackers often use legitimate-looking names to blend in with theme and plugin files.
- PHP files in wp-content/uploads
- Recently modified files with random names
- Scripts using eval(), assert(), base64_decode(), gzinflate(), or str_rot13()
- Long strings of encoded text that hide readable instructions
- Files with double extensions such as image.jpg.php
- Unexpected files in wp-includes or wp-admin
File timestamps can also help.
If many core or theme files changed at the same time as the infection, that may point to a coordinated compromise rather than a normal update.
Scan the backup with trusted security tools
To check if WordPress backup has malware, use more than one scanner.
No single tool catches everything, and different engines detect different patterns.
Useful options include:
- ClamAV for general malware scanning on extracted files
- Wordfence for comparing WordPress files against known clean versions
- Sucuri SiteCheck for reputation and remote indicators of compromise
- MalCare or similar WordPress security tools for known malicious signatures
Scan the extracted archive, not just the compressed file.
Some malware is hidden in nested folders, and some scanners work better when they can inspect the plain file structure.
Use diff tools to compare against clean WordPress files
Comparing the backup against a fresh copy of WordPress is one of the most reliable checks.
Download the same WordPress version from WordPress.org and compare core directories file by file.
Look for:
- Unexpected code in core files
- Extra includes added near the top or bottom of a file
- Modified functions that do not match the official release
- Injected scripts in header.php, footer.php, or functions.php
Tools such as WinMerge, Beyond Compare, Meld, or command-line diff utilities can speed up this review.
A small, hidden change in a core file is often enough to signal a compromise.
Inspect the database backup carefully
Database infections are easy to overlook because they do not appear as obvious files.
If your backup includes an SQL dump, search for suspicious content before importing it.
Common indicators in the database include:
- Spam links embedded in posts, comments, or widgets
- Injected JavaScript in post content or option values
- Unknown admin users or strange user meta entries
- Redirect URLs in siteurl, home, or custom plugin settings
- Base64-like strings inside wp_options or wp_posts
Open the SQL file in a text editor or import it into a local database and search for terms such as iframe, script, eval, onclick, and suspicious domains.
Also review the wp_options table, since many attackers store persistence there.
Check for persistence mechanisms
Even if you remove visible malware, persistence mechanisms can bring it back.
A backup may contain code that re-downloads malicious payloads or recreates infected files after every request.
Review these areas closely:
- wp-cron.php triggers and scheduled actions
- mu-plugins in wp-content/mu-plugins
- Customizer settings and widget text
- .htaccess rules that redirect users or block scanners
- wp-config.php for injected include statements
Also inspect server-side files outside the typical WordPress structure if your backup includes them.
Attackers sometimes place payloads in parent directories or backups of custom scripts.
How do you tell if the backup is clean enough to restore?
A backup is safer to restore when multiple checks agree: the file scan is clean, core files match the official release, the database contains no suspicious code, and no persistence mechanisms are present.
If only one area appears infected, treat the entire backup as unsafe until proven otherwise.
Before restoring, verify:
- The backup source date predates the first sign of compromise
- Admin passwords and API keys were rotated after the infection
- Plugin and theme versions are known good
- The backup does not include unexpected executable files in uploads
What to do if malware is found
If you confirm malware in the backup, do not restore it directly to production.
Instead, rebuild from known-clean WordPress core files, reinstall trusted plugins and themes from official sources, and manually migrate only clean content.
For content restoration, extract posts, pages, and media selectively while excluding infected code, rogue admin accounts, and malicious database entries.
Afterward, change all passwords, regenerate security salts, review access logs, and update every plugin and theme.
For high-risk cases, have a security professional review the backup and the live environment.
This is especially important if the site handles ecommerce, memberships, customer data, or payment details.
Recommended workflow for verifying a WordPress backup
- Create a quarantined copy of the backup.
- Extract the archive and scan all files with at least one offline malware scanner.
- Compare WordPress core files against a fresh official release.
- Review themes, plugins, uploads, and mu-plugins for suspicious code.
- Search the SQL dump for injected scripts, spam, and unknown users.
- Inspect .htaccess, wp-config.php, and cron-related files for persistence.
- Restore only after the backup passes every check.
Following this process gives you a reliable answer to how to check if WordPress backup has malware and helps prevent the common mistake of restoring a site that is already compromised.