The first response should reduce harm without erasing the information needed to understand access, scope and recovery. Deleting suspicious files immediately may remove only visible symptoms while destroying timestamps and leaving the attacker active.
Work from a written incident timeline and make reversible changes where possible.
Minute 0–5: confirm the business risk
Record who reported the incident, current time with timezone, affected URL and visible symptoms. Check whether checkout, account login, downloads or administrator access could expose customers.
Do not browse suspicious pages while logged into WordPress, hosting or email in the same browser profile. Use a clean device or isolated browser and avoid downloading unknown files.
If card data may be involved, follow the payment provider and organisation’s incident process immediately.
Minute 5–10: preserve a recoverable snapshot
Ask the host for a filesystem, database and relevant log snapshot before cleanup. Record server/site identifiers and backup timestamps. Keep the copy in protected storage with limited access.
Do not restore over the current site yet; that would remove evidence and may reintroduce a vulnerable version. Do not email the archive or place it in the public web directory.
Verify that the backup job finished and note whether logs rotate soon.
Minute 10–15: contain public harm
Choose the narrowest containment that protects visitors: disable checkout, place the affected site behind a controlled maintenance response, block a malicious route or suspend only the compromised account.
Use a static maintenance page served outside WordPress where practical. Avoid a plugin-based maintenance page when WordPress itself is untrusted.
Preserve access for authorised responders through hosting controls without publicly revealing origin addresses.
Minute 15–20: secure the control plane
From a clean device, rotate hosting/control-panel credentials, WordPress administrator accounts, deployment/SSH keys and database access that may be exposed. Protect the primary email account and enable multi-factor authentication.
Do not rotate every application secret blindly before recording dependencies; uncontrolled changes can destroy service and logs. Prioritise accounts that can modify files, database, DNS and backups.
Revoke unknown sessions and record each change in the timeline.
Minute 20–25: collect volatile evidence
Export or preserve web access/error logs, PHP logs, WordPress security events, mail queue, running/scheduled tasks and current administrator list. Record recently changed files without opening suspicious PHP in a browser.
Capture DNS, redirect and server configuration relevant to the symptom. Hash or otherwise identify collected archives so later copies can be compared.
Minimise customer data and use the organisation’s approved evidence location.
Minute 25–30: define the clean recovery path
List trusted WordPress core, plugin and theme sources; known-good backup dates; PHP version; custom code ownership; and external services. Decide whether recovery will rebuild clean components and import validated content rather than "cleaning in place."
Assign owners for containment, investigation, communications and business reconciliation. Record what must be verified before reopening.
Do not promise a reopening time before the infection vector and persistence are understood.
Avoid destructive first reactions
Do not delete all recently modified files, overwrite the database, run an unknown cleanup script or grant a third party unrestricted credentials. A compromised timestamp can be changed, and legitimate cache or update files can be recent.
Do not pay a ransom or contact an alleged attacker without the organisation’s authorised incident lead and legal guidance.
Keep customers informed through approved channels when service or data risk requires it.
Define the first verification gate
Containment is successful when public malicious behaviour stops, control accounts are protected and evidence is preserved. It is not proof the website is clean.
Recovery still requires identifying persistence, replacing untrusted code, checking database/users, closing the entry point, rotating secrets and testing the rebuilt site.
Request emergency WordPress rescue when checkout, administrator access, mail abuse or several sites are affected. Provide symptoms, timeline and host access through a managed channel—never post archives, passwords or customer data publicly.