When WordPress is compromised: An action plan for the first hour

Category: Cybersecurity

A strange administrator account, unknown redirects or altered files may indicate that the WordPress site has been compromised. In that situation, it is tempting to update everything, delete suspicious files and change a few passwords. Such measures may be appropriate later, but if carried out in the wrong order, they can destroy evidence, lock out responsible parties or allow the attacker to retain access.

The goal during the first hour is not necessarily to return the website to normal operation. The goal is to regain control: contain the incident, protect users and data, preserve relevant information and establish a secure starting point for remediation.

Determine who is leading the incident

Before anyone starts changing the website, one person should be given responsibility for coordinating the work. This may be an internal technical lead, the service provider or the web agency. That person should keep track of what is being done, by whom and when.

Create a simple incident log containing the following information:

• When the suspicion arose and who discovered it
• Which symptoms you have observed
• Which users, systems and integrations may be affected
• Which measures have been implemented
• Who made the decisions

Avoid discussing the incident in a channel that may be compromised. If an administrator’s email account may have been taken over, use another agreed channel for coordination and password sharing.

First phase: Confirm the symptom without making unnecessary changes

Start by documenting what you can actually see. Take screenshots of unknown users, error messages, changed settings and suspicious content. Note the time. Preserve relevant logs from the operating environment, WordPress, security tools and any protection services, if available.

Look for specific anomalies:

• New administrators or changed email addresses
• Unknown plugins, themes or scheduled tasks
• Redirects to other websites
• Changes to payment information, forms or tracking codes
• An unusually high number of logins or password attempts
• Files recently created or modified without a known reason
• Alerts from operations, browsers or search services

A single anomaly does not always prove a breach. An unknown file may belong to a legitimate update, and high traffic may be the result of a campaign. Documentation makes it possible to investigate without relying on assumptions.

Second phase: Contain the damage

If the website is spreading malware, redirecting visitors, displaying false payment details or exposing personal data, it should normally be taken offline or placed in a controlled maintenance mode. Do this at the infrastructure level if the WordPress administration cannot be trusted.

Do not delete the entire installation as the first step. First take a copy of the files, database, logs and relevant configuration. This copy should be treated as potentially harmful and stored separately from regular backups.

Also assess which connected services need to be isolated. WordPress may have access to email delivery, payments, customer data, analytics tools, cloud storage and financial systems. A compromised integration key may give the attacker further access, even after the website has been cleaned up.

Third phase: Secure authentication and active sessions

Changing passwords is important, but not sufficient. An attacker may already have an active logged-in session, a hidden administrator account or valid keys to other services.

Carry out the measures from a device you have reason to trust:

1. Change passwords for operations, WordPress administrators, the database, file access and relevant provider accounts.
2. Enable or verify multi-factor authentication on accounts with elevated privileges.
3. Terminate active sessions so that existing logins become invalid.
4. Rotate security keys and integration keys that may have been accessible.
5. Disable unknown users, but document them before removing them.
6. Check that recovery email addresses and phone numbers have not been changed.

Use unique passwords. If the same password has been used elsewhere, those accounts must also be treated as compromised. Prioritize accounts that can modify the website, create users, retrieve data or change billing.

Do not update indiscriminately in the middle of the investigation

Outdated components are a common entry point into WordPress, and updates will often be part of the solution. However, an immediate bulk update can overwrite files and make it more difficult to understand what happened.

First, preserve the necessary data. Then map the WordPress core, themes and plugins against known vulnerabilities and actual usage. Components that are no longer maintained should normally be replaced or removed. Deactivation alone is not always sufficient if the files remain accessible on the server.

Updates should be carried out in an isolated environment or as part of a controlled rebuild. Pay particular attention to login, forms, payments, search, integrations and editorial functions before reopening the site.

Choose between cleanup and rebuilding

It may be tempting to find a single malicious file, delete it and declare the website safe. The problem is that the attacker may have created multiple backdoors, modified the database or inserted code into an apparently legitimate plugin.

Rebuilding from known, clean components often provides better control than manual cleanup. This typically involves reinstalling WordPress, themes and plugins from approved original packages, checking customizations and importing verified content.

Manual cleanup may be necessary when the solution contains extensive custom development. In that case, all relevant files should be compared with their expected contents, and the database must be examined for unknown administrators, injected code, modified settings and scheduled tasks.

Use backups as a basis for recovery, not as a time machine

A backup is not automatically clean. The attacker may have had access long before the symptoms became visible. If you restore the latest copy without checking it, you may restore the backdoor at the same time.

Assess each available backup based on:

• When the first reliable signs of compromise appeared
• How long the vulnerability or account in question may have been exploited
• Whether the copy includes files, the database and the necessary configuration
• Whether the contents can be checked in an isolated environment
• Which legitimate changes will be lost through restoration

For online stores and websites with many forms, you must distinguish between application code and recent business data. An older, clean codebase can be combined with controlled order or form data, but this requires a planned migration. Do not overwrite new orders or enquiries without clarifying the consequences.

Check before reopening the website

Before normal operations resume, you should be able to answer three questions: What was the likely entry point? Has this entry point been closed? What signs would reveal that the attacker still has access?

Carry out at least the following checks:

• All administrators and service accounts are known and necessary
• Passwords, security keys and affected integration keys have been changed
• Active sessions have been terminated
• WordPress, themes and plugins have been checked and updated
• Unused components and accounts have been removed
• File areas have the correct write permissions
• Forms, payments and email work without unknown recipients
• Monitoring and logging have been enabled
• A new, controlled backup has been created

Monitor the site particularly closely after reopening. Look for new administrators, modified files, unusual logins, traffic anomalies and unexpected outbound requests. Monitoring must have a named recipient and an agreement on who will respond.

Assess whether the incident must be reported

If personal data may have been compromised, the organization must quickly assess its documentation and reporting obligations. This should be handled by the person responsible for privacy and management, not just by the technical provider.

Document what data the website stores, who may be affected, what the attacker may have accessed and which measures have been implemented. Do not wait for complete technical certainty before beginning the organizational assessment.

Turn the incident into an operational improvement

Once the situation is stable, you should conduct a brief review. It should not look for someone to blame, but for weaknesses in the system. Perhaps multi-factor authentication was missing, responsibility for updates was unclear, the backup was difficult to use or alerts were sent to an inbox that no one monitored.

Conclude with specific measures, an assigned person and a deadline. A simple incident response plan should be kept available outside WordPress and include contact details, shutdown procedures, the location of logs and backups, prioritized integrations and criteria for reopening.

The most important lesson is that incident response begins before the incident. Clear access management, rapid update procedures, tested recovery and monitoring with actual follow-up make the first hour far less chaotic.