WordPress Security Audit: Suspicious Accounts and File-Editing Plugins on Client Sites

How this started

This review started in October 2026, during our PHP2Shell patching project for several live and staging WordPress environments on different PHP branches and hosting setups, including managed hosting. The patching has its own case study, so this page covers the other question that work raised: what a patched server cannot tell you. While investigating, the review also turned up file editor and file manager plugins, and user accounts nobody could readily match to a known owner.

Why patching alone was not enough

A patched PHP runtime closes a known hole, but it says nothing about access someone may already have, such as a login created earlier or a plugin that lets a logged-in user edit files on the server. Patching closes the door. The security review checks whether anyone already walked through it, and what would make the next break-in worse.

How we investigated

1. Before looking closely at anything, we created recovery points where the hosting supported them and kept a dated record of the environment state. That gave every later comparison a fixed starting point.
2. We went through the visible WordPress user accounts and their roles, including who held the administrator (admin) role, the role with full control of a site, alongside the available security-related activity. Every account that can sign in is a way into the dashboard, so each one needs a known owner.
3. Accounts we could not readily match to a known owner went on the list as suspicious, with their ownership marked for verification. We did not label them malicious, because a missing owner is a warning sign, not proof.
4. We read the web-server and PHP error logs we could export, watching for odd requests and error patterns that deserved a closer look. We wrote the time window and sampling limits beside each result, so nobody could mistake a sample for a full history.
5. We recorded the file editor and file manager plugins as findings in their own right, because these dashboard tools let a logged-in user edit server files whether or not anyone has misused them yet.
6. We wrote up what we saw apart from what still needed proof: account ownership, file integrity checks (comparing site files against known-good copies), fuller log coverage, and host confirmation for unresolved runtimes. That way a suspicion never became a fact, and a gap in the evidence never became a clean result.
7. We updated the activity-logging plugin in the reviewed environment to support ongoing change tracking, then prepared concise follow-up actions.

What we did with the findings, and what we recommend

• Accounts, what we did: we listed ownership of the unrecognized accounts as a task needing further validation.
• Accounts, hardening guidance: record an unrecognized account before changing anything, confirm it with a named person, and remove or downgrade it if nobody can vouch for it. Then rotate passwords and the salts (the site's security keys; changing them logs everyone out) and turn on two-factor authentication (2FA), a second check at login, for every admin.
• Plugins and file access, what we did: we documented the file editor and file manager plugins as observed findings.
• Plugins and file access, WordPress hardening guidance: delete file manager plugins and use SFTP (a secure file transfer connection) or the host's file manager instead. Adding DISALLOW_FILE_EDIT to wp-config.php, the main WordPress settings file, removes the built-in editors. DISALLOW_FILE_MODS goes further and blocks installing, updating and deleting plugins and themes from the dashboard, so it only suits sites updated another way, such as WP-CLI (the WordPress command-line tool), the host or a deployment pipeline.
• Integrity and monitoring, what we did: recovery points and a dated record give a known starting point, and we updated the activity-logging plugin in the reviewed environment to support ongoing change tracking.
• Integrity and monitoring, what stays open: file integrity checks, fuller log coverage and host confirmation on unresolved runtimes stayed on the validation list instead of being assumed. As general guidance, WP-CLI can compare core files and WordPress.org plugins against the official originals.

The results

The website owners now have a written set of findings, a dated record of the environment state, recovery points where the hosting supported them, and concise follow-up actions for what is still open. We updated activity logging in the reviewed environment to support ongoing change tracking. No confirmed compromise appeared in the sampled evidence, and we reported it as exactly that: a limited sample, not a full forensic clearance or a blanket all-clear.

Reusable lesson

Do not let a patch stand in for an audit: confirm who holds each key to the site, and write down what the evidence cannot yet show.

How I would evaluate this today

Today we would give a similar site its own review of accounts, file access and logs, scoped and documented the same way. Nothing here discloses an incident, replaces a full WordPress incident investigation, or certifies that any site was free of compromise; we share it, anonymized, to show how the work was scoped.