Unknown WordPress administrator: verify the account’s origin and secure access

An unfamiliar account calls for verification, then a decision

You discover an administrator whose name you do not recognise in WordPress. This finding deserves prompt verification: the account may have substantial powers. It could, however, belong to an authorised service provider, come from a migration, or relate to a forgotten intervention. Its name alone does not establish that the site has been hacked.

The aim is to find out who authorised this access, limit opportunities for unauthorised activity, and retain the information needed for an investigation. Deleting the account immediately may remove useful information and affect the content assigned to it.

Start by notifying the known owner or technical manager. If harmful changes are underway, ask the host to contain the incident at the same time: searching for explanations must not allow an attack to continue.

Confirm the site, account, and available access

Open the administration area through your usual address, entered directly or stored in a trusted bookmark. Check the domain: production and staging may have the same title. Do not follow a link in a suspicious email to perform this check.

With an account authorised to manage users, open Users, then All Users; menu wording may vary. Filter administrators, then return to the full list if necessary. Compare the login username, display name, and role: these details are not interchangeable.

Record the WordPress version and authentication tools in use. The screens described mainly concern a self-hosted site. WordPress.com and multisite have particular features detailed below. If your account cannot access the list, send the finding to the person responsible; do not borrow their password or try to promote yourself.

Create a private record before making changes

For each affected account, record the site, username, observed role, and discovery time with the time zone. Where the numeric identifier is available in the account editing address, retain it too. It helps track the same record despite a change in display name.

Keep a dated screenshot of the profile and useful information in a private folder accessible only to those handling the case. Record the email address when needed for identification, without trying to collect every user’s personal data.

Separate facts from assumptions: “account seen this morning” does not mean “account created this morning”. Record known recent interventions and every action taken afterwards. Do not publish account lists, personal addresses, or complete logs on a forum. Cookies, tokens, and passwords do not belong in this record.

Preserve the current state and older backups

In the hosting panel, or through authenticated support, request a copy of the files and database before risky operations. Have available logs preserved before rotation, meaning their automatic replacement. A screenshot of the account list does not replace this preservation.

Label the new copy as an observed state that may be compromised. It is for analysis and retaining recent data; it must not be presented as a clean backup. Protect its location and ask who can access it. Have a copy kept outside the public directory and, if possible, beyond the potentially compromised access. Retain the original exported files and work on copies for analysis; record who made the export and when.

Keep older backups separately. Do not restore the entire database to make a user disappear: recent orders, registrations, and content could be lost. Analyse an older copy in an isolated environment with a separate database, protected access, and real payments, emails, and integrations disabled.

Choose between three paths

The first path applies when the owner identifies the account and finds an authorised intervention. It involves documenting its task and adjusting the privileges actually needed. A recognised identity does not remove the need to investigate unusual activity.

The second applies when the origin remains uncertain and no damage has been observed. It combines verification through known contacts, examination of existing traces, and an appropriate temporary restriction agreed with the person responsible. Define who must respond and when to reassess; do not leave the uncertainty without follow-up.

The third takes priority if the owner rejects this access, unauthorised changes appear, or the host reports an intrusion. Have the site handled as an incident, with containment and investigation. These paths address different levels of evidence; they are not three procedures to apply consecutively to every account.

Path 1: confirm a legitimate intervention

Prerequisites: you have recorded the exact username, site, and role in a private file. Use the owner’s or provider’s known contact details; the unfamiliar account’s address cannot be your only proof of identity.

1. Contact the owner, agency, or host through the channel already present in your usual records. Ask for the username used, task, intervention period, and person who authorised the access. Do not send a password or token to obtain the answer.
2. Compare the response with a ticket, maintenance request, or migration that actually took place. A name such as “support” proves nothing, and a general invoice does not confirm authorisation for this specific account.
3. If the task is confirmed, record its responsible person, scope, and end date in the access register. The expected result is a verifiable justification; next examine whether the role is still needed, as described in the following section.
4. If the provider does not recognise the account or the evidence conflicts, move to examining traces or incident handling. Even a recognised account may have been used by a third party: do not dismiss unexplained activity solely because its holder is known.
5. This verification path does not change the account. You can stop it without restoration; retain the responses and uncertainties. Any restoration of privileges already restricted must await an explicit decision from the person responsible, not merely a reassuring message.

Adjust a recognised account without deleting its content

For legitimate access that has become too broad, an authorised administrator opens the account from All Users, records the current role, and selects the role agreed with the owner. They save only this change. Avoid bulk selections: different people may have different tasks.

Choose privileges according to the remaining work, not convenience. Someone responsible for reviewing posts does not necessarily need to administer users or plugins. If roles have been customised, have the maintainer confirm their capabilities.

Then have the intended action checked using the person’s own account, without sharing their credentials. If the chosen role is unsuitable, correct the assignment after agreement. Returning to the previous role requires justification; it must not become an automatic promotion to make an access denial disappear.

