The first 24 hours of a WordPress security incident determine how much evidence survives, how quickly damage is contained, and whether the same attacker returns. Random cleanup can make the site look better while destroying the information needed to find the entry point. Use a written sequence: confirm, preserve, contain, investigate, eradicate, recover, and monitor.
First 15 minutes: establish control
Record who discovered the problem, the exact time, affected URLs, screenshots, alerts, unusual accounts, redirects, browser warnings, and recent changes. Assign one incident lead and a private communication channel. Freeze routine deployments so normal work does not overwrite evidence.
For expert containment and investigation, contact our hacked WordPress recovery service before making irreversible cleanup changes.
Preserve evidence
Copy web server, PHP, authentication, firewall, CDN, hosting, database, deployment, and application logs. Capture suspicious files with timestamps and hashes. Record active users, scheduled tasks, plugins, themes, administrator accounts, file changes, and external connections. Store evidence outside the affected hosting account with restricted access.
Contain without losing visibility
Restrict administrative access, isolate affected services, block confirmed malicious sources, and temporarily disable risky functions. For an e-commerce or lead site, decide whether to place checkout or forms into a controlled maintenance state. Do not announce full recovery before payment destinations, forms, emails, and integrations are verified.
Our WordPress backup and recovery guide explains how recovery objectives and isolated restore testing support safer containment.
Scope the incident
Identify the earliest reliable indicator, affected accounts, altered files, database changes, injected scripts, new administrators, modified DNS, payment settings, API keys, emails, and connected services. Compare the site with trusted source code and known-good backups. A visible malware file may be only one part of persistence.
Use a complete WordPress security audit checklist to examine users, code, hosting, configuration, integrations, and evidence of compromise.
Eradicate the cause and persistence
Replace compromised core and vendor code from verified sources, remove malicious files and database records, patch vulnerable components, close exposed accounts, and correct permissions. Rotate WordPress, hosting, database, SFTP, email, registrar, CDN, repository, deployment, and API credentials according to the incident scope.
Review our guide to rogue WordPress administrator accounts so hidden or unauthorized privileged access is not left behind.
Recover using explicit criteria
Restore or rebuild in an isolated environment, verify integrity, update every supported component, test critical user journeys, scan externally, and confirm logs reach a protected destination. Reopen only when the entry point is addressed, persistence checks are clean, credentials are rotated, backups work, and monitoring is active.
Our documented WordPress security recovery case study shows how investigation, cleanup, hardening, and verification fit together.
Communicate carefully
Maintain a factual incident timeline and decision log. Notify hosting, payment, insurance, legal, privacy, or law-enforcement contacts when appropriate. Avoid unsupported statements about what data was or was not accessed. Customer communication should be accurate, timely, useful, and consistent with professional legal advice.
Monitor after reopening
Increase monitoring for authentication, file changes, database changes, outbound connections, scheduled tasks, DNS, payment settings, and vulnerable components. Track the indicators from the incident and review new anomalies daily until confidence is restored.
Ongoing WordPress maintenance helps convert incident lessons into tested updates, backups, monitoring, and accountable follow-through.
Run a lessons-learned review
Document the root cause, contributing conditions, detection gap, containment decisions, recovery time, evidence gaps, business impact, and corrective owners. Update the response plan and practice it. The goal is not only a clean site; it is a system that detects and contains the next problem faster.
Frequently Asked Questions
What is the first step after discovering a WordPress hack?
Preserve evidence and establish control. Record the time and symptoms, save relevant logs, restrict access, assign an incident lead, and avoid making untracked changes.
Should I restore a backup immediately?
Not automatically. A backup may contain the same compromise, and an immediate restore can destroy evidence. Identify the likely intrusion window and validate the restore point first.
How long does WordPress incident response take?
It depends on site size, access to logs and backups, malware persistence, integrations, and business impact. Reopening should be based on verified recovery criteria, not a fixed clock.
Do I need to notify customers after a website incident?
Notification depends on the data involved, contractual duties, applicable law, and jurisdiction. Preserve facts and involve qualified legal or privacy advisers promptly when personal data may be affected.
