Cloudways PHP2Shell status: what it says and how to confirm

Cloudways's own status page says the PHP2Shell patch rollout was complete for all active servers on 22 October 2026 at 10:11 UTC, on both Autonomous and Flexible, with no customer action needed. That is the host's statement about its fleet. To confirm your app, ask support for the fixed build and the restart.

Who is affected on Cloudways?

Any app on a Cloudways server that runs PHP. The PHP project says all installations serving web requests are in scope, including PHP-FPM, mod_php, CGI, FrankenPHP and LiteSpeed. WordPress and WooCommerce always run on PHP, so they are in scope. A Node.js or static app on the same account does not run PHP.

Cloudways's status page names two platforms, Autonomous and Flexible, and gives a separate time for each. It says the Autonomous patch was applied by 22 October 01:02 UTC and the Flexible rollout finished by 10:11 UTC the same day. If your app sits on an old PHP branch, read the next section.

What does Cloudways's page say, and what does it leave out?

The status page tells you what the host did to its fleet. It does not tell you what runs your app. Here is the gap.

• It lists branches, not builds. The 21 October 22:19 UTC update says the phased rollout covered PHP 5.6 and above, naming 5.6, 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4. It does not list a fixed package or build for each.
• Old branches rely on backports. PHP says 8.1 and older no longer receive updates from the project, and that some vendors provide backported fixes. Cloudways says deprecated versions are covered through extended support partners.
• It does not mention restarts. The page says servers were updated. It does not say which workers were restarted or when.
• It says "no action needed". That is Cloudways's statement for the rollout. It does not replace a per-app answer if you need one for a client or an audit.

At our check on 26 October 2026 we could not read any per-app build identifier from outside. Treat any other "Cloudways is patched" claim, on a forum or in a thread, as a lead until it links this status page. Why a checker sees a banner, not a patch has the longer explanation.

How do I confirm my Cloudways app is patched?

Where do I see the PHP version?

Cloudways's PHP version guide places the setting under Application Settings, then PHP Settings, for Flexible apps. For Autonomous the same guide points to the app's Tools or Workflows area. The guide did not load for us on 24 October, so check the labels in your panel. This screen shows the branch you selected. It is not proof of a fixed build.

What do I ask support?

Send this and keep the reply:

For [your app and domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP-FPM or Apache workers serving it have been restarted or replaced, and say whether I need to redeploy or change a setting.

• Note whether the app is on Flexible or Autonomous
• Note the PHP branch the panel shows
• Send the question above and save the reply with its date
• Look for a build identifier or changelog entry naming both CVE ids, and a restart time
• Ask about any PHP you run outside the managed stack, such as a container you built yourself

Am I affected? A three-state self-test

Was anything exploited before Cloudways patched?

Attempts, yes. AWS reported honeypot attempts from 17 October, four days before disclosure, and said it is unclear whether those would have worked on real systems. After public proof-of-concept code appeared, AWS reported broad attempts against its sensors. The AWS post we read on 24 October 2026 reports attempts and does not report a confirmed compromise. That can change, so re-check; attempts versus real compromise is tracked on its own page.

Cloudways's 22:19 UTC update on 21 October says interim configuration-level mitigations were deployed across the fleet and the phased rollout of official patches had begun. That is Cloudways's own statement and we cannot verify it from outside.

If your app ran an unpatched PHP between 17 and 22 October, look for unexpected PHP files in upload directories, cron entries you did not create, new administrator accounts, and unusual outbound connections. Patching removes nothing planted earlier.

What about CVE-2026-115560?

On 23 October php.net posted a follow-up naming CVE-2026-115560. The notice describes an unlikely RCE route that depends on specific session settings, suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, and says a full advisory will come with that release. Cloudways's 23 October note says it has mitigations in place and that no customer action is needed. It also mentions reports of a possible memory-safety crash bug in 8.4.27 and 8.5.12, which it calls a stability concern. We have not seen a PHP advisory for that second item.

PHP recommends that setting until the next release, and says that if you already applied it after the 21 October advisory, you should keep it in place. If you change PHP settings yourself, keep a note of what you changed.

What is the bug, in plain terms?

Both CVEs are memory-safety problems in the PHP engine, reachable by an unauthenticated web request. CVE-2026-109618 is remote code execution through out-of-memory corruption. CVE-2026-109619 is remote code execution through stale request state in a worker. The PHP project describes the conditions in its advisories. We do not reproduce attack code, and you do not need them to fix your site.

For the full version table see the fixed versions page and the PHP2Shell overview. For the same question on other hosts see SiteGround and how Kinsta answers the same question, or Hostinger's hPanel check and DigitalOcean's Droplet case. The rest are in the other host status guides. If you run your own container, rebuild and redeploy the image. The wider October picture is in the tracker.