Hacked WordPress site cleaned and secured

The challenge

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. Business correspondence suddenly gave the impression of 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.

How BugShield approached it

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.

Technical findings

• An abandoned contact-form add-on with a known CVE was the likely initial entry point.

• The attackers hid their code by uploading PHP dropper files and modifying an mu-plugin to insert malicious content into the footer.

• 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.

What this prevented next time

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.

Why hacked WordPress sites bounce back

Malware often leaves persistence in places a homepage restore never touches: mu-plugins, uploads PHP, cron events, and database options. If the original plugin hole stays open, reinfection can happen overnight even after a cosmetic cleanup.

Emergency WordPress hacked site cleanup has to pair removal with hardening: update or replace the vulnerable plugin, rotate every privileged credential, and verify core integrity before you ask Google to clear a warning.

• File and database payloads, not just the homepage HTML

• Unused administrator accounts from past freelancers

• Outdated plugins with known public CVEs

• Backups taken after infection began

• Shared passwords across hosting and SaaS tools