Cloudways PHP Update Skill for Patching Your Fleet with Hermes

A critical PHP flaw can move from advisory to attempted exploitation within days. Keeping up with every incident by hand gets hard when you manage a whole fleet of servers. This guide shows how a Cloudways managed Hermes agent can watch for new PHP vulnerabilities and check your servers through the Cloudways MCP, then prepare each fix while you keep the final approval.

Use this material as a template only. The skill and prompts in this article are examples, not an official Cloudways or DigitalOcean product, and they come AS IS without warranties of any kind, express or implied. A skill that can change production servers carries real risk. Review it, test it on a non-production environment, and decide whether the risks are acceptable before you use it. The full disclaimer appears at the end of the article.

Prerequisites

To set up the fleet monitoring skill, have the following on hand : 

• A Cloudways account with at least one server that hosts PHP applications
• A Cloudways managed Hermes agent 
• A Cloudways access token for the Cloudways MCP
• A non-production server or test app to practice on
• A channel where the agent can send you alerts and approval requests
• The skill file, which this guide describes in detail
• Optional API keys for NIST NVD and WPScan, which raise the lookup limits the skill works within

The Recent PHP Vulnerabilities

Two critical PHP flaws disclosed on October 21, 2026 put any unpatched PHP site that serves web requests at risk. They are tracked as CVE-2026-109618 and CVE-2026-109619. The researchers call the pair php2shell. The Canadian Centre for Cyber Security alert AL26-026 says successful exploitation could let an unauthenticated attacker run arbitrary code.

The alert lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as affected. It rates mod_php as the greatest risk, because a demonstrated exploit triggers the flaw before application code runs.

PHP branch	Affected versions	Fixed version
8.5	Before 8.5.12	8.5.12
8.4	Before 8.4.27	8.4.27
8.3	Before 8.3.36	8.3.36
8.2	Before 8.2.35	8.2.35

Versions 8.1 and older no longer receive updates from the PHP project, although some vendors provide backported fixes. Each fix is a patch release inside its branch. A server on 8.3.35, for example, needs 8.3.36 and does not need a jump to 8.4.

On October 23, the PHP Security Team published another remote code execution flaw, CVE-2026-115560, that the October 21 releases do not address. Exploiting it needs an uncommon mix of PHP configuration and application behavior. Until an update ships, PHP recommends keeping the session upload progress feature off with session.upload_progress.enabled=0.

A Cloudways PHP update therefore has two jobs. The first is applying the fixed version once it is available on your server. The second is watching for the next advisory, which never stops.

Why a Monthly Maintenance Window Is Too Slow 

Many teams evaluate and apply server patches on a monthly cycle. PHP flaws now move faster than that. The php2shell fixes shipped on October 21, proof-of-concept code was already circulating, and a follow-up flaw arrived two days later.

Fleets add a second problem. An agency can run dozens of servers hosting many WordPress sites, and nobody can read every advisory feed every day.

Applications sharing a server raise the stakes. A rushed update can break sites that were never at risk, which is why the skill checks every sibling app before it proposes anything.

A manual process leaves gaps while users catch up on advisories, and a fully automatic one can cause its own outages. A supervised agent closes both gaps. It watches and checks around the clock and leaves the decision to you.

SANS called the php2shell episode a dress rehearsal for more flaws of similar severity and urged teams to keep their inventories current. Continuous monitoring keeps that inventory current.

Cloudways Managed AI Agents and the Cloudways MCP

You can connect your Cloudways managed agents to your servers and applications through the Cloudways MCP. It exposes your account’s servers, apps, backups, and monitoring data as tools the agent can call, and every connection uses an access token with a scope you choose. Managed AI Agents deploys open-source agents such as Hermes and OpenClaw from the same Cloudways dashboard you already use for hosting. 

For the purpose of this article, we are using an Hermes agent hosted on Cloudways Managed Agents platform.However, you can substitute a Cloudways managed OpenClaw instance without any significant changes.   

Meet the Cloudways Vulnerability Guardian skill

The skill turns a Hermes agent into a patch assistant that finds Critical vulnerabilities and checks whether a fix is safe for your fleet, then waits for your exact approval before it changes anything. It is named cloudways-vulnerability-guardian and covers PHP runtimes and WordPress workloads on Cloudways servers.

—

name: cloudways-vulnerability-guardian

description: Scans Cloudways multi-tenant servers and WordPress workloads for Critical vulnerabilities, verifies patch feasibility, enforces pre-update backups on affected applications, and applies remediations with human confirmation.

version: 1.0

author: Cloudways Managed Agents Team

tags: [cloudways, wordpress, php, cve, patching, devops]