Path 2: investigate the origin using available traces

Prerequisites: preserve existing logs and agree on a responsible person and a reassessment deadline. The aim is to match retained events with known interventions; a log installed after discovery cannot reconstruct the past.

1. Consult maintenance tickets, retained notifications, and logs already available. Search for the account identifier and ask the person responsible to compare its creation or promotion with authorised operations. Record the period actually covered by each log.
2. Check what columns mean before comparing dates. Registration is neither the last login nor necessarily a promotion to administrator. Some fields come from a plugin or the host: have what they record confirmed.
3. Record matching events and gaps without treating a network address as certain proof of identity. Missing traces may result from short retention or an event that was not logged. The expected result is a supported origin or explicitly documented uncertainty.
4. If the origin remains unknown at the agreed deadline, have a decision made on the temporary restriction described next and an assisted review. If a harmful action appears, move immediately to containment. This examination deletes nothing: keep original exports and work on copies rather than clearing logs to start again.

Temporarily reduce privileges without deleting the account

Prerequisites: on a straightforward self-hosted site, another trusted administrator must retain access, and the person responsible must approve the measure after preservation. Record the previous role. Restricting a role is not a complete account lock.

1. From All Users, open the targeted profile and check the username, not only the display name. Make sure you are not changing your only trusted access. If the account is a super administrator or belongs to a network, involve its manager first.
2. Where the option exists, select “No role for this site”, then save only this change. Reopen the profile to confirm the value and record the time. Keep the account and its content: deleting them is not a way to bypass an unavailable setting.
3. Have the maintainer check capabilities assigned directly to the account and external connections. Removing the role removes rights linked to that role but may leave individual capabilities; it does not necessarily prevent authentication. The Subscriber role also retains access.
4. If the option is missing, the value changes back by itself, or network rights are outside your scope, stop this procedure and have the host or network manager handle the case. Then move to sessions and application access, which require their own checks.
5. The expected result is a saved restriction with a known scope, not a guarantee that every intrusion has stopped. The previous role may be reassigned only after the origin is clarified and agreement is documented; never automatically restore suspicious access to undo a reported inconvenience.

Close the correct user’s sessions

Prerequisites: retain useful traces and use an administrator authorised to edit the targeted account. A session is the access held by a browser already logged in; closing it does not change the secret that allows a later login.

1. Open the targeted account’s profile and recheck its username. In Sessions, look for “Log Out Everywhere” when offered for that user. Do not use your own profile thinking it acts on every administrator.
2. After validating the target, use the button and retain the displayed result with the time. On your own profile, “Log Out Everywhere Else” closes your other sessions while keeping the current one: that has a different scope.
3. If the button is absent, disabled, or fails, record the exact observation and have the maintainer check sessions. The button’s state does not prove the absence of application passwords, external access, or any other login method.
4. Ask for confirmation of the targeted revocation, then continue handling the relevant secrets and integrations. The expected result concerns that account’s sessions, not all access to the site; a new login must also be prevented when access is unauthorised.
5. A revoked session cannot be reactivated with an Undo button. For a user ultimately recognised and authorised, returning to use requires a new login with secure means, after agreement. Do not copy a cookie or reuse a suspicious secret to restore the old session.

Examine application access separately

Application passwords let tools communicate with WordPress without using the main password. In the account profile, consult their section where available. Keep useful names and metadata before revoking the relevant access; do not create a new secret to test them.

These forms of access must be examined separately from browser sessions. Last-used information is not a complete history: updates may be spaced apart. A reassuring name is not proof of authorisation.

Revocation may interrupt a legitimate mobile app or synchronisation. Notify its owner. After securing the site, only recognised tools should receive suitable new access. Do not reuse a suspicious secret to undo the intervention or try to read secrets stored in the database.

Path 3: contain unauthorised access with the host

Prerequisites: the owner rejects the access or harmful actions have been observed. Use the host’s customer account and known contacts. If the incident is continuing, request containment without waiting for every origin investigation to finish.

1. Open a private ticket or the host’s emergency channel from your trusted access. Provide the domain, affected username, time with time zone, and observed facts. Distinguish changes seen from assumptions and mention evidence already preserved.
2. Request an appropriate restriction: limiting administration, isolating the installation, or another provider measure. Specify the functions to protect and observed damage. A store serving a fraudulent page has different constraints from a site with no visible change.
3. Have the scope across shared services confirmed before implementation. Do not shut down a server hosting other sites yourself. Also ask which copies and logs are being kept to analyse the cause after containment.
4. Obtain the time, the scope actually blocked, and the next expected check. A visible maintenance page does not prove that administrative or technical access is closed. The aim is to reduce possible actions during analysis, not to declare the site clean.
5. Define reopening conditions and legitimate functions to check with the person responsible. Do not remove a restriction simply because the page looks normal. Lifting containment must be coordinated after the agreed checks; it is not the automatic undoing of a presentation setting.

