What matters first: The root index.php is small and commonly monitored, so attackers use it as a reliable execution point. Repeated modification proves the cleanup missed a loader, credential or neighbouring compromise.
What this symptom actually tells you
Fresh timestamps and hashes separate real reinfection from cached output. Ownership and audit logs help identify web, SFTP or system-level writes.
Capture evidence before changing anything
- Preserve each infected version, hash, timestamp and owner.
- Monitor the file for the next write and correlate it with process and access logs.
- Search cron, mu-plugins, uploads, auto-prepend configuration and sibling sites.
- Audit hosting, SFTP and administrator credentials used near the write time.
Most common causes
- Hidden loader: Another PHP file rewrites index.php on requests or cron.
- Compromised credentials: An attacker continues uploading the file externally.
- Neighbouring site: A different application under the same user writes across directories.
- Server-level persistence: auto_prepend_file or scheduled system tasks execute before WordPress.
Safe diagnostic and repair sequence
- Replace index.php from the exact clean core package after preserving evidence.
- Remove the persistence mechanism and close the write path.
- Rotate all privileged credentials and invalidate sessions.
- Separate or clean every site sharing the account and monitor integrity.
How to choose between the likely causes
Do not treat Hidden loader and Compromised credentials as interchangeable. Another PHP file rewrites index.php on requests or cron. By contrast, an attacker continues uploading the file externally. Use two checks to separate them: Preserve each infected version, hash, timestamp and owner; and monitor the file for the next write and correlate it with process and access logs. Those observations usually show whether the next safe move is to replace index.php from the exact clean core package after preserving evidence or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not keep replacing index.php while the site remains online and actively changing. Preserve state and contain write access first.
How to verify the repair
- 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.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.