prerequisites:

  mcp_servers:

    – name: cloudways

      url: https://mcp.cloudways.com/mcp/

      transport: http

      headers:

        X-Access-Token: “${CLOUDWAYS_ACCESS_TOKEN}”

        X-Mcp-Host: “hermes-agent”

      required_tools:

        – get_servers

        – get_server_settings

        – get_applications

        – get_app_settings

        – update_server_package

        – take_app_backup

        – restore_app_backup

        – get_operation_status

  environment_variables:

    – CLOUDWAYS_ACCESS_TOKEN: Scoped token from https://unified.cloudways.com/api (requires Server, Server Management, Application, and Service categories)

    – NIST_NVD_API_KEY: Optional (raises NVD rate ceiling to 50 requests per 30 seconds)

    – WPSCAN_API_KEY: Optional (required for WPScan API quota)

  notification_channels:

    – email: Default operational address configured in agent profile

    – slack: Active channel webhook / bot integration

    – telegram: Configured bot chat ID

    – whatsapp: Connected gateway / business API endpoint

—

Automated vulnerability surveillance, runtime compatibility validation, and supervised patch management for Cloudways-hosted PHP runtimes and WordPress applications.

 

1. Prerequisites & Validation Constraints

Before executing tasks, verify the environment and active tool configurations:

• Authentication Validation: Ensure the Cloudways MCP tools listed in the prerequisites are available to the agent. If the MCP was connected through the Cloudways panel, the panel stores the token and CLOUDWAYS_ACCESS_TOKEN will not be set in the environment, so do not ask the user to paste a token into the conversation. If a tool call fails because of scope, report the missing scope to the user and stop. If the tools are unavailable, tell the user to connect the Cloudways MCP in the panel.
• Tool Discovery: Cloudways MCP exposes a default set of tools directly and loads the rest through its toolset discovery meta tools. If a required tool is not listed directly, discover it through those meta tools, read its schema, and use the exact parameter names it returns. 
• Strict Integer Type Enforcement: Cloudways endpoints return HTTP 422 Unprocessable Entity if string values are supplied for entity identifiers. The skill must explicitly typecast all server_id and app_id values to native integers before issuing API calls.
• Transport Plane: The hosted HTTP MCP server at https://mcp.cloudways.com/mcp/ is the sole interface for any change to servers or applications. Read-only HTTP GET requests are also permitted for advisory feed ingestion and for application health checks. The skill operates without SSH or command-line shell access .
• Omnichannel Broadcast Protocol: Every alert, approval manifest, blocked status report, and rollback warning generated by the agent must be dispatched synchronously across all connected channels (Email, Slack, Telegram, and WhatsApp). If the user has configured channel preferences or routing rules in the agent profile, those rules take precedence over this default and the agent must follow them. 

2. Threat Intelligence Ingestion & Throttling Rules

Monitor only Critical severity advisories, defined in this skill as a CVSS base score of 8.0 or higher, along with actively exploited vulnerabilities tracked in CISA KEV. Adhere to source-specific throttling limits to prevent rate-limit blocks:

[SOURCE 1: NIST National Vulnerability Database (NVD)]

• Target Scope: Official CVE records, core PHP runtimes, and standard library components.
• Rate-Limit & Backoff Strategy:
  • If NIST_NVD_API_KEY is not provided: Hard throttle requests to a maximum of 1 query every 6.5 seconds (under the public 5 requests per 30-second window).
  • If NIST_NVD_API_KEY is active: Throttle to 1 query every 0.8 seconds (under the 50 requests per 30-second window).
  • On HTTP 403 or 429: Pause execution for 30 seconds before retrying once.

[SOURCE 2: GitHub Advisory Database (GHSA)]

• Target Scope: Packagist and Composer packages, PHP language runtimes, and upstream library dependencies.
• Rate-Limit & Backoff Strategy:
  • Interface via GraphQL API consuming standard GitHub token points.
  • On receiving an HTTP 429 (rate limit reached) or secondary rate limit response: Implement exponential backoff starting at 10 seconds, doubling per retry up to 80 seconds (10s, 20s, 40s, then 80s).

[SOURCE 3: WPScan Vulnerability Database]

• Target Scope: WordPress Core software, official and third-party plugins, and active themes.
• Rate-Limit & Backoff Strategy:
  • Track cumulative daily calls within the agent session. On free-tier plans, strictly cap outbound lookups at 6 requests per calendar day.
  • Enforce a mandatory 2.0-second pause between subsequent API queries.
  • Once quota exhaustion (HTTP 429 with quota message) is reached, fall back to checking local/cached advisory manifests.

[SOURCE 4: Patchstack Security Feed]

