If index.php keeps returning after you replace it, the file is not the root cause. WordPress core files are easy to restore; a reinfection means another process, account or persistence mechanism still has permission to write the file again.
Prove when and how index.php changes
Start from a known-good core copy, record its hash and modification time, then watch for the next change. Correlate that timestamp with web requests, cron execution, plugin activity, deployments and server events. The writer matters more than the final malicious line.
Separate core corruption from active persistence
- Compare core files with the exact trusted WordPress release.
- Review recently modified PHP outside core, especially writable directories.
- Inspect scheduled tasks, MU plugins and active theme/plugin loaders.
- Check whether hosting-level automation or deployment is legitimately rewriting the file.
Look for the component that can write it back
Common persistence surfaces include a compromised plugin or theme, a hidden loader, a scheduled callback or a server-level process. If .htaccess is also being rewritten, use the repeated .htaccess diagnostic. If changes correlate with scheduled execution, compare malicious WordPress cron jobs.
Restore from a trusted baseline only after containment
- Preserve the infected file and relevant logs.
- Disable or isolate the confirmed writer.
- Reinstall affected core, plugin or theme code from trusted packages.
- Rotate credentials that could still provide write access.
- Recheck ownership and writable paths before returning to normal traffic.
Do not keep replacing index.php on a timer
That can hide the recurrence while the attacker-controlled writer remains active. It also destroys timestamps that help attribute the reinfection.
Recovery exit criteria
The incident is closed only when the core hash remains stable through normal traffic, cron and restart cycles, no unknown process rewrites the file, and the persistence mechanism that caused the reinfection has been removed.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Fresh timestamps and hashes separate real reinfection from cached output. Ownership and audit logs help identify web, SFTP or system-level writes.
- 1
Preserve each infected version, hash, timestamp and owner.
- 2
Monitor the file for the next write and correlate it with process and access logs.
- 3
Search cron, mu-plugins, uploads, auto-prepend configuration and sibling sites.
- 4
Audit hosting, SFTP and administrator credentials used near the write time.
What must be verified
- index.php remains identical through traffic, cron and restart.
- No unknown process or account can write to the web root.
- Sibling sites and server-level configuration are clean.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is it useful to just keep replacing index.php with a clean copy while investigating?+
No, this is explicitly discouraged. Repeatedly replacing the file while the site remains online and actively being written to just resets the symptom without closing the write path, so the file will likely be reinfected again before the actual cause is found.
Why would index.php specifically be the file that keeps getting reinfected?+
It's small and commonly monitored, which makes it a reliable execution point for attackers rather than a coincidence. Repeated modification of this particular file is itself evidence that cleanup missed a loader, a compromised credential, or a related infection elsewhere on the account.
Could a completely different website on the same server be the actual source of reinfection?+
Yes. When multiple sites share the same hosting account or system user, a compromised neighbouring application can write across directories and reinfect index.php on a site that is otherwise clean, which is why sibling sites need to be checked as part of the investigation.
What's the difference between a hidden loader and server-level persistence causing this?+
A hidden loader is another PHP file within the WordPress install that rewrites index.php on requests or via cron, whereas server-level persistence uses mechanisms like auto_prepend_file or scheduled system tasks that execute before WordPress even runs. Both need to be ruled out, since fixing only one while the other remains will still result in reinfection.