Book a demo
Book a demo
Login

App workflow WordPress

Inspect a WordPress vulnerability finding in xCloud

Open the finding details and record component, affected version, severity, and remediation. 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 vulnerability scan flags a plugin used by a live appointment site. The manager needs to determine whether the installed version is affected and choose a safe response.

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

Confirm the finding target

Where
xCloud WordPress → Vulnerability Scan
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Site ID, finding ID and scan timestamp
Action
Open the named site's finding and record component slug, installed version, severity, advisory and scan time.
Expected result
A finding tied to one deployed component.
Verify
Cross-check slug and installed version in WordPress Plugins.
If it fails
If the finding belongs to another site or stale version, rescan before response planning.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Vulnerability Checker in xCloud

Step 2 of 5

Check exposure and evidence

Where
Vendor advisory and plugin settings
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Affected version range and enabled feature
Action
Read the primary advisory and identify the vulnerable feature, required attacker access and whether that feature is active on this site.
Expected result
A reasoned exposure assessment.
Verify
Compare advisory version range with the exact installed version and feature configuration.
If it fails
If advisory details are insufficient, mark risk uncertain and escalate rather than invent exploitability.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Vulnerability Checker in xCloud

Step 3 of 5

Check remediation options

Where
Plugin changelog and staging
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Fixed version, replacement, disabling impact
Action
Inspect available fixed version, vendor status and compatibility. If no fix exists, test disabling or replacing the affected feature on staging.
Expected result
A selected mitigation with known effect on bookings.
Verify
Run a staging booking and cancellation after the proposed change.
If it fails
If mitigation breaks bookings, keep the finding open and select a controlled alternative.

Sources: Manage WordPress plugins · Create a staging environment in xCloud

Step 4 of 5

Apply approved mitigation

Where
xCloud WordPress updates or app admin
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Selected plugin slug, backup ID, change window
Action
After owner approval and completed backup, update only the selected plugin or adjust its feature in WordPress. Wait for any update job to finish.
Expected result
The affected component changes as planned.
Verify
Confirm installed version and booking behavior on production.
If it fails
If the update fails, stop, preserve logs and use the narrow rollback plan.

Sources: Manage WordPress plugins

Step 5 of 5

Verify and document residual risk

Where
xCloud Vulnerability Scan and incident record
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Rescan permission, advisory and test results
Action
Trigger an authorized rescan, check finding state, and document whether exposure is removed or only mitigated. Record follow-up date.
Expected result
A dated evidence trail and owner for remaining risk.
Verify
Match rescan result to the production installed version.
If it fails
If the finding persists, investigate version/report timing and do not mark it resolved.

Sources: Vulnerability Checker in xCloud · Vulnerability operations

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