Security WordPress: control access and contain an incident

9 min read

WordPress security begins with a concrete question: who can modify your site and regain access? An editor can have rights adapted to the content while a former provider retains powerful access to hosting. Organize accounts, check their actual permissions, and prepare for incident containment before any cleanup.

Priority: nominative and limited access, controlled recovery and double authentication when the service supports it. In the event of an alert, preserve traces and block suspicious access before repairing. The register and the sheet below structure these decisions.

Identify all access and recovery paths

The WordPress documentation includes security of the hosting environment, not just the application.^[4] So start by mapping direct access and recovery paths.

Collect owners of accounts WordPress, hosting, file access, database, domain manager, and reset mail. Add technical accounts, integrations, and app passwords where they exist. For each, note the decision maker, the actual holder, and the means of recovery.

A contact address is not enough: check who actually controls the box and can contact the supplier. Changing a WordPress password does not constitute access control to the domain or hosting.

Designate a person authorized to request a block from the host, with a relay in case of absence. Keep these contact details off-site, in a protected space.

Set WordPress rights according to actual tasks

A role is a set of capabilities, or capabilities, that is to say permissions. Your work rule must remain the granting only of the capacities necessary for the tasks entrusted, in accordance with the WordPress documentation.^[5]

Distinguish between writing, publishing, modifying others' content and technical administration. The Editor role can publish and manage other users' articles, so it is not automatically suitable for an editor responsible for preparing their own content.^[5] If a custom role is needed, have its capabilities verified rather than copying a script found online.

Test with the account concerned: creation of a draft authorized, publication refused if it is not planned, access to extension management refused. A hidden menu does not replace this control of actions.

For validation, note the account tested, the task, the denial or permission observed, and the controller. Retest after a role modification or an extension that changes permissions.

Access to the site editor depends in particular on edit_theme_options, whose scope goes beyond this single interface.^[5] Do not add it to quickly resolve a writer's block.

Security WordPress: close forgotten access and test 2FA

Favor nominative accounts: each access must have an identifiable holder, without sharing an administrator account. When leaving, check WordPress, hosting, file access and integrations separately.

For sensitive access, look for double authentication actually supported by the service, a compatible extension or your identity provider. Do not assume it is native or active. Check its operation on the connection path actually used, then check the other access paths.

Prepare recovery before imposing it: authorized person, backup codes kept separately from identifiers, documented alternative method and test with an authorized account. These secrets do not go into the registry.

For each automated access, note the authentication method and the associated secret, without copying this secret. Have its suspension procedure and dependencies confirmed. Testing one connection path should not be used as proof for all others.

At the end of a contract, remove unnecessary access and revoke the affected sessions or tokens when the tool allows it. Change shared secrets; changing the master password alone does not prove complete revocation.

Inventory components and make logs usable

WordPress recommends keeping the core software as well as all installed themes and extensions up to date, and choosing components that are still receiving updates.^[4]

Inventory each component with its version, its origin, its use, its manager and its active or inactive state. Check dependencies before a checkout. Disabling is not a security validation. Prepare restorable backup and functional tests according to the site maintenance and backup control.

Then locate the logs actually available: connections, administration, hosting and messaging depending on the tools. The absence of an entry proves nothing if logging was not enabled or if the traces have expired.

Keep exports in a separate space with limited access, with their origin, timestamp and time zone. Keep the originals; work on copies. Set a retention appropriate to the investigation and data present, without publishing logs containing secrets or personal information.

A minimal access register filled in to decide

Fictitious example, without reference to a client of 4SYSTEM: Camille prepares articles; Julien, a former provider, retains access to accommodation. Léa is responsible for the site. The register distinguishes between decisions and expected evidence: it does not describe checks that have already been passed.

Add review date, expiry date for temporary access and proof reference. Use explicit statuses: requested, revoked, verified. A request does not constitute a confirmed revocation. Keep passwords, private keys and backup codes out of this table.

Containment: intervene in the right order

Treat an unknown administrator account, an unexpected redirection, an unexplained file modification, or an unusual sending from email as alerts. These signs call for verification; they do not alone prove the origin of the incident.

1. Resume a reliable channel. Contact the host using their known contact details and use a trusted position. Do not rely solely on messages posted by the suspicious site.
2. Preserve what is available. Export traces and view accounts, files and timeline before modifications. If the abuse continues, do not delay blocking: request parallel preservation from the host.
3. Contain access. Have the site isolated or restricted to the appropriate level. A maintenance page displayed by WordPress does not demonstrate that technical access is blocked.
4. Secure recovery. Control hosting, messaging and domain; revoke suspicious access and renew exposed secrets from a trusted environment.
5. Diagnose then repair. Work on a copy when possible. Don't randomly delete files or run unexamined scripts: you could destroy evidence or make the shutdown worse.

A containment sheet and proof of recovery

In the same fictional example, an unrecognized administrator appears. The presence of Julien in the register does not establish his responsibility. The following sheet is used to manage actions, not to declare the incident resolved.

• Signal: unknown account spotted in administration; origin not determined.
• Driver: Léa decides; the host takes care of technical isolation.
• Scope to check: WordPress, Julien's hosting access, recovery by email and domain.
• Evidence to keep: list of accounts, available exports, captures and timestamped timeline; protected off-site storage.
• Confinement decided: request isolation, remove residual access from Julien, control other privileged accounts.
• Repair authorized after diagnosis: process the identified entry, choose a verified restore or rebuild, and then renew the affected secrets.
• Validation expected: tests of essential functions, permissions authorized and denied, recovery and control of available traces.

A backup must be examined before restoration: its existence does not prove that it precedes the compromise. Document changes, testing and authorization for return to service. A normal display does not demonstrate eradication.

If the entry point remains unknown, do not present the rollback as a sufficient correction. Maintain the necessary restrictions and have possible access routes examined. The person authorizing the resumption must be aware of the remaining uncertainties.

If personal data appears to be exposed, transmit to the data controller the categories concerned, the suspicious period and the possible accesses to qualify the applicable notification obligations. The return of the site does not resolve this question.

Frequently asked questions

What to do if the domain is in the name of the service provider?

Do not attempt to bypass the holder's account. Gather the contract, available supporting documents and information from the registrar. Ask for the applicable procedure for reestablishing authorized management or arranging the transfer. Distinguish the ownership dispute from the technical emergency: the host can examine measures to protect the site independently of the transfer of the domain.

How to intervene if 2FA blocks you?

Use the recovery method provided by the service or request assistance from a verified channel. If an extension provides the second factor, have its fallback procedure identified before any technical modification. Avoid globally disabling protection for all users. After recovery, check the sessions and regenerate the emergency resources concerned.

Can a multisite administrator fix everything?

Not necessarily: administration capabilities differ between a single installation and a multisite network.^[5] Identify the blocked tasks and the authorized account at the network level. If the affected extension or configuration falls under this level, the local administrator should not be given additional rights by default. Address the intervention to the competent manager and document its scope.

Skip to useful controls

Start by identifying who controls hosting, domain and email, then remove access that is no longer needed with proof of revocation. Then have the editorial account and administrator recovery tested. If you need to clarify responsibilities or prepare a supervised intervention, consult the 4SYSTEM services to define the necessary perimeter.

Sources

• Security : Advanced Administration Handbook | Developer.WordPress.org (accessed 2026-10-08)
• Roles and Capabilities : Documentation : WordPress.org (accessed 2026-10-08)