• Target Scope: High-velocity WordPress vulnerability disclosures, zero-days, and security patches.
• Rate-Limit & Backoff Strategy:
  • Cache fetched global feed payloads locally for a minimum of 15 minutes before refreshing.
  • Parse and strictly adhere to Retry-After headers if returned. If no explicit delay is provided, apply a 5-second backoff on throttled responses.

[SOURCE 5: CISA Known Exploited Vulnerabilities (KEV) Catalog]

• Target Scope: Confirmed in-the-wild exploited CVEs requiring immediate prioritization regardless of standard disclosure timing.
• Rate-Limit & Backoff Strategy:
  • Ingest the remote known_exploited_vulnerabilities.json dataset once per scan cycle.
  • Cache the JSON file locally for 6 hours; do not issue per-vulnerability outbound requests.
  • Filter locally against vendor criteria (cpe:2.3:a:wordpress:wordpress and cpe:2.3:a:php:php).

3. Dynamic Inventory & Multi-Tenant Compatibility

Never rely on stale or cached version state files. Always poll live Cloudways runtimes during the active scan cycle.

[STEP 1: Server and Application Discovery]

• Server Enumeration:
  Call cloudways.get_servers() to retrieve all active servers. Extract each numeric server_id.
• Runtime Query:
  For each discovered server, call cloudways.get_server_settings(server_id=int(server_id)).
  • Extract and record php_version (the currently running engine, e.g., “8.1”).
  • Call cloudways.packages_list to retrieve installable package versions, and record the PHP versions installable on that server as available_php_versions. Do not assume the server settings response contains this list .
• Application Topology Mapping:
  Call cloudways.get_applications(server_id=int(server_id)) to list all tenant apps hosted on that server.
  • Record app_id, app_label, primary domain, and app_version (WordPress core release in the case of WordPress applications).
  • Query cloudways.get_app_settings(app_id=int(app_id)) for application-level parameters.
• Discovery Boundary Rule: During inventory discovery, the agent operates in pure read-only mode and must not execute any operation that mutates, flushes, or modifies files or database rows.

[STEP 2: Multi-Tenant Blast Radius Assessment]

• Scope Isolation:
  Because changing a server’s PHP package affects the shared execution environment for every application on that server_id, server-level patches must never be evaluated against a single vulnerable application in isolation.
• Tenant Compatibility Matrix:
  Change Classification: Classify every proposed change before running the compatibility check. A patch update keeps the server in its current PHP branch (for example, 8.3.35 to 8.3.36). A branch upgrade moves the server to a different branch (for example, PHP 8.1 to PHP 8.2). Patch updates still run the sibling check as a confirmation step. Branch upgrades require the full matrix below. When a Critical CVE demands a branch upgrade:
  • Loop through all co-located sibling applications identified on that server_id.
  • Cross-reference the required target PHP runtime against each application’s recorded core version and declared component dependencies.
  • Verify minimum and maximum supported PHP constraints across every asset manifest.
• Hard Failure & Protection Gate:
  • If any sibling application on that server runs legacy code or an unverified component incompatible with the target PHP release, immediately block the automatic upgrade proposal.
  • Classify the issue as BLOCKED_BY_MULTI_TENANT_INCOMPATIBILITY.
  • Generate an asset conflict report showing the exact blocking component and its host application, dispatch this report to all connected communication channels (Email, Slack, Telegram, WhatsApp), and terminate the remediation pipeline for that server.

4. Remediation Workflow & Decision Gates

[BLOCK 1: Target Feasibility Evaluation]

• Trigger: A Critical CVE (CVSS 8.0 or higher, or indexed in CISA KEV) matches an asset in the active inventory.
  • Execution: The agent queries cloudways.get_server_settings(server_id=int(server_id)) for PHP engine availability.
• Branch Condition:
  • Condition Met: If the required fixed version is installable on the server and passes sibling compatibility checks, proceed to [BLOCK 2]. Record the exact version string returned by get_server_settings. If the settings response lists only branch-level versions (for example, “8.3”) and the agent cannot confirm that the installable package includes the fixed patch release, treat the condition as unmet and divert to [BLOCK 3] with a note that the patch level could not be verified.
  • Condition Unmet: If the target version is not listed in Cloudways supported packages, divert immediately to [BLOCK 3].

[BLOCK 2: Hard Token-Based Approval Gate]

