Book a demo
Book a demo
Login

Operations WordPress

Respond to a WordPress site compromise report

Preserve evidence, scope impact, prioritize containment, and use verified recovery guidance. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A client reports an unknown WordPress administrator and suspicious redirect. The response owner must preserve evidence, control access and verify clean recovery.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Open incident and preserve evidence

Where
WordPress and xCloud logs; incident channel
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Report time, URL, user ID, owner
Action
Record symptoms, affected URLs, account names and timestamps. Preserve relevant logs and create an authorized current-state backup under restricted access before altering service.
Expected result
An evidence baseline before edits.
Verify
Have incident lead verify copies are readable and access-limited.
If it fails
If credentials are exposed, rotate from a trusted environment while retaining evidence.

Sources: Site backups in xCloud · xCloud agent capability boundaries · WordPress security hardening

Step 2 of 5

Limit ongoing exposure

Where
WordPress Users and incident channel
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Suspect account, transactions and credential owners
Action
With incident lead approval, revoke the suspect WordPress account and sessions and pause unsafe application transactions if needed. Arrange separate xCloud/network containment with the authorized host owner.
Expected result
Further harm limited while investigation continues.
Verify
Test a known legitimate admin path after containment.
If it fails
If containment blocks customers broadly, communicate and adjust with incident owner.

Sources: WordPress roles and capabilities · WordPress security hardening

Step 3 of 5

Investigate entry and scope

Where
WordPress users/files/plugins and security findings
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Known-good versions, change history, indicators
Action
Compare user roster, plugin/theme files and recent changes with known-good records. Read scanner findings and provider logs as one signal, without treating a scan as a forensic verdict.
Expected result
A scoped remediation plan.
Verify
Check redirect behavior from multiple clients and paths.
If it fails
If evidence suggests broader server compromise, involve qualified response support.

Sources: WordPress roles and capabilities · WordPress security hardening

Step 4 of 5

Remediate in isolation

Where
Staging or clean target; backup history
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Clean version, backup, newer data list
Action
Rebuild or repair affected components in an isolated environment, update credentials and test business integrations. Choose a backup only after confirming it predates compromise.
Expected result
A candidate clean service with reconciled data.
Verify
Run login, public page, form and transaction checks in isolation.
If it fails
If the backup may also be compromised, do not promote it; investigate alternate recovery.

Sources: Manage WordPress plugins · WordPress security hardening

Step 5 of 5

Return with monitoring

Where
Production cutover and incident record
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Approval, customer notice, follow-up scan
Action
After incident lead approval, restore service and monitor logs, new accounts and redirects. Record unresolved gaps and recheck after update cycles.
Expected result
A controlled return to service.
Verify
Confirm clean behavior from external browser and limited user.
If it fails
If suspicious behavior recurs, recontain and extend investigation.

Sources: WordPress roles and capabilities · WordPress security hardening

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized WordPress administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases