WORD SECURITY
SERVICESMalware RemovalHacked Site RecoverySecurity HardeningOngoing Security RESOURCESWordPress Security GuidesHacked Site Recovery GuideSecurity ChecklistEmergency Checklist COMPANY PricingAboutContact REQUEST MALWARE CLEANUP
GUIDE

Why Restoring a Backup May Not Fix a Hacked WordPress Site

By Word SecurityUpdated

Restoring last week's backup feels like the obvious fix. It's sometimes useful. It also frequently brings the problem straight back, because a restore returns the site to a state that was already vulnerable, and may already have been infected.

Four ways a restore fails

  1. The backup already contains the infection. Attackers often get in well before the symptoms show. If the backup postdates the compromise, restoring it reinstates the backdoor.
  2. The vulnerability is still there. A backup restores the old plugin versions too. The same automated scan that found the site before will find it again.
  3. The credentials are still valid. A restore doesn't change passwords, keys or hosting access that the attacker already has.
  4. Not everything is in the backup. The infection may also sit elsewhere in the account, on other sites sharing it, or at server level.

When a restore does help

  • You can show the backup predates the compromise, from logs, file dates and the first symptoms.
  • You restore it as a starting point and then update, rotate credentials and close the entry point.
  • You compare it with the infected copy to see what changed, which helps find how the attacker got in.

How to use a backup safely

  1. Keep the infected copy. Take a full copy of the current site first. It's evidence.
  2. Pick the backup deliberately. Work out when the compromise began, then choose one from before.
  3. Restore to a staging location if you can, and inspect it with the WordPress Malware Cleanup Checklist before it goes live.
  4. Update everything immediately after the restore, before the site is public.
  5. Rotate credentials and salts.
  6. Check for data gaps. Orders, form entries and posts made after the backup date are lost unless you merge them separately.

Backups are also an attack surface

Backup archives stored inside the web root can be downloaded by anyone who guesses the file name, and backup plugins have had vulnerabilities of their own. Keep backups outside the web root or off the server entirely, and don't leave old archives lying around.

Verify the backups you rely on

A backup nobody has restored is a hope, not a backup. Test a restore on a schedule. Checking backups is part of ongoing WordPress security. If you're in the middle of an incident, see What to Do Immediately After Discovering a WordPress Hack and WordPress Malware Keeps Coming Back: Why Reinfections Happen. The The Complete WordPress Hacked Site Recovery Guide puts backups in context.

Further reading

Dealing with this on a live site?

Send us the details and we'll tell you what we'd do and what it would cost.

Request Malware Cleanup

Related services

SERVICEWordPress Malware RemovalFind the infection, remove it, review access and close the way in. From $199.SERVICEOngoing WordPress SecurityUpdate oversight, security checks and backup verification from $79/mo.

Related guides

GUIDEWordPress Malware Keeps Coming Back: Why Reinfections HappenThe usual reasons a site is clean for a week and infected again.GUIDEWhat to Do Immediately After Discovering a WordPress HackThe first-day decisions: contain, notify, preserve and communicate.GUIDEWordPress Malware Cleanup ChecklistA technical checklist for files, database, users, tasks and verification.GUIDEThe Complete WordPress Hacked Site Recovery GuideThe full lifecycle: detect, contain, clean, validate, recover and prevent reinfection.