WordPress Malware Keeps Coming Back: Find the Cause

Establish what actually came back

Keep a before-and-after record of the suspicious file, database value, account or redirect. Include hashes where your investigator can collect them safely, the time it was detected and the action taken. A filename alone is insufficient: an attacker can change the name, and a legitimate deployment can recreate an expected file.

First separate a fresh malicious change from a stale cache, an old scanner report or a historical search snippet. Compare the live origin, public cached response and the actual affected content. Record the timezone used by each log. Conflicting timestamps can make a routine deployment look like reinfection or hide the sequence of an attack.

Use the recurrence timing to guide the investigation

These are working hypotheses, not diagnoses. More than one route can exist. Do not delay containment while trying to make every event fit one explanation, and avoid destroying logs simply because the first cleanup appeared to succeed.

Review code that ordinary plugin checks miss

Inventory the components that run before the affected page renders: normal plugins, must-use plugins, drop-ins, theme bootstrap code, custom snippets and relevant server configuration. Review stored application settings and scripts as well as files. A dashboard list of active plugins is not a full map of what the PHP process may execute.

WordPress publishes checksum-verification tools for core and supported plugin packages. They can help identify differences against publisher files, but their coverage must be understood. A clean core result does not validate custom code, uploads, database content or an account login. A premium or bespoke component may need comparison with its own authenticated release source.

Run investigation tooling from a trusted administrative environment. Avoid casually bootstrapping a known-compromised application just to produce a list. If examining a copy, keep it isolated and prevent it from contacting production integrations or handling normal customer traffic.

Close every relevant path that can write the malware back

• Review hosting users, SSH or SFTP access, CMS administrators, recovery email access and deployment credentials.
• Audit scheduled hosting jobs, external deployment services and backup/restore automations against a documented owner.
• Investigate neighbouring websites that share writable directories or a hosting account; a clean main domain may be recontaminated by another application.
• Replace affected components from verified sources and remove abandoned code rather than leaving it disabled but reachable.
• Review the identified initial access condition and its fix. An unknown cause must remain an open item, not be relabelled as a completed root-cause investigation.

If host-level control may have been lost, a fresh application directory on the same compromised server is not a trusted rebuild. Decide with the hosting provider whether the account, operating system or wider environment also needs replacement. Separate recovery credentials from old automation until that trust decision is made.

Restore in controlled stages and watch what changes

1. Establish a clean baseline from verified code and reviewed data, with file inventory and configuration recorded.
2. Enable the minimum features needed for one business journey and observe unexpected file writes, outbound connections and account changes.
3. Reintroduce necessary integrations one at a time, with their credentials replaced where exposed and their owners identified.
4. Exercise scheduled functions and background work deliberately, then compare the application with the recorded baseline.
5. Monitor public behaviour and relevant logs after reopening, with an agreed owner for investigating alerts and a documented escalation route.

Do not deliberately leave a vulnerable production component online to see whether an attacker returns. Observing a rebuild in a restricted test environment is different from allowing further public compromise. Keep customer data out of test copies unless there is a defined need and appropriate protection.

What an evidence-led recurrence report looks like

Hypothetical example: a business removes the same injected file three times. Each return appears just after a scheduled deployment. Comparing the deploy archive with the clean baseline reveals that an old, already infected build is being republished. The team repairs the build source, replaces its deployment credentials, investigates how that source was changed and retests the schedule. The file deletion was necessary, but the deployment chain was the recurring cause.

Ask a WordPress reinfection recovery provider for the sequence of events, tested hypotheses and outstanding gaps. A useful report says which code, accounts and automations were reviewed and how recurrence will be detected. It should not equate a quieter scanner dashboard with proof that the attacker never accessed customer data.

CyberXperts can help scope recurring website malware and distinguish application cleanup from a wider hosting or identity problem. An initial enquiry needs the symptoms and hosting context, not unrestricted credentials or a public link to a compromised backup.