New 24/7 monitoring and daily cloud backups now included in every Shield Pro plan.
WordPress malware removal case study
A UK agency site was showing defaced content, injected links, and browser security warnings. This case study follows the cleanup from containment through malware removal, access hardening, and review preparation.
The agency's marketing site was injecting spam links into footers and briefly showing a hijacked homepage overnight. Clients started forwarding screenshots of Google's security warning that the site may be hacked. Outbound pitches suddenly looked like they came from a compromised brand.
Admin users had reused passwords across tools, and an outdated plugin left a known entry point. Restoring last week’s backup alone would have brought the same malware back if the injection point stayed open. The team also could not tell whether client project URLs on shared hosting were involved.
They needed emergency cleanup with a clear price, proof the site was clean enough to request a Safe Browsing review, and hardening so the same plugin hole did not reopen the following night.
Before the repair
The visible problem appeared in several places, while other parts of the WordPress site continued to look normal.
Visitor experience
The homepage intermittently displayed unrelated content, spam links appeared across inner pages, and browser warnings discouraged visitors from continuing. The visible damage changed depending on the page and time of day.
What the site revealed
Unknown administrators, unsolicited password resets, scheduled tasks, and obfuscated PHP under uploads showed that this was more than a damaged homepage. The infection had several ways to remain active or return.
BugShield treated this as an emergency cleanup with a confirmed quote. The Vault held hosting, WordPress, and DNS credentials so the developer could work without passwords living in email threads or Slack.
Cleanup covered malware scanning, removing injected files and database spam, rotating compromised credentials, closing the outdated plugin hole, checking core file integrity, and preparing evidence for a Google Safe Browsing review once the public site was clean.
The developer also walked the agency through which client sites on the same host should be scanned next. Scope stayed on the marketing site they registered, with a clear recommendation rather than silent access to unrelated projects.
Stage 1
The agency sent screenshots of Google's security warning and the defaced homepage. They received a confirmed quote and a developer was assigned within an hour.
Stage 2
Admin passwords were changed, unknown users were removed, and the suspected plugin was disabled while we checked the site files.
Stage 3
Injected PHP, spam database rows, and .htaccess redirects removed. Core and theme files compared against clean copies.
Stage 4
Clean scan summary delivered with Safe Browsing review guidance. Shield Pro recommended for ongoing malware checks.
An abandoned contact-form add-on with a known CVE was the likely initial entry point.
Malicious PHP files in the uploads folder and a modified must-use plugin allowed unwanted footer content to keep returning.
Two unused administrator accounts still had administrator capability from past freelancers.
wp-config salts looked unchanged after the incident, so credential rotation alone was not enough without fresh keys.
A partial backup restore earlier that week had reintroduced one of the droppers because the backup was taken after infection started.
The outcome
Next day
Cleanup timeframe
The homepage returned to the agency’s brand within the cleanup window, and referral traffic started recovering after Google processed the review. The team kept daily malware scans on a Shield Pro plan and stopped relying on ‘restore last backup’ as their only security playbook.
Get a confirmed malware cleanup priceWhat changed
Backups without knowing the infection date can restore malware. Cleanup first, then take a clean restore point.
Reused agency passwords across client tools turn one breach into many. The Vault and rotation policy reduced that blast radius for future work.
A WordPress malware removal case study should show more than a clean homepage. Malicious code can sit in plugin folders, uploads, must-use plugins, scheduled tasks, database options, and user accounts. Each persistence point needs to be checked before the site can be treated as clean.
The cleanup also has to close the route used to gain access. Removing visible spam without replacing the vulnerable plugin, rotating privileged credentials, and refreshing security keys leaves the original weakness available.
Injected files and altered WordPress code
Database spam, redirects, and malicious options
Unknown administrators and active sessions
Scheduled tasks and must-use plugin persistence
The vulnerable plugin or compromised credential
A backup is useful only when it predates the infection and the entry point has been closed. One earlier restore had reintroduced a malicious file because the selected backup was created after the compromise began.
The safer sequence was to identify the infection, remove its persistence, close the vulnerable path, and then create a new clean restore point. That gave the agency a known state to return to without reviving the same payload.
BugShield removed the malicious content and documented the cleanup. The agency could then request a security review through Google Search Console with the site in a verifiably cleaner state.
Google controls its own review and warning-removal timetable. Cleaning the WordPress site makes a review possible, but it does not allow a developer to remove a browser or search warning directly.
The follow-up work focused on fewer privileged accounts, unique passwords, current plugins, refreshed WordPress salts, and monitoring for unexpected file changes. These controls make new activity easier to detect and limit the access available if one credential is exposed.
The agency also received a practical checklist for reviewing its other WordPress sites. Each site still needed its own evidence and scope, but the same access, update, and backup questions could be applied consistently.
Continue reading
WooCommerce checkout case study
A UK fashion store lost Stripe and PayPal payments after a plugin update. This case study follows the checkout failure from the first report through diagnosis, repair, and successful test orders.
Read case studyWordPress critical error case study
A UK charity site stopped loading after weekend WordPress updates. This case study follows the PHP error from inaccessible pages and wp-admin through plugin isolation, recovery, and live donation-form testing.
Read case studyWordPress downtime case study
A UK consultancy site became unreliable after an incomplete hosting migration. This case study follows the outage from conflicting DNS responses and certificate warnings through correction, external testing, and same-afternoon recovery.
Read case studyFAQ
Answers about the infection, cleanup process, Google warnings, reinfection checks, pricing, and recovery timeframe.
The cleanup covered malicious files, database spam, rogue administrators, scheduled tasks, compromised credentials, the vulnerable plugin path, WordPress file integrity, and preparation for a Google Safe Browsing review.
The likely entry point was an abandoned contact-form add-on with a known vulnerability. Weak access hygiene and unused administrator accounts increased the risk, while hidden files and a modified must-use plugin helped the infection persist.
Only if the backup was created before the infection and the original entry point was closed. An earlier restore had already brought one malicious file back, so the live site needed investigation and cleanup before a new restore point was created.
BugShield cleaned the site and prepared the evidence needed for a review request. Google reviews the request separately and controls when its browser and search warnings are removed.
A developer was assigned within one hour and the cleanup was completed the next day. Another infection may take more or less time depending on the number of sites, persistence methods, hosting access, and available logs.
The emergency malware cleanup was £99.99, confirmed before payment. A separate request receives its own confirmed price based on the site and the work required.
No. The agreed work covered the registered agency website. Other WordPress properties on the same hosting account were identified for separate review rather than accessed without permission or scope.
The vulnerable plugin path was removed, credentials and WordPress salts were rotated, unused administrators were disabled, persistence files were cleared, and ongoing malware monitoring was recommended.
Yes. Malicious code can appear in uploads, themes, must-use plugins, scheduled tasks, database options, server configuration files, and user accounts. That is why deleting one suspicious plugin is not a complete cleanup.
Yes. BugShield can investigate defacement, redirects, spam pages, rogue administrators, malicious files, database injections, and recurring infections. The cleanup plan is based on the evidence found on the registered site.
Describe the warning, redirect, or suspicious change and see the confirmed cleanup price before a developer begins.
Request malware removal