Suspected WordPress breach? Here's what you should do in the first hour

An unknown administrator account appears. The homepage redirects visitors to another website. Files have been changed outside working hours, or the security tool alerts you to suspicious activity. It is easy to act quickly, but in the wrong order.

The first hour should be used for three things: limiting further damage, preserving information about the incident and establishing control over access. The goal is not necessarily to get the website back online immediately. The goal is to restore it to a state you can trust.

This plan is designed for WordPress-based business websites. It should be adapted to your responsibilities, providers and technical setup before an incident occurs.

First: Clarify whether you actually have an incident

An anomaly is not always a breach. A redirect may be caused by a configuration error, and a new file may come from a legitimate update. At the same time, clear warning signs should be treated as a potential security incident until you know more.

Relevant warning signs include:

• Unknown administrator accounts or unexpected changes to user roles.
• Changes to content, themes or settings that no one recognizes.
• Redirects, new advertisements or unfamiliar content.
• Alerts about malicious files, unusual logins or altered code.
• Significant spikes in traffic, server load or outgoing email.
• Customers reporting warnings, fake forms or suspicious messages.

Record when the anomaly was first observed, who discovered it and what they saw. Take screenshots, but avoid clicking around more than necessary. Do not delete users, files or logs before someone has assessed whether they may be important to the investigation.

Minute 0–10: Assign responsibility and limit activity

Appoint one person to lead the incident. This person should keep track of decisions, timestamps and everyone involved. This reduces the risk of multiple people making conflicting changes at the same time.

Contact your hosting provider or technical partner early. They may have access to server logs, backups and measures that are not available in WordPress. Also clarify who can decide to take the website temporarily offline.

If the website is actively harming visitors, collecting information through a fake form or distributing unwanted content, traffic should be limited. This may mean enabling maintenance mode, blocking public access or isolating the affected environment. A short period without a website is often better than keeping a compromised solution open.

Do not use the suspected WordPress installation for internal communication about the incident. Use established channels outside the website.

Minute 10–20: Secure logs and take a snapshot

Before cleanup begins, you must preserve anything that could explain what happened. Ask your hosting provider to secure relevant logs and take a snapshot of the affected files and database. This is not a backup to be used for restoration, but documentation of the state at the time of the incident.

Also note which alerts you have received and which files, users or settings appear to have been changed. Timestamps are particularly useful when information from several systems is later compared.

Avoid relying blindly on the log from a single WordPress plugin. If the attacker has had extensive access, data within the installation may have been changed or deleted. Server logs, login logs and alerts from external monitoring systems can provide a broader picture.

Minute 20–35: Disable access in the right order

Changing passwords is important, but it must be done from a device you have reason to trust. If an administrator's computer or email account has been compromised, new passwords may also be captured.

Start with the accounts that control the rest of the environment:

1. Secure the email accounts used for recovery and administration.
2. Change access credentials for web hosting, servers, control panels and domain management.
3. Change passwords for WordPress administrators and terminate active sessions.
4. Change database passwords, deployment keys and other technical secrets as needed.
5. Revoke application passwords, integration keys and access you cannot verify.

Enable multifactor authentication wherever it is missing. At the same time, check that contact information and recovery methods have not been changed. A new password is of little use if an unauthorized person can still reset it or use an existing session.

Do not give all employees administrator privileges to help out. The incident should be handled by as few people as possible, using named accounts and documented tasks.

Minute 35–50: Determine the scope before restoring

Now you need to investigate more than the initial symptom. Removing a redirect does not mean the cause is gone. The attacker may have created additional users, inserted hidden code or gained access through another service.

The review should include at least:

• The WordPress core, active and inactive plugins, and themes.
• Administrator accounts, roles and recent logins.
• Scheduled tasks and unexpected configuration changes.
• Files that were recently created or modified.
• Integrations with forms, online stores, analytics, email and customer systems.
• Other websites or test environments on the same server account.

Look for known vulnerabilities in the components that were installed when the incident occurred. An available update may close the security hole, but it does not necessarily remove changes that have already been made. Therefore, simply «update everything» is not a complete cleanup.

If you cannot determine the scope, the installation should be treated as compromised. In that case, rebuilding from a known clean state is safer than repairing individual files based on suspicion.

Minute 50–60: Choose a safe path back

Before reopening the website, you must choose between cleaning it, restoring it or rebuilding it completely. The choice depends on how clear an overview you have, how extensive the changes are, and which backups are available.

A backup is only relevant if it is from before the compromise. It must be checked before use. An older backup may also contain the same vulnerable extension that opened the door in the first place.

A responsible restoration therefore involves more than pressing a restore button:

1. Build or restore in an isolated environment.
2. Check files, the database and users.
3. Remove components that are not necessary.
4. Update WordPress, themes and plugins from trusted installation packages.
5. Change relevant keys and login credentials.
6. Test forms, payments, login and other critical functions.
7. Reopen the website only once the responsible person has approved its condition.

After the first hour: Monitor whether the problem returns

A reopened website should be monitored more closely than usual. Watch for new administrators, failed logins, file changes, unexpected tasks, traffic patterns and outgoing email. Also verify that backups are working after the restoration.

Consider whether the incident may have affected personal data, customer data or payment information. This must be handled by the organisation’s data protection officer, management and any legal advisers. Do not wait until the technical cleanup is complete to make this assessment.

Communication should be precise. Distinguish between what you know, what you are investigating and the measures that have been implemented. Avoid categorical statements that «no data has been affected» until this has actually been established.

Prepare the plan before you need it

The greatest time savings come from preparation. Create a brief incident card with contact people, telephone numbers, suppliers, decision-making authority and the location of access credentials. The document must be available even if WordPress, email or an individual employee is not.

Also clarify in advance who can take the website offline, who can order technical assistance and who approves reopening. Test that necessary administrators have multi-factor authentication, and remove accounts that should no longer be used.

Finally, you should practise with a simple scenario. Ask the question: If an unknown administrator is discovered tomorrow morning, who does what during the next 60 minutes? If the answer depends on one person, an old password or a supplier no one knows how to contact, you have identified a security problem before it became a crisis.