The first 15 minutes after confirming a WordPress compromise are about limiting new damage while preserving enough evidence to understand the access path. Do not start by deleting every suspicious file: isolate risky functions, record the current state and secure the accounts that can put the attacker straight back in.
Decide what must stop immediately
If checkout, account login, downloads or redirects could expose visitors, place the affected function behind maintenance or an edge rule while keeping an evidence copy. Do not destroy logs or timestamps as part of containment.
Record a small incident timeline
Write down first detection time, visible symptom, recent deploys, unknown admins, modified files and hosting/security alerts. A five-line timeline is enough to prevent later guesswork.
Secure control-plane access first
Rotate hosting-panel, registrar, email and privileged WordPress access from a known-clean device. WordPress-only password changes are insufficient if the recovery email or hosting account is compromised.
Preserve the current version before cleaning
Take a filesystem/database snapshot or provider backup and retain relevant web/authentication logs. The working copy can then be repaired without losing the original evidence.
Identify the likely blast radius
Check whether the incident is one site, one hosting account, multiple domains, email, DNS or ecommerce. Scope determines whether a simple restore is even trustworthy.
Define the next safe state
The first milestone is not “malware scan says clean”; it is controlled access, contained visitor risk, known backup/evidence and a plan for root-cause removal before reopening.
For access recovery, use safe hacked-admin recovery; then follow credential rotation after a compromise.