Website Security
WordPress Website Infected with Malware (WordPress Repair)
Last reviewed
Direct answer
A WordPress malware infection means malicious code is living in your files or database — contain visitor exposure, preserve a forensic copy, clean or restore from a known-good backup, then rotate every credential and close the entry point before you reopen traffic.
Malware on WordPress is often quieter than a full “site hacked” crisis at first: scanners flag PHP in uploads, checksums fail, or odd files appear while the homepage still looks fine. This guide focuses on infection indicators and a cleanup path — not general compromise symptoms like spam redirects alone (see the related hacked and redirect guides). Safe WordPress Repair means evidence first, clean restore or trusted file replacement second, then hardening so the same payload cannot reappear overnight.
Key facts
Verifiable numbers and definitions — each claim links to its source.
- WordPress's hacked-site FAQ treats Indicators of Compromise—blacklists, host shutdowns, malware flags, unexpected users—as the symptoms that define the incident. (FAQ My Site Was Hacked)
- Official cleanup guidance says regenerating secret keys in wp-config.php forces logged-in sessions off after you lock down access. (FAQ My Site Was Hacked)
- WordPress recommends replacing core wp-admin and wp-includes directories from a clean copy of the same version via SFTP, not the in-dashboard reinstaller alone. (FAQ My Site Was Hacked)
- Google Search Console's Security issues report is the documented place to review malware and social-engineering warnings Google issued for the property. (Google Security issues report)
What the error means
“Infected with malware” usually means executable or injectable code an attacker planted — web shells in uploads, trojanized plugins, modified core/theme files, or database-stored scripts that load on page view. Hosts and Google may detect it before you notice customer complaints. Unlike a broad “we got hacked” narrative, the repair job here is identifying where the payload lives, removing it without destroying the business site, and proving the install is clean. Rescue 404 approaches malware as a containment and rebuild problem: forensic backup, credential rotation, clean packages, upload/database scrub, then review requests — never by running attacker tooling or “testing” unknown PHP in a browser.
Common symptoms
- Hosting or security scanner reports malware, quarantines files, or marks paths as infected
- Unexpected `.php` files appear under `wp-content/uploads` or inside image/media folders
- Core, plugin, or theme file checksums fail or modification dates jump without a legitimate update
- Site intermittently injects hidden iframes, drive-by scripts, or crypto-mining tags in page source
- Search Console lists malware / hacked content security issues even when the homepage looks normal
- CPU or outbound connections spike from PHP processes you did not authorize
- Antivirus or browser extensions warn on specific URLs while other pages still load
Most likely causes
- 01 Vulnerable or abandoned plugins/themes left unpatched after a public CVE
- 02 Stolen SFTP, panel, or wp-admin credentials used to drop webshells
- 03 Nulled “premium” extensions that ship backdoors as part of the package
- 04 World-writable directories or PHP execution allowed inside uploads
- 05 Infected workstation or agency laptop deploying compromised files
- 06 Shared-host neighbor compromise pivoting into your account
- 07 Old backup archives or installers left downloadable in the web root
What changed before the problem started
- Host malware notice, quarantine email, or account “cleanup required” ticket arrived
- New plugin/theme installed from an unofficial zip or “null” marketplace
- Missed updates stacked up for weeks while the site stayed “working”
- Staff or vendor access changed without rotating shared passwords
- File integrity / security plugin first reported modified core files
- Traffic or error logs show probes hitting odd PHP paths under uploads
Troubleshooting steps
- 01
Limit public harm and take a labeled forensic backup
If visitors may download malware, enable maintenance mode or ask the host to restrict public PHP where possible. Before deleting anything, download full files + database into an offline archive named with today’s date and “infected-forensics.” Success signal: you have a complete copy and unauthorized editors cannot log in (reset passwords on accounts you still control).
- 02
Rotate every secret that touches the stack
Change WordPress admins, hosting panel, SFTP/SSH, database, CDN, and DNS/registrar passwords. Revoke application passwords and unused users. Treat `wp-config.php` salts and DB credentials as potentially stolen — update the database password in the panel and config together. Success signal: former passwords fail everywhere and only known people retain access.
- 03
Restore a pre-infection backup when you have one
Prefer a host or backup-plugin snapshot from before scanner alerts or odd file dates. Restore files and database as a set, then update core/plugins/themes immediately on a secured session. Success signal: previously flagged paths are gone and a fresh malware scan against the restored tree is clean.
- 04
Rebuild from official packages if no clean backup exists
Reinstall WordPress core and delete/reinstall plugins and themes from wordpress.org or licensed vendors — do not surgically “edit out” lines in nulled code. Quarantine executable PHP under uploads; replace media from known-good copies when files were overwritten. Success signal: core/extension trees match clean zips and uploads contain no runnable PHP.
- 05
Scrub persistence points attackers reuse
Inspect `mu-plugins`, drop-ins (`object-cache.php`, `advanced-cache.php`), rogue cron, unknown admins, and altered `.htaccess`. Remove only after you have the forensic copy. Success signal: logged-out browsing shows no injected scripts and only expected must-use code remains.
- 06
Verify clean, then harden and request external review
Rescan with the host tool and your security plugin. In Google Search Console, open Security issues and request review after cleanup if malware was listed. Turn on sensible auto-updates, remove unused extensions, enforce 2FA, and store backups off the web root. Success signal: scanners stay clean for 24–48 hours and review is submitted or cleared.
When to stop troubleshooting
Stop DIY cleanup if malware returns after each clean pass, you lack a trustworthy backup and cannot safely rebuild, payment or personal data may have been exposed, the host demands a professional remediation letter, or database injections are beyond your comfort with serialized WordPress data. Hand Rescue 404 the forensic archive, scanner output, first-alert timestamp, and a list of everyone with admin or SFTP access.
Information to collect before requesting help
- 01 Host or plugin scanner report listing infected paths
- 02 First alert date/time and whether the homepage still looked normal
- 03 Example URLs or file paths flagged as malware
- 04 Whether a pre-alert backup exists and its timestamp
- 05 WordPress, PHP, and hosting provider versions
- 06 Recent plugin/theme installs and update history
- 07 Who had wp-admin, SFTP, and panel access in the last 90 days
How a professional repairs the problem
Rescue 404 preserves the infected state, rotates credentials, and restores or rebuilds from clean packages while scrubbing uploads and database injections. Technicians remove persistence (mu-plugins, drop-ins, cron, bad server rules), verify a logged-out clean browse, coordinate host unsuspend or Google review when needed, and harden updates and access so the same malware family cannot walk back in — without demonstrating or running exploit payloads.
Frequently asked questions
Is “malware infected” different from “WordPress hacked”? +
Can I delete one flagged file and go live? +
Will a security plugin alone remove WordPress malware? +
Should I keep the site online during cleanup? +
Do I need Google review after a file-only infection? +
When should I call Rescue 404? +
Repair dispatch
Still Need Help Fixing Your Website?
If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.
- You will receive a clear explanation of the likely cause.
- We will tell you if the issue falls outside our repair scope.
- No additional work will be performed without approval.
- A backup should be created whenever access and website condition allow it.
Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.