• Trigger: Feasibility check passed; target version is installable on the target server.
• Hard Constraint: Absolute execution freeze. The agent is strictly prohibited from inferring consent from generic user phrases such as “proceed”, “fix it”, “yes”, “okay”, or “update everything”.
• Omnichannel Notification: Broadcast the complete approval manifest across Email, Slack, Telegram, and WhatsApp:
  1. Threat Context: CVE ID, CVSS score, vulnerability summary, and exploitation status.
     • Target Scope: Affected server_id, specific vulnerable target_app_id, and primary domain.
  2. Version Migration: Current runtime version to target patched version.
  3. Tenant Verification: Signed confirmation that all sibling applications sharing the server are verified compatible.
     • Snapshot Reference: Target name for the pre-execution backup of the affected application: cve-patch-{CVE_ID}-{APP_LABEL}-{YYYYMMDD_HHMMSS}.
     • Required Exact Token: The agent must display:
       To authorize this change, reply with the exact confirmation string:
       CONFIRM_UPDATE_SERVER_{SERVER_ID}_TO_VERSION_{TARGET_VERSION}
• Requirement: Block all execution until the user submits the exact confirmation token. If any other input is received, remain idle.

[BLOCK 3: Terminal Advisory & Standby]

• Trigger: Remediation requires an upstream version that Cloudways has not yet packaged into platform repositories, or affects application-level code (plugins/themes) outside server package scope.
• Constraint: No state mutation permitted. Do not attempt unofficial repository additions or direct file mutations.
• Omnichannel Broadcast: Dispatch a high-priority advisory to Email, Slack, Telegram, and WhatsApp containing:
  1. Advisory Alert: State that a Critical vulnerability exists, but Cloudways repositories currently support up to version {MAX_SUPPORTED_VERSION} (or that the issue requires application-level dashboard action).
  2. Status Statement: Confirm that zero modifications were applied and the server remains untouched.
  3. Mitigation Recommendation: Advise the user to contact Cloudways support regarding package availability, update components via the WordPress admin panel, or apply edge firewall filtering.
• State: Enter indefinite standby on this vulnerability until the user issues new instructions.

[BLOCK 4: Supervised Execution & Recovery Pipeline]

• Step 4A (Target Application Snapshot Phase): Call cloudways.take_app_backup(app_id=int(target_app_id)) strictly for the affected application. Sibling applications are not backed up. Capture operation_id and poll cloudways.get_operation_status() until the backup confirms complete.
• Step 4B (Server Package Phase): Execute runtime update strictly via cloudways.update_server_package(server_id=int(server_id), package_name=”php”, version=target_version). Do not send any other parameters. Poll operation completion until status reports complete.
• Step 4C (Health Check): Perform HTTP status verification across all sibling applications on that server. If any application returns an HTTP status 500 (or similar server level alert), immediately halt, notify all channels, and present the rollback prompt referencing the target application backup created in Step 4A.

5. Execution Protocol & Rollback Safeguards

Once the exact confirmation token is submitted:

[PHASE 1: Pre-Patch Target Application Backup]

• Target Application Snapshot Isolation:
  The agent must call cloudways.take_app_backup(app_id=int(target_app_id)) strictly for the affected application identified in the vulnerability alert. Sibling applications that are not the direct target of the advisory are not backed up.
• Standardized Snapshot Naming:
  Enforce explicit naming for rollback tracking:
  cve-patch-{CVE_ID}-{APP_LABEL}-{YYYYMMDD_HHMMSS}
• Asynchronous Completion Loop:
  Capture the returned operation_id. Poll cloudways.get_operation_status(operation_id=int(operation_id)) every 5 seconds up to a maximum of 120 attempts (10 minutes).
  • If status: 2 (Completed): Proceed to Phase 2.
  • If timeout is reached or the backup fails: Abort the remediation pipeline immediately and notify all connected channels. Do not modify packages.

[PHASE 2: Remediation Deployment & Parameter Lockdown]

• Parameter Lockdown Rule: The agent must pass only server_id, package_name=”php”, and version=target_version to cloudways.update_server_package. The agent is strictly forbidden from altering or sending modifications to max_execution_time, memory_limit, opcache, or any other runtime directives unless explicitly instructed by a secondary user command.
• Execute Update:
  Call cloudways.update_server_package(server_id=int(server_id), package_name=”php”, version=target_version).
  Capture the returned operation_id and poll cloudways.get_operation_status() until completed.

[PHASE 3: Post-Patch Health Verification & Rollback Protocol]

• Multi-Tenant Health Checks:
  Dispatch HTTP GET requests to the primary URL of every co-hosted application on that server.
• Success Condition:
  If all applications return HTTP 200 OK:
  1. Log the patch as successful.
  2. Record the snapshot reference ID in the audit log.
  3. Broadcast a success confirmation across Email, Slack, Telegram, and WhatsApp.
  4. Return the agent to standby.
