WP-CLI is useful when the dashboard is unavailable, but it executes WordPress code by default. On a compromised installation, bootstrapping malicious plugins or themes can run attacker-controlled PHP with the command user’s permissions.
Use it from authorised shell access, with snapshots and an explicit purpose.
Confirm path and operating-system user
Run commands from the correct document root and as the site owner, not as an unrestricted server account. Verify the canonical URL, wp-config.php, database and table prefix.
On servers with several sites, a misplaced --path can change another installation. Record the working directory and command output in the incident timeline.
Do not place credentials directly in shell history.
Preserve evidence before mutation
Take filesystem/database snapshots and copy relevant access, PHP, mail and audit logs. Record current users, plugins, themes and scheduled events before updates or deletions.
WP-CLI output is useful evidence, but do not dump full options, users or orders into a shared ticket. Redact identifiers and personal data.
Use read commands first.
Reduce WordPress bootstrap risk
Where supported and appropriate, use --skip-plugins and --skip-themes to avoid loading suspect extension code. Understand that must-use plugins still load unless specifically handled.
For example:
wp --skip-plugins --skip-themes core version
wp --skip-plugins --skip-themes user list --fields=ID,user_login,rolesThese flags reduce exposure; they do not prove the environment is safe.
Verify core integrity
Use the matching official release metadata to check WordPress core:
wp core verify-checksums --include-rootReview failures individually. Custom root files, host tooling and version mismatch can produce findings that are not malware.
Core checksums do not inspect uploads, custom themes, database injections or stolen accounts.
Inventory plugins and themes
List installed component names, status and versions without activating anything. Compare maintained packages with trusted vendor sources and check whether abandoned code remains on disk.
Checksum support varies, especially for commercial and custom extensions. Replace untrusted packages from verified downloads rather than editing suspicious lines in place.
Record licences/owners without exposing keys.
Inspect users and scheduled tasks
List administrators, roles, application-password metadata where available, and cron events. Preserve unknown IDs and hook names before disabling them.
Do not delete all cron entries; WooCommerce and backups rely on legitimate schedules. An unknown hook needs source analysis.
Use exact user IDs for any approved reset and revoke sessions afterwards.
Export narrowly and avoid loading payloads
Use WP-CLI database export only when the command user and destination are trusted. Place exports outside the web root, restrict permissions and remove working copies under the incident retention plan.
Commands that evaluate arbitrary option values, invoke plugin callbacks or run eval can execute compromised code. Prefer structured read commands and offline inspection.
Do not pipe unknown database content into a shell or upload it to public analysis services.
Check multisite and remote execution
Specify the intended site URL on multisite and record whether a command applies network-wide. A user or plugin action on the wrong site can alter shared tables.
Avoid running recovery commands through an opaque remote-management service until its account, token and audit logs are trusted. Revoke old management credentials after the incident.
Keep command history free of secrets and customer data.
Avoid unsafe search-and-replace
Database search-and-replace is appropriate for planned migrations, not as a generic malware cleaner. Obfuscated payloads, serialized values and legitimate content can be damaged.
Export the database, identify exact malicious records and use precise, reviewable changes. Never run a broad replacement on the only copy.
Keep infected data isolated from production.
Know when not to use WP-CLI
Do not bootstrap the site when file ownership is unknown, PHP execution itself is under investigation or the shell account may be compromised. Use offline analysis and a clean rebuild instead.
After recovery, test the site through normal HTTP, login, forms, checkout, cron and mail; CLI success is not user-path proof.
Request emergency technical recovery when WP-CLI output changes unexpectedly or several sites share the user. Share commands and redacted results—never private keys, database exports or malware samples publicly.