Introduction

An unexpected PHP file on a server is often a sign of compromise, persistence, or an abandoned backdoor left behind after an earlier incident. Even if the file looks inactive, you should treat it as suspicious until proven otherwise. The goal is not just to delete the file. You need to preserve enough evidence to understand what happened, remove the unwanted code safely, and stop the attacker from putting it back.

Symptoms

  • You find a PHP file you did not deploy in a web-accessible or writable directory
  • The file has an obfuscated name, recent timestamp, or suspicious permissions
  • Security tools flag a shell, backdoor, or unknown script on the host
  • Other compromise indicators appear, such as changed admin accounts or redirects
  • The file returns unusual output, takes commands, or connects to external services

Common Causes

  • Attackers uploaded a web shell through a vulnerable plugin, form, or file manager
  • Stolen hosting or SFTP credentials were used to place the file directly
  • A previous cleanup removed visible malware but left persistence scripts behind
  • The application allows unsafe file uploads or writable execution paths
  • Another compromised site on the same host was used as an entry point

Step-by-Step Fix

  1. Preserve the file, timestamps, nearby logs, and related changes before removal so you can investigate the intrusion properly.
  2. Determine whether the file is reachable from the web, executed by scheduled tasks, or referenced by other compromised scripts.
  3. Put the site into a controlled cleanup state if needed so the attacker cannot keep using the file while you investigate.
  4. Remove the unauthorized PHP file only after you have captured what you need for rollback and incident review.
  5. Search for related indicators such as similar filenames, modified .htaccess rules, injected includes, rogue cron jobs, or new admin users.
  6. Patch the original access path, whether it was a vulnerable plugin, exposed credential, insecure upload path, or shared-host compromise.
  7. Rotate hosting, database, CMS, SFTP, and deployment credentials if they may have been exposed.
  8. Retest the site and monitor file integrity closely to confirm the file does not return after cleanup.
  9. Review upload and execution controls so writable directories cannot also serve arbitrary PHP execution going forward.