• Failure Condition & Immediate Rollback:
  If any application returns an HTTP error code (500 Internal Server Error, 502 Bad Gateway, or 503 Service Unavailable):
  1. Alert the user immediately across all channels (Email, Slack, Telegram, WhatsApp) with exact HTTP response codes, failing endpoints, and server error details.
  2. Present an emergency prompt to restore the affected application:
     cloudways.restore_app_backup(app_id=int(target_app_id), backup_id=rollback_ref)
  3. Require explicit secondary confirmation before triggering the restore operation. The agent must display the following: To authorize this restore, reply with the exact confirmation string: CONFIRM_RESTORE_APP_{APP_ID} Block all restore execution until that exact string is received. If any other input is received, remain idle 

6. Guardrails & Grounding Rules

Ground the agent’s autonomous behavior in production infrastructure realities using the following mandatory operational constraints:

[GUARDRAIL 1: Asynchronous State Validation]

• Zero-Assumption Principle: Cloudways mutates infrastructure via background asynchronous workers. An initial HTTP 200 response from an API invocation indicates only that a job has been queued, not that it has succeeded.
• Enforcement: The agent must never treat an operation (such as take_app_backup, update_server_package, or restore_app_backup) as complete until it extracts the operation_id, polls cloudways.get_operation_status(operation_id=int(operation_id)), and verifies that the return state has transitioned from status: 1 (In Progress) to status: 2 (Completed).

[GUARDRAIL 2: Zero Unsolicited State Mutations & Exact Token Enforcement]

• Human-in-the-Loop Barrier: The agent is strictly prohibited from executing state-modifying actions autonomously.
• Enforcement: No server package update or runtime change may occur without receiving the exact authorization token (CONFIRM_UPDATE_SERVER_<SERVER_ID>_TO_VERSION_<TARGET_VERSION>), and no restore action may occur without receiving the exact restore token (CONFIRM_RESTORE_APP_<APP_ID>). Ambiguous consent is treated as an explicit rejection.

[GUARDRAIL 3: Server Parameter Invariance]

• Scope Containment: Modifying package versions must not introduce collateral configuration drift.
• Enforcement: The agent must not alter web server settings, PHP ini parameters, database connection strings, or system cron configurations. All settings outside the isolated target package version must remain invariant.

[GUARDRAIL 4: Multi-Tenant Fail-Safe Prioritization]

• Server-Wide Blast Radius: In multi-tenant Cloudways topologies, server stability overrides individual patch urgency.
• Enforcement: If the agent cannot conclusively confirm compatibility across 100% of the sibling applications sharing a target server_id, it must immediately abort the server-level runtime change. It is strictly forbidden to resolve a vulnerability on one tenant by risking downtime or fatal runtime errors on co-located tenants.

[GUARDRAIL 5: Pure API Operation – Zero Shell / CLI Invocation]

• Zero-Shell Principle: The agent operates strictly within the Cloudways MCP tool surface for every server and application change. The only calls outside that surface are read-only HTTP GET requests to public advisory feeds and to each application’s primary URL during health verification.
• Enforcement: The agent is forbidden from requesting SSH credentials, generating shell commands, or invoking CLI utilities (such as wp-cli, bash, or sh). Any remediation action outside the capabilities of the Cloudways MCP tools must be flagged for manual user intervention.

[GUARDRAIL 6: Immutable Rollback Tagging on Affected Application]

• Audit Traceability: Every automated modification must have a verifiable recovery point.
• Enforcement: No package alteration may proceed unless a pre-patch backup has completed strictly for the affected application and its unique snapshot reference (cve-patch-{CVE_ID}-{APP_LABEL}-{YYYYMMDD_HHMMSS}) has been confirmed in session memory. If the backup job fails or returns an error status, the remediation pipeline must halt immediately.

[GUARDRAIL 7: Omnichannel Alerting Integrity]

• Notification Delivery: Security events and approval gates must not remain hidden in CLI session logs.
• Enforcement: Every generated advisory, approval request, blocked update report, and health-check failure must be broadcast to all connected communication adapters (Email, Slack, Telegram, WhatsApp) simultaneously before the agent transitions to an idle state, unless the user has set channel preferences that narrow delivery. In that case the agent follows the user’s routing and confirms delivery to at least one channel before going idle. 

 

The file opens with a short header that tells the agent what it needs. It names the Cloudways MCP server and lists the tools the skill calls, and it describes the optional settings. An access token is optional in the file when the MCP is already connected in the Cloudways dashboard, and API keys for the NVD and WPScan advisory sources are optional as well. The header also lists the channels the agent can use for alerts.

The skill calls nine Cloudways MCP tools.

