Quick summary
A security cleanup note about distinguishing a real WordPress compromise from a separate hosting firewall problem that was blocking external site-health crawlers.
The problem
A site-health crawl failed while the WordPress installation also contained backdoor code, injected theme scripts, a malicious plugin, and an unauthorized administrator account.
What I checked
- Crawler responses at the hosting and firewall layers
- Theme files, plugins, administrator accounts, and database content
- Known malicious code and persistence patterns
- Post-cleanup WordPress file and database indicators
- Frontend presentation affected by removed compromised files
What I changed
- Removed the backdoor code, injected scripts, malicious plugin, and unauthorized account
- Swept the database for remaining indicators
- Verified the WordPress installation after cleanup
- Documented the remaining firewall issue as a separate hosting task
- Repaired footer styling affected by removal of the compromised theme code
Result
The WordPress compromise was cleaned without falsely treating the unrelated firewall crawl block as evidence that malware remained.
Where this fix usually leads next
This kind of work usually connects back to WordPress Support and Technical SEO so the fix note can lead into a clearer support path instead of staying as an isolated one-off task.
What I'd watch next
- Whether the hosting provider adjusts the crawler-blocking rule
- Whether file monitoring detects the removed patterns returning
- Whether all administrator credentials and salts have been rotated