auto_prepend_file / .user.ini Malware means a PHP configuration directive forces a malicious file to load before normal WordPress code on many or all requests. Treat the visible payload as evidence of a broader compromise until the entry point and persistence path are understood.
Symptoms
- Malware appears across many pages even after WordPress files are replaced.
- A hidden .user.ini, php.ini or hosting configuration contains auto_prepend_file.
- Requests execute an unfamiliar PHP file before wp-config.php or WordPress bootstrap.
- The infection survives theme/plugin cleanup and may affect multiple sites under one account.
Indicators of compromise
Indicators should be interpreted in context. Preserve enough evidence to distinguish a compromised origin from stale cache, a legitimate customization or a third-party service before deleting files.
How this threat persists
Persistence may live in a different layer from the symptom: a backdoor, scheduled task, MU plugin, database loader, compromised credential, shared-hosting account or remote script can recreate the visible malware after an incomplete cleanup.
Investigation
- Search for .user.ini/php.ini and hosting-level PHP directives above and inside the document root.
- Identify the prepended file and preserve a copy safely for analysis.
- Determine the filesystem/account scope where the directive applies.
- Review access logs and modified-file timelines to identify the entry point.
Recovery
- Remove the malicious auto_prepend_file directive and payload through the supported hosting configuration path.
- Check all affected sites/directories under the same account.
- Rotate credentials and patch the original vulnerability.
- Restore trusted application files and verify requests no longer include the loader.
- Monitor configuration and filesystem changes after recovery.
WP•FIX treats security incidents as root-cause investigations. Removing the visible payload is only one step; recovery also checks persistence, credentials, vulnerable components and the scope of access the attacker may have had.
Prevention after cleanup
Prevention depends on the confirmed entry point. Typical post-recovery work includes updating or replacing vulnerable components, rotating exposed credentials, removing unused privileged access, verifying clean backups, reducing unnecessary write/execute paths and monitoring the affected layer for recurrence.
FAQ
Is auto_prepend_file / .user.ini Malware always easy to detect?
No. Conditional behavior, remote loaders, cache variants and hidden persistence can make a compromised site appear normal to administrators.
Can I remove only the visible auto_prepend_file / .user.ini malware payload?
That may stop the immediate symptom, but reinfection is likely if the loader, backdoor or original entry point remains.
Should I restore a backup?
A known-clean backup can be useful, but it should be restored only after confirming its date and addressing the entry point; otherwise the site can be reinfected.
When should I request professional incident response?
If visitors are exposed, the site is blacklisted, privileged access may be compromised, malware returns, or the infection spans multiple layers/sites, a controlled incident-response workflow is safer than repeated file deletion.
Seeing signs of auto_prepend_file / .user.ini Malware?
Send the site URL and exact behavior you or visitors see. Do not send passwords in the first message.
Open a security incident