Job in the pipeline	Cloudways MCP tool
Find your servers	server_list
Read PHP and server settings	server_settings_get
List the apps on a server	server_get
Read app settings	app_settings_get
Find installable PHP versions	packages_list
Change the PHP package	server_package_update
Back up one app	app_backup
Restore an app	app_restore
Check a background job	operation_status

The skill also tells the agent to convert every server and app ID to a whole number before each call, because Cloudways rejects string values for IDs.

How the Skill Works

Each scan moves through stages that narrow from broad threat data to one specific change on one specific server. The agent can stop at several points, and it can only change a server at the very end.

Watching the Advisory Feeds

The skill tracks Critical advisories, which it defines as a CVSS base score of 8.0 or higher, along with anything listed in the CISA Known Exploited Vulnerabilities catalog. NVD reserves its Critical label for 9.0 and above, so this threshold casts a slightly wider net on purpose.

Source	What it covers	Throttle the skill applies
NIST NVD	CVE records and PHP core	One query every 6.5 seconds without a key, every 0.8 seconds with one
GitHub Advisory Database	Packagist packages and runtime dependencies	Exponential backoff from 10 to 80 seconds
WPScan	WordPress core, plugins, and themes	25 lookups a day on the free tier, with a 2-second pause between calls
Patchstack	Fast-moving WordPress disclosures	15-minute cache, and Retry-After headers are honored
CISA KEV	Confirmed exploited vulnerabilities	One download per scan, cached for six hours

An agent that respects feed limits keeps its access to those feeds, which matters when the job runs every six hours.

Reading the Live Fleet

Every scan starts from live data. The agent lists your servers, reads each server’s PHP settings, lists the apps hosted there, and records app labels, domains, and WordPress versions. It never trusts a c

ached inventory, and this stage is strictly read-only.

Classifying the Change

Before checking compatibility, the skill sorts every proposed change. A patch update stays in the same PHP branch, such as 8.3.35 to 8.3.36. A branch upgrade moves to another branch, such as 8.1 to 8.2.

Patch updates still get a sibling check as confirmation. Branch upgrades get the full compatibility matrix, which compares the target PHP version against every app’s core version and declared components. If any sibling app might break, the skill marks the server BLOCKED_BY_MULTI_TENANT_INCOMPATIBILITY, sends a report naming the blocking component and its host app, and stops.

Deciding What Happens Next

The feasibility check has two results. If the fixed version is installable on the server and every sibling app passes, the skill prepares an approval request. If Cloudways has not packaged the fix, if the agent cannot verify the patch level, or if the problem lives in a plugin or theme, the skill sends an advisory, changes nothing, and stands by.

The Approval Request

The approval request tells you which CVE is involved, its score and exploitation status, the server, the app and its domain, the current and target versions, confirmation that sibling apps are compatible, the backup name, and what the backup covers. It then asks you to reply with an exact string such as CONFIRM_UPDATE_SERVER_{SERVER_ID}_TO_VERSION_{TARGET_VERSION}. Words like yes or fix it never count.

Carrying Out the Update 

Once the exact string arrives, the skill runs a fixed sequence.

1. Back up the affected app under the name cve-patch-{CVE_ID}-{APP_LABEL}-{YYYYMMDD_HHMMSS} and poll the operation every 5 seconds for up to 10 minutes. If the backup fails or times out, the pipeline stops before touching the server.
2. Update the PHP package, sending only the server ID, the package name, and the target version.
3. Poll the operation until Cloudways reports it complete.
4. Send a GET request to the primary URL of every app on the server.
5. If every app answers with a 200, log the patch with its backup reference and broadcast the result. If any app returns an error, alert you with the exact status codes and offer a restore that needs its own confirmation string.

Guardrails That Protect Your Fleet 

The skill assumes the agent will eventually misread something, so the following rules limit the damage a mistake can do.

• Asynchronous state validation. Cloudways runs changes as background jobs, so an early success response only means a job was queued. The agent polls until the job completes, which stops it from announcing a patch that never finished.
• Exact-string approval. Server changes need the exact update string, and restores need their own string, CONFIRM_RESTORE_APP_{APP_ID}. Ambiguous replies count as a refusal, so a casual “ok” cannot trigger a production change.
• Server parameter invariance. Only the package version changes. The agent never touches PHP ini values, web server settings, database connection strings, or cron, so a patch cannot cause configuration drift.
• Multi-tenant fail-safe. If the agent cannot confirm compatibility for every sibling app, it aborts. One site’s urgency never justifies risking its neighbors.
• Zero shell access. The agent never asks for SSH credentials or runs wp-cli. Its only outside calls are read-only requests to public advisory feeds and to each app’s primary URL.
• Immutable rollback tagging. The named backup must exist and be confirmed before any change, and a failed backup stops the run.
• Alerting integrity. Every advisory, approval request, blocked report, and health failure reaches every connected channel unless you set routing preferences, so a finding never sits unseen in a log.