Protect trusted access in a coordinated order

Work with the owner from a device considered trustworthy. Have access to the recovery mailbox, hosting, and services capable of modifying the site examined. A new WordPress value entered from a compromised device or in an environment still controlled by a third party may be exposed again.

On a self-hosted site, change your legitimate account’s password in Profile, in the account management section, then save the profile. Use a unique secret and keep recovery means in a private location. Enable the two-factor authentication provided by the service or the tool already chosen, along with its recovery codes.

For the unauthorised account, coordinate blocking, sessions, recovery, and integrations with the maintainer. Simply sending a reset link to its address does not remove its control. Do not arbitrarily replace its contact details to turn the account into your new main account.

Adapt the intervention to multisite

In multisite, several sites share an installation and accounts. Check the site selected in My Sites, then involve the network manager. A user absent from one site may still exist in the network or belong to another site.

A local administrator does not necessarily have permission to edit the profile concerned. A super administrator has a broader scope: removing a role on one site must not be presented as removing their network powers.

Native sessions and application passwords are attached to the shared account: revoking them may also cut off access to other sites in the network. The action is therefore not necessarily limited to the displayed site. Ask the manager to check memberships, network status, and the scope of technical access before any global restriction. They must protect the other sites and document expected consequences. If nobody recognises the super administrator, the host and network owner must handle the problem together; do not improvise changes to shared tables.

Adapt the checks to WordPress.com

On WordPress.com, select the site, then open Users, All Users, depending on the interface style. Distinguish a team member from a pending invitation. An invitation sent but not accepted does not have the same status as access already used. Have who requested it confirmed. On sites allowing a separate local login, a pending WordPress.com invitation does not prove that the local account is unusable. Have the intended login method checked without disabling WordPress.com login as a test.

The external collaborator label does not, on its own, reduce permissions. An administrator is not necessarily the owner of the site, domain, or subscription either. For a restriction or recovery you cannot perform, go through the recognised owner and WordPress.com support. If a separate WP Admin password exists, changing it does not change the WordPress.com account password: have both affected access methods handled without confusing them.

Consult Jetpack, then Activity Log, where that screen is available. Visible history depends on the plan and retention; an absent event does not close the investigation. For your own WordPress.com account, also check Security, Connected Applications: examine the scope of connections and disconnect unauthorised ones. Any connection restored later must be explicitly approved.

Check containment and preserve legitimate functions

Reopen the user list from your trusted access. Verify the saved role and revocation confirmations obtained. Have new traces after the intervention time checked. If an unfamiliar administrator appears again or regains privileges, report the recurrence to the provider instead of repeating a loop of deletions.

Also check affected legitimate functions: planned publishing, identified synchronisation, and access for authorised people. Reserve tests that write data or send messages for a neutralised copy or controlled test mode. A real payment is not a necessary security check.

Do not try logging in with a suspicious secret to check whether it is blocked. Request targeted technical validation. A normal-looking site, a downgraded account, or a satisfactory scanner result does not guarantee the absence of other access. The observation period and additional checks depend on the actual incident.

Provide an actionable case and organise the next steps

In the private ticket, state the domain, your authorisation to intervene, discovery time, account concerned, and observed changes. Add checks made with providers, measures taken with their times, and the presence of preserved backups. Ask about the limits of available logs and the next expected action.

If customer or user data appears exposed, inform the person responsible for its protection in your organisation so they can have the situation assessed. Do not publish that data to demonstrate the incident. The investigation must also establish how access was obtained; this guide is not a complete cleanup procedure.

For the future, maintain an administrator register with the responsible person, task, and review date. Separate personal accounts from provider interventions. Reassess privileges when tasks end and check backups regularly. Any permanent account removal must await a documented decision about its content and preservation of evidence.

Inventory administrators from an analysis copy

When the interface cannot be trusted, a responder can supplement the inventory with WP-CLI. Be careful: WP-CLI loads WordPress code; running a command on a compromised installation may execute malicious components. Reserve this read operation for an isolated analysis copy prepared by the incident manager after preserving original material. This is not an invitation to execute unknown code on your personal computer.

With trusted runtime files and the analysis database confirmed, explicitly select the path and site:

The command removes no access. Its result provides candidates to compare with authorised accounts and available traces. user_registered is the account registration date, not its last login or the time it received its role; that value may also have been changed. An old user may have been promoted recently.

This filter is not a complete inventory of all sensitive capabilities or multisite super administrators. Have those scopes examined separately. Keep the result in the incident’s private file. This read operation has no rollback; suspending suspicious access remains a separate decision, with evidence preservation and verification of legitimate administrator access.

wp --path='/chemin/analyse' --url='https://analyse.example.test' user list --role=administrator --fields=ID,user_login,user_registered --format=table