WordPress hacked after a developer handoff: the leftover file problem

Sometimes a WordPress site is not compromised through WordPress itself. It is compromised through something sitting next to WordPress: a leftover “temporary” tool that was useful during development and then quietly forgotten.

In this case, a single PHP helper file functioned as a full backdoor long after a developer handoff. Rotating WordPress passwords would not have solved the real problem.

The fix was disciplined, not clever: remove the spare key, rotate the right credentials, look for secondary access, and put a clean offboarding routine in place.

How it usually starts

A site changed hands. A migration and some troubleshooting needed quick server access. The site kept running. The owner did not arrive with a dramatic “we’ve been hacked” moment. They had quieter signals: occasional slowness, a couple of unfamiliar files in the file manager, and the line experienced owners learn not to ignore: “I swear we didn’t touch anything.”

Before changing anything, ask: did anyone have server access recently for legitimate reasons (developer, agency, contractor, migration, debugging)? Here the answer was yes, a few months earlier.

Why “helpful” tools become backdoors

Developers often use small practical tools under deadline pressure: file managers, uploaders, database viewers, search/replace scripts, mail testers, cache cleaners. Those tools are not malicious by default. Left on a production server, they become an access path that bypasses wp-admin entirely.

In the audit we found one PHP file in a place it did not belong. The name was boring. The behavior was a full file manager: browse directories, upload files, edit files on the server.

Someone could control the site without logging into WordPress. That is why this class of incident is so frustrating. You can rotate WordPress passwords all day. It will not matter if an attacker can still upload and modify PHP.

If someone can upload and edit files, they can:

• Drop a second backdoor that survives plugin updates and a shallow “cleanup”
• Inject malicious logic into theme or plugin files
• Add redirects or spam pages that only trigger sometimes
• Create hidden admin users later
• Reinfect the site after you think you fixed it

This is not “a WordPress core vulnerability” in the usual sense. It is unauthorized server access. Treat it like a lost key.

Remediating the leftover tool

1. Delete the tool and search for other leftovers from the same period. Helper scripts often arrive in clusters.
2. Rotate credentials with the assumption the environment was exposed: hosting panel, SFTP/SSH keys and users, WordPress admins, and database credentials when feasible.
3. Hunt secondary doors: oddly placed PHP files, small injections in existing files, unknown admins, must-use plugins. Continue with malware removal if anything looks planted.
4. Harden afterward: fewer people with server access, 2FA on admins, login security, and a security checklist so mystery files stand out.

After the file was gone and access was tightened, the quiet weirdness stopped. No magic trick. Just removing the spare key.

Emergency recovery is temporary (not a client “backdoor”)

Locked out of wp-admin but you still own the site (or are hired to recover it) and have FTP/SFTP access? Use a one-time recovery method, then delete the code immediately:

• Create a WordPress admin via FTP
• Emergency one-time URL hook (same rule: remove after one login)

Do not leave recovery hooks or file managers on client sites “for later.” Do not install permanent hidden admin creators as a support convenience. Attackers look for exactly that pattern. A forgotten recovery snippet is a backdoor with a nicer story.

Authorized emergency recovery: create access, log in, delete the code, rotate passwords, scan. Permanent client backdoors: never.

Quick checklist after any handoff

1. Handoff sweep: unknown PHP files, “temp” scripts, file managers, uploaders, one-off debug tools
2. Limit server access: remove old SFTP users, SSH keys, and hosting panel accounts you cannot name
3. Baseline: use a short checklist so leftovers are obvious (WordPress security checklist)

This is operational security: clean handoffs, tight access, and noticing changes early. WP Security Ninja helps you keep a clearer baseline inside WordPress (tests, scanning, events) so suspicious patterns are easier to catch after a cleanup. Pair that with offsite backups you have actually restored once.