Requirements and responsibilities
Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: A scanner flags a plugin installed on a client site.
xCloud agent capability boundaries · WordPress roles and capabilities
Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.
xCloud agent capability boundaries · WordPress plugin administration
Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: Scanning alone neither patches nor proves compromise.
Illustrative situation
Illustrative scenario, not a customer case study: A scanner flags a plugin installed on a client site. The actual installed version and vendor fix path are documented.
Choose the approach
Separate affected-version evidence from generic security severity labels. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · WordPress roles and capabilities · Vulnerability Checker in xCloud
Keep application setup, domain/DNS ownership, mail delivery and external integrations with their named administrators. Use a plain documented path when a proposed integration cannot be demonstrated end to end.
xCloud agent capability boundaries · WordPress plugin administration
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Identify site, plugin slug, version and finding source
- Where
- xCloud Vulnerability Checker findings
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Identify site, plugin slug, version and finding source; exact site identity, named approver and controlled sample data.
- Action
- Read the xCloud finding for exact site, plugin slug, installed version and advisory identifier. Do not label an entire site compromised from a version finding.
- Expected result
- The affected component and range are recorded.
- Verify
- The affected component and range are recorded. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If site/version mismatch exists, investigate scanner freshness before action.
Sources: Vulnerability Checker in xCloud · xCloud agent capability boundaries · WordPress plugin administration
Step 2 of 5
Check vendor advisory and available fixed version
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Check vendor advisory and available fixed version; exact site identity, named approver and controlled sample data.
- Action
- Read vendor advisory and changelog for fixed release, compatibility, support and whether the plugin is still needed.
- Expected result
- A concrete remediation candidate is identified.
- Verify
- A concrete remediation candidate is identified. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If no fix exists, consider disable/removal or temporary mitigation with owner.
Sources: WordPress roles and capabilities · Vulnerability Checker in xCloud · WordPress plugin administration
Step 3 of 5
Decide urgency with exposure and compatibility owner
- Where
- Business owner acceptance sheet and selected application records
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Decide urgency with exposure and compatibility owner; exact site identity, named approver and controlled sample data.
- Action
- Assess exposure from the plugin's actual use and available alternatives with business owner; record urgency and maintenance window.
- Expected result
- The triage decision has a reason.
- Verify
- The triage decision has a reason. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If risk cannot be assessed from current evidence, escalate rather than silently dismiss it.
Sources: WordPress roles and capabilities · xCloud agent capability boundaries · Vulnerability Checker in xCloud · WordPress plugin administration
Step 4 of 5
Propose a remediation and test sheet
- Where
- Business owner acceptance sheet and selected application records
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Back up and test selected remediation in staging; exact site identity, named approver and controlled sample data.
- Action
- Prepare a selected update/disable proposal and staging test sheet, including backup and customer journey, without changing production in this triage guide.
- Expected result
- An operator has a safe change plan.
- Verify
- An operator has a safe change plan. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If backup or test environment is unavailable, mark remediation blocked.
Sources: WordPress roles and capabilities · xCloud agent capability boundaries · Vulnerability Checker in xCloud · WordPress plugin administration
Step 5 of 5
Record residual risk and owner
- Where
- Business owner acceptance sheet and selected application records
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Apply and record residual risk if no fix exists; exact site identity, named approver and controlled sample data.
- Action
- Record decision, remaining exposure and review deadline in the issue ledger; hand the approved change to a separate update procedure.
- Expected result
- The finding is assigned and not falsely closed.
- Verify
- The finding is assigned and not falsely closed. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If no owner accepts the risk, keep the ticket open and escalate.
Sources: WordPress roles and capabilities · xCloud agent capability boundaries · Vulnerability Checker in xCloud · WordPress plugin administration
Maintenance
Assign a cadence for selected WordPress core, theme and plugin updates, review version-based findings and retest the path in this guide. In particular, repeat: The actual installed version and vendor fix path are documented. A chat prompt is not a scheduled task.
Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud
Record actual backup completion, storage access and responsible staff. Recheck connected application and provider behavior after changes rather than relying on a site health status alone.
Recovery decisions
This triage guide makes no production change. Preserve the finding and a safe remediation proposal; an authorized operator can later back up, test and update the selected component, with its own recovery decision.
AI handoff
Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.
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
- Inspect WordPress vulnerability findings mcp · read
Discover the connected read schema first. Version-based findings are not proof of compromise or a complete safety assessment; rescan is a separate write.
Checkpoint: Record site, component, installed version, finding and observation time.
Vulnerability Checker in xCloud · xCloud agent capability boundaries
- Review a WordPress business journey app · manual
Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence.
Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision.
- Business owner review and acceptance app · manual
Human planning, acceptance and record reconciliation cannot be inferred from xCloud resource reads. The business owner chooses the application's source of truth.
Checkpoint: Record approved criteria, observed application evidence, unresolved questions and named follow-up.
WordPress roles and capabilities · xCloud agent capability boundaries
Copyable agent brief
Manual checkpoints
- The named site, business or provider owner supplies application evidence the connected hosting reads cannot observe.
- A separately approved operator performs any later configuration, staging, update, restore or publication described in the decision sheet.
- The owner accepts the review finding and proposed checks without treating the unexecuted change as completed.
Feature coverage
- business-acceptance (covered): The actual installed version and vendor fix path are documented. Propose a remediation and test sheet
- recovery (covered): Scanning alone neither patches nor proves compromise. Record residual risk and owner