WordPress Malware Removal

Malware removal is an incident-response process, not simply deleting the file named by a scanner. The immediate priorities are to contain harm, preserve evidence, regain control of accounts, identify the route of compromise, rebuild or clean from a trusted baseline and verify that the attacker cannot return.

Recognise incident indicators

• Unexpected redirects, pages, administrators or scheduled tasks
• Search results showing spam that is not visible to normal visitors
• Host, browser or security-service warnings
• Changed plugin/theme files or unknown PHP files
• Outbound email, high CPU or unusual network activity
• Customer reports of payment, login or download anomalies

Contain without destroying evidence

Restrict public access or use the host’s isolation tools if the site is actively harming visitors. Preserve server, access and security logs and take a forensic copy where competent support is available. Do not repeatedly browse a suspected site from an administrator computer or delete random files before the incident route is understood.

Recover control of every connected account

1. Use a known-clean device.
2. Reset hosting, registrar, WordPress, email, CDN and vendor credentials.
3. Review recovery email, MFA devices, API keys and application passwords.
4. Remove unknown users and revoke old supplier access.
5. Check DNS, email routing, payment and analytics settings for unauthorised changes.

Choose a clean recovery strategy

Recovery options

Option	When it may fit	Main risk
Restore a known-good backup	A trustworthy point exists before compromise	The vulnerable route or stolen credentials may remain
Rebuild from clean packages	Core, themes and plugins can be reinstalled and custom code reviewed	Requires careful data preservation and technical skill
Specialist incident service	Scope, evidence or business impact is significant	Needs clear authority, access and deliverables
Manual file deletion only	Almost never sufficient as the sole response	Missed persistence, modified database or reinfection

Remove the route of compromise

Update or replace vulnerable software, correct permissions, remove abandoned extensions, rotate secrets and patch custom code. Check administrator computers and shared credentials. If the site is restored without addressing the entry point, reinfection is likely.

Verify the recovered site

• Compare core and extension files with trusted distributions where possible.
• Inspect administrators, scheduled tasks, database users and configuration.
• Test forms, checkout, downloads, email and external integrations.
• Check logs and external security/search warnings over time.
• Confirm backups now contain a clean state and are not publicly accessible.

Consider notification obligations

If personal data, payment workflows or customer accounts may have been affected, record the assessment and obtain appropriate privacy, legal or payment-provider advice. Do not make unsupported assurances before the scope is known.

Post-incident closure

• Document the confirmed or most likely entry route.
• Record every account and secret rotated.
• Keep a clean baseline and new independent backup.
• Confirm external warnings and search results recover.
• Review whether customers, providers or authorities must be notified.
• Schedule monitoring and a follow-up review.

Do not close the incident merely because the homepage looks normal. Persistence, stolen credentials and altered external accounts can survive a visual cleanup.

Practical next step

If compromise is suspected, stop routine editing and open an incident record. Secure the registrar and hosting accounts from a clean device before attempting cosmetic cleanup inside WordPress.

Sources and date checked

This guide was checked on 21 July 2026. WordPress, plugins, hosting platforms and commercial terms change, so confirm the current documentation and licence details before making a material change.

• WordPress security handbook
• Hardening WordPress
• WordPress file permissions
• WordPress debugging guidance