A malicious `auto_prepend_file` can execute PHP before WordPress loads, so a clean plugin/theme scan may miss the persistence entirely. Inspect PHP configuration from the request’s directory hierarchy and runtime, not only `wp-config.php` or the WordPress file tree.
Confirm the effective runtime value
Use the affected PHP SAPI/pool to identify the effective `auto_prepend_file`, not just the value in one ini file. CLI and FPM can load different configuration. Record the loaded ini files from the affected request path so the comparison is explicit.
Walk the directory configuration chain
Inspect `.user.ini`, local php.ini directives, hosting-panel overrides and parent directories that apply to the document root. Record which file actually sets the value.
Preserve the referenced payload
Hash and copy the prepended file plus the configuration artefact that points to it. Removing the directive first can erase the easiest path to understanding persistence.
Check scope beyond one WordPress install
A parent-level directive can affect multiple sites under the same account. Test sibling document roots before declaring the incident isolated.
Remove the unauthorized configuration at its owner
Restore the expected PHP configuration and trusted file state. Avoid commenting one line while leaving an attacker-controlled parent config or panel setting active.
Restart/reload and verify the effective state
Account for `.user.ini` cache TTL or FPM reload behavior, then confirm the runtime no longer prepends the file and representative requests remain healthy.
Use recent-file evidence to establish timing and prove the reinfection route is closed after cleanup.