A full backup can contain legitimate business data alongside vulnerable code, compromised accounts or persistence. Restoring it may recover availability without proving that the intrusion has been removed.
Build a clean application and import validated data in controlled stages.
Preserve the current incident state
Snapshot filesystem, database, logs, users, cron and mail activity before restoration. Record containment actions and the original document root.
Keep infected evidence non-executable and outside public storage. Do not overwrite it with the backup or use the only copy as a working directory.
Protect customer/order data and limit access.
Choose a candidate data point
Compare backup time with earliest credible compromise and recent business activity. Inventory software versions, administrators and known indicators within the archive.
An old backup can be useful for content comparison without being safe to boot. Record missing orders, users, forms and uploads that require reconciliation.
Do not equate "before symptoms" with clean.
Create a clean document root
Install WordPress core, maintained plugins and themes from verified sources. Apply supported PHP, least privilege and production configuration without copying unknown code.
Review custom plugins/themes line by line from a trusted repository or known-good version. Remove abandoned components and replace their functionality.
Keep the infected root isolated and read-only.
Recreate configuration and secrets
Build a new wp-config.php structure using current database access and fresh authentication keys. Rotate SMTP/API, payment, backup, deployment and webhook credentials exposed to the old environment.
Do not copy secrets from the compromised archive. Verify DNS/CDN/hosting accounts and enable MFA.
Document secret owners without storing values.
Validate database content
Import the database into isolation and inspect users/usermeta, options, cron, snippets, redirects, widgets, posts/templates and custom tables.
Remove only confirmed malicious records through precise changes. Avoid global replacement across serialized data. Where integrity is uncertain, import content/orders through supported application tools into a fresh schema.
Retain row backups and identifiers.
Validate uploads
Scan and inventory media, blocking executable PHP and unexpected server rules. Confirm each file type is needed and do not copy cache, backup or temporary directories as media.
Preserve customer uploads under access/retention controls. Rebuild thumbnails and generated assets from trusted sources.
Do not open unknown files on an ordinary workstation.
Review external configuration
Audit DNS/CDN redirects/workers, tag-manager containers, Search Console owners, SMTP provider, payment administrators and backup/deployment accounts. Malicious behaviour can survive outside WordPress.
Revoke unknown users/tokens and compare deployed versions with approved history. Keep public DNS unchanged until the clean environment passes tests.
Do not restore old API tokens simply because integrations need them; issue new least-privilege credentials.
Reconcile current business data
Compare WooCommerce orders/payments, stock, users and form entries after the selected backup. Use payment provider and authorised records as independent references.
Import recent validated data without overwriting clean security configuration or duplicating transactions. Assign one authoritative order state.
Document exceptions requiring manual customer contact.
Test in isolation
Verify login, roles, forms, checkout sandbox, webhooks, cron, mail, redirects, language/mobile and backups. Inspect rendered code and network destinations.
Run through recurrence triggers such as cron cycles, cache warm-up and administrator login. Confirm no original indicators or unknown accounts return.
Keep analytics/payment production actions disabled until approved.
Prepare a reversible cutover
Record current/new document roots, database endpoints, DNS TTL and cache layers. Define rollback that returns to safe maintenance—not the infected application.
Prevent both old and new sites from accepting writable checkout/forms simultaneously. Reconcile submissions during the final transition window.
Reopen with monitoring
Switch DNS/document root only after acceptance criteria and rollback are ready. Monitor file/database changes, privileged users, outbound mail and original indicators.
Retain the old root and evidence under policy, then remove them securely. Review the initial entry point and patch/process failure.
Request emergency rebuild help when database/uploads and recent orders need selective recovery. Share inventories and managed access—never public archives, secrets or customer databases.
A real three-file check and its limits
On 24 October 2026 at 23:07 UTC, we compared MD5 hashes from three core files on this editorial site with the WordPress.org checksum response for version 7.1.3, en_US. All three matched:
wp-login.php → matched
wp-includes/version.php → matched
wp-admin/admin.php → matched
Scope → 3 selected core filesThe hashes were collected with PHP and compared with the official response; we did not run WP-CLI, restore a backup or investigate an infected client site. This demonstrates one code-provenance check. It does not verify other core files, plugins, themes, database content, accounts, persistence or recent business records.
The official WP-CLI checksum command documents verification against a specified version and locale, before WordPress loads. In an environment with that tool, a responder can use the verified values:
wp core verify-checksums --version=VERIFIED_VERSION --locale=VERIFIED_LOCALEKeep the result with its actual scope. Ask the handover to identify which backup data was selected, how later records were reconciled, who verified account control and who authorised cutover. Matching code and a working homepage do not settle those decisions.
If access remains unresolved, follow authorised administrator recovery. To request a hacked WordPress restoration assessment, provide the backup date, latest business records to preserve, original symptom and known access restrictions. The hacked WordPress recovery service should agree reconstruction, continuity and acceptance as explicit parts of the scope.
Before the next incident, use the 2027 WordPress recovery plan and tabletop exercise to agree ownership, backup dependencies and reopening decisions without changing production.