WordPress hacked or just under attack?

Unusual traffic, repeated login failures and security alerts do not all mean the same thing. Before deciding what to fix, it helps to establish what the evidence actually shows.

A blocked request is not a confirmed break-in

Public websites receive automated requests for login pages, configuration files and paths that may not exist. A log showing that a request was blocked tells you about that request. It does not, by itself, prove that someone gained access or that every part of the website is safe.

The useful questions are what was requested, how the server responded, whether activity is continuing and whether anything on the website has changed without your knowledge.

Symptoms worth investigating

• Administrator accounts or files that you do not recognise.
• Unexpected redirects, injected links or changes to page content.
• Login failures that persist despite a valid password.
• Files that reappear after deletion.
• A sudden rise in server load alongside unusual request patterns.

These symptoms need context. A broken login can also result from a plugin conflict or access rule. High resource usage can come from legitimate software as well as automated traffic.

Why another password reset may not help

In one support investigation, a password verified correctly at PHP level but WordPress still rejected it. A malicious plugin was found interfering with the authentication process. Resetting the password again would not have addressed that cause.

Another investigation involved an access rule targeting a WordPress update file. Correcting that rule did not remove every access restriction, so the remaining denial had to be traced through the hosting configuration.

Start with a record of the problem

Note when the issue started, record the exact error and preserve relevant logs. Establish what backups are available before making substantial changes. Avoid repeatedly deleting suspicious files without considering what might recreate them or losing evidence that could explain the incident.

If the website is actively harming visitors, containing that behaviour should be treated as a priority. The appropriate action depends on the compromise and the hosting access available.

Protection needs to fit the website

Traffic rules and security tools need to account for genuine visitors, administrators, search engines and integrations. A useful response targets the observed problem and checks that forms, checkout and editing still work afterwards.

Recovery is also more than a single clean scan. The follow-up may include reviewing accounts, compromised credentials, software, backups and any unresolved signs of persistence.