This set of guardrails are in keeping with the standard agentic AI guardrailing advice that recommends that an agent asking permission before a destructive action should never be your only protection. The agent should operate under predefined restrictions that anticipate and mitigate unintended adverse actions.

With the skill’s logic and guardrails covered, the next step is setting it up for your Cloudways fleet. 

Setting Up a Fresh Hermes Agent

Start from an agent with no Cloudways access, so you can watch each permission arrive. The agent handles most of the installation itself.

Deploy a Managed Hermes Agent

Create a new Hermes agent from the Managed AI Agents area of your Cloudways platform and wait for its status to show Running. The agent page has tabs for Overview, AI Agent, Instance, and LLM & Channels.

Create an Access Token 

Open the Cloudways API page and select Create Access Token. Give the token a clear name and choose the Read-Only scope, then set an expiration date. A short expiry limits the damage if the token is ever misused.

Copy the secret as soon as it appears. Cloudways cannot show it again, and a lost token has to be revoked and replaced.

Connect the Cloudways MCP

Back on the agent’s MCP tab, select Connect on the Cloudways MCP card, paste the token into the dialog, and confirm. Paste it only there, and never into the chat. 

Then ask the agent to list the available Cloudways toolsets to confirm that the connection works.

Give the Agent the Skill

Read the skill in full and adjust parameters and guardrails according to your preferences before you hand it over. 

Paste the following instruction into the chat and add the whole skill file below it.

Below is a skill file called cloudways-vulnerability-guardian. Please set it up as a skill in your environment in whatever way suits you best. Do not run it yet, and do not make any changes to my Cloudways account. When you finish, tell me where you saved it and what you still need from me. Do not ask me to paste an access token, because the Cloudways MCP is already connected in the dashboard.

Let the agent decide how to install the file. Its reply should name the location and any adjustments it made, which are worth reading before you move on.

Run a Discovery-Only Test 

Ask the agent to run only the discovery stage of the skill and change nothing.

Run only the discovery stage of the cloudways-vulnerability-guardian skill. List my servers with their PHP versions and the apps on each one. Do not change, back up, or restore anything.

Compare the answer with your Cloudways Platform dashboard. If the agent’s answer matches your Cloudways dashboard, the connection and the skill both work, and you are ready to schedule scans.

At this point, we assumed that your previous token has Read-only scope. So, when you are ready for real patching, create a second token with Limited Access instead of widening the first one. If the agent reports a missing scope, add the endpoint group it names to the token’s scope  and try again.

Scheduling the Scan with a Hermes Cron Job

A scan that runs only when you remember to ask defeats the purpose of an always-on agent. Hermes lets you create, pause, edit, and remove jobs by asking in plain language, so you hand the agent an instruction and it builds the job.

There is one catch you need to design around. Each scheduled run starts in a fresh session with no memory of earlier conversations, so the job’s instructions must carry everything the run needs, and the skill gets attached to the job. Scheduled runs also cannot create other jobs by default, so you make the request from a normal chat.

The Instruction to Give the Agent

Please create a recurring scheduled job for the cloudways-vulnerability-guardian skill you installed. Create it paused so I can review it before it runs. Run it every 6 hours and name it cloudways-fleet-monitor. Each run starts in a fresh session with no memory of earlier runs, so make the job’s instructions fully self-contained and attach the skill to the job. On each run, discover the live fleet through the Cloudways MCP and check the advisory sources the skill lists, then report any Critical findings that match my inventory. Make no changes to any server or application during a scheduled run. When a finding has a feasible patch, send me the full approval request from the skill and stop there. If nothing needs my attention, respond with only [SILENT]. If possible, make the job continuable so my replies keep the context of what you sent. When I send a confirmation string in chat later, re-run discovery and the compatibility checks before you take any action. When you finish, tell me the job ID, the schedule, the exact instructions you saved, and the delivery target, then wait for me to tell you to resume the job.

Why the instruction reads this way

• Every six hours. This matches the skill’s six-hour cache for the CISA catalog and stays well inside the limits of the advisory feeds.
• Created paused. Hermes supports creating a job paused as a safe canary, so you can read what the agent saved before anything runs.
• Scan only. The scheduled run reports and stops. Any change waits for your exact confirmation string in chat.
• The [SILENT] reply. Hermes suppresses delivery when a run responds with only that marker, and it still saves the output locally. A failed run always delivers, so a broken scan cannot hide.
• Re-running discovery after approval. Your confirmation arrives in a different session from the scan, so the agent checks the fleet again before it acts.

The agent chose the final wording of the job, so reading it is your responsibility. Confirm that it keeps the scan-only rule and attaches the skill before you resume it.

Test the first run against a non-production setup. A real vulnerable server produces a real approval request, so treat even a test as live.

Scheduled agent jobs execute inside the Hermes gateway, and hermes cron status reports whether the scheduler is alive. If the gateway is not running, agent jobs are skipped until it returns. Hermes also has a global emergency stop, hermes pause, that halts every scheduled fire until you run hermes resume.

Activating the Scheduled Scan

The job you created is paused, so nothing runs until you tell the agent to start it. First read the instructions the agent saved and confirm that they match what you asked for.

• The schedule is every six hours
• The skill is attached to the job
• The job reports findings and makes no changes
• A clean scan responds with only [SILENT]
• The delivery target reaches you

Once the saved instructions look right, send the agent this message.

I have read the instructions you saved for cloudways-fleet-monitor, and they match what I asked for. Please resume the job now so it runs every 6 hours. Then tell me the job ID, the time of its next run, and where its results will be delivered. Keep every scheduled run scan only, and send me the full approval request only when a scan finds a Critical vulnerability that matches my inventory. 

The agent should reply with the next run time. If you would rather see a report before waiting six hours, ask it to run the job once now, which Hermes triggers on the next scheduler tick. Do that against a non-production setup first, because a real vulnerable server produces a real approval request.

If the next run time passes without a report, check the scheduler with hermes cron status. Scheduled agent jobs run inside the Hermes gateway, so a stopped gateway skips them. You can pause the job at any time with /cron pause <job_id>.

A good idea is to list all Hermes cron jobs by running hermes cron status  command in the terminal.

 

Ideas for Extending the Skill

The skill is a starting point, and the ideas below are suggestions you can adapt or ignore. None of them are required steps, and several give the agent more power, so weigh that before you try one.

• A PHP package revert prompt. Restoring an app does not undo a server-wide PHP change. A second exact string could let the agent set the package back to the previous version if a health check fails.
• Wider backups. Cloudways MCP offers a server backup tool that backs up a whole server including its apps. A setting could back up every sibling app before a server-level change.
• Remembering what was reported. Hermes can feed a job its own previous output through a continuity option. That could help the scan avoid repeating an alert you have already seen.
• Separate tokens for each phase. A Read-Only token could power the scheduled scan, with a Limited Access token connected only while you approve and run a patch.
• Native WordPress vulnerability data. Cloudways can list WordPress core, theme, and plugin vulnerabilities with severity scores for an app. That could supplement the WPScan source and its daily limit.
• Handling plugin updates. Cloudways Site Manager can run managed WordPress updates with safe updates as the default, and its Pro features cost $3 per app per month. That could take over some of the plugin work the skill currently hands to you.
• Limiting who can approve. A confirmation string works from any connected channel, so you might restrict which senders or channels count as approval.

Conclusion

With this skill in place, detection can run all day while judgment stays with you. Start small by deploying a managed Hermes agent, connecting a Read-Only token, adding the skill, and running a discovery test on a non-production server. Once you trust what you see, widen the token and let the schedule run.

The php2shell flaws show why this matters. The first patches shipped on October 21, a second unpatched flaw appeared two days later, and PHP asks teams to keep its mitigation in place until the next update. A Cloudways PHP update is an ongoing job, and a scanner that never forgets to look earns its place in your routine.

Advisory sources and tool names will change over time, so revisit the skill regularly, especially when Cloudways or Hermes ships a major update.

 

Disclaimer

The skill, prompts, commands, and configurations in this article are provided as examples and templates for educational purposes only. They are not an official Cloudways or DigitalOcean product, are not covered by any support plan or service level agreement, and are provided AS IS without warranties of any kind, express or implied. AI agents can make mistakes, and a skill that can change production servers carries real risk, including downtime and data loss. Before you use any part of this material, review it, test it on a non-production environment, confirm that it fits your own security and backup requirements, and decide for yourself whether the risks are acceptable. You are solely responsible for the agents you deploy and the access you grant them, along with all outcomes. To the fullest extent permitted by law, Cloudways and their affiliates disclaim liability for any loss or damage arising from use of this material. Vulnerability and version details reflect sources available on October 24, 2026 and may change. References to third-party companies and products, including PHP, WordPress, Hermes, and OpenClaw, are for informational purposes only and do not imply any affiliation with, sponsorship by, or endorsement of those third parties . Nothing in this article is legal, security, or professional advice.