# PHP2Shell (CVE-2026-109618 & CVE-2026-109619): How xCloud Moved Before the Official PHP Patch

> PHP2Shell (CVE-2026-109618, CVE-2026-109619) is a critical PHP RCE. xCloud applied a temporary mitigation before the patch. See what it covers and what to do.

**If you are an xCloud customer, we have already applied a temporary mitigation for PHP2Shell on your servers.** We did it before the official PHP patch was even released, and you did not have to lift a finger.

![PHP2Shell CVE-2026-109618 and CVE-2026-109619](/_landing/blog/php2shell-vulnerability-cover.jpg)

At xCloud, **we care about security, and our goal is to keep your sites and servers secure at all times.** When a critical bug lands, we do not wait for someone else to fix it first. That is what being safe with us means: we act early, and we tell you plainly what is left for you to do.

**PHP2Shell** is the nickname for **CVE-2026-109618 and CVE-2026-109619**, two critical remote code execution vulnerabilities in **PHP itself**. The PHP security team rated both **CVSS v4.0 9.2** and scheduled the official fix for **21 October 2026 at 14:00 UTC**. Our mitigation is **temporary, not a complete fix**: update PHP on all your servers and sites immediately once the official release is available.

This is a core PHP issue, so it sits below WordPress, WooCommerce, Laravel and every other PHP app, and our guide to [**web hosting security best practices**](/web-hosting-security-best-practices/) will only get you so far. Below, we cover how we worked on it, exactly what the mitigation covers, and the steps to install the official patch.

## **TL;DR: What You Need to Know**

Short on time? Here is the whole story in a few lines:

- **xCloud customers:** we applied a **temporary mitigation** automatically, before PHP core was patched. It switches off the part of PHP the leaked reports point to, which reduces the risk until the official patch is out.
- **Check your inbox:** your team has an email with your protected servers and how many sites are on each.
- **Not a complete fix:** **update all your servers and sites immediately** once the official PHP release is available, from **Manage PHP → Scan Patch**.
- **What it is:** two critical PHP core vulnerabilities (CVSS v4.0 9.2). Proof-of-concept code is already public.
- **Not WordPress:** updating WordPress, themes or plugins does not fix it.
- **PHP 8.1 or older:** these versions are end of life and are not expected to get a fix. Move those sites to PHP 8.3 or newer.

## **How We Worked Proactively**

PHP gave only a day's notice, and reports of a public exploit followed within hours. So we treated it as an emergency from the first announcement.

1. **We assessed the risk the same day.** As soon as PHP announced the release on 20 October, our team reviewed the notice and the early reports, and confirmed that every PHP server on the platform was potentially in scope.
2. **We built a mitigation instead of waiting.** Our team, led by our CTO **Nasir Nobin**, prepared a rule that switches off the part of PHP the leaked reports point to, which reduces the risk until the official patch is out.
3. **We rolled it out across the platform.** On the morning of 21 October, the mitigation was applied automatically to PHP on connected **Managed and Self-Managed** xCloud servers, hours before PHP's official release.
4. **We told every team what we did.** Each team received an email at its team address listing its protected servers and how many sites are on each, plus any servers we could not reach.
5. **We keep retrying the rest.** Unreachable servers are retried once a day, at 19:00 UTC, so they get the mitigation within a day of reconnecting.
6. **We prepared for the real fix.** Support has answers ready for customer questions, and **Manage PHP → Scan Patch** is ready to install the official update the moment patched builds are available.

**We would rather act before a vulnerability becomes your problem.** When a bug sits below your application, the fastest protection is the one your hosting platform applies for you, across every server at once, while you are still reading the news. When we can protect your servers early, we always will.

## **What the Mitigation Covers, and What It Doesn't**

We want you to know exactly where you stand, so here are the gaps as plainly as we can put them.

| **Situation** | **Covered by the mitigation?** |
|---|---|
| PHP installed on a connected xCloud server (Managed or Self-Managed) | ✅ Yes, applied automatically |
| A server that was disconnected or unreachable during the rollout | ⏳ Not yet. Covered within a day of reconnecting (daily retry at 19:00 UTC) |
| PHP running inside your own Docker containers | ❌ No. We only change PHP installed on the server itself |
| PHP 8.3 on a server with a broken PHP 8.3 configuration (two servers platform-wide) | ❌ No, until that configuration is repaired |
| Any server, after the official PHP release | ⚠️ Still needs the official PHP update |

If any of these apply to you, contact xCloud support and we will help you work out the safest next step.

## **Why You Still Need the Official PHP Update**

Here is the honest part. **This is a mitigation, not a complete solution for the issue.**

PHP has not published the technical details yet, so our mitigation is based on the leaked reports. It switches off the part of PHP those reports point to, which reduces the risk until the official patch is out. If the full advisory shows another way in, only the patched PHP build closes it.

If you only remember one line: **the mitigation buys you time, only the PHP update fixes the problem.** Wait for the official release, then update all your servers and sites immediately.

## **PHP2Shell at a Glance**

| **Detail** | **What we know** |
|---|---|
| **CVE IDs** | CVE-2026-109618, CVE-2026-109619 |
| **Nickname** | PHP2Shell |
| **Type** | Remote code execution (RCE) in PHP core |
| **Severity** | CVSS v4.0 9.2 (Critical), as rated by the PHP security team |
| **Announced** | 20 October 2026 |
| **Official fix** | 21 October 2026, 14:00 UTC |
| **Affected versions** | Confirmed by PHP with the release. Early reports say PHP 5.4 and later |
| **Fixed versions** | Expected for supported branches (PHP 8.2 and newer); confirmed with the release |
| **Exploitation** | No confirmed attacks reported at the time of writing, but proof-of-concept code is already public |
| **xCloud status** | Temporary mitigation applied before the official fix; the official PHP update is still required |

## **What Is PHP2Shell?**

**PHP2Shell is the name for a pair of remote code execution bugs in the PHP engine.** Remote code execution means an attacker can make your server run commands they choose, over the network, without logging in. That is the worst class of web vulnerability, because whoever wins it effectively owns the server.

Think of it like a flaw in the lock on your building's front door rather than in any one apartment. It does not matter how well each tenant secures their own door if the main entrance can be opened from the street.

PHP's own announcement is short by design. It says the release "addresses two critical vulnerabilities, both rated CVSS v4.0 9.2", and that "full details, affected versions, and the fixed versions will be published with the release." You can read it on [**php.net**](https://www.php.net/archive/2026.php#2026-10-20-1).

### **A Few Things Worth Knowing**

- **It is not a WordPress bug.** WordPress, WooCommerce, Magento, Laravel and custom PHP apps all run on top of PHP, so all of them are exposed in the same way.
- **You cannot fix it in your app code.** Security plugins and application firewalls run *after* PHP has already handled the request, which is too late for a bug in PHP itself.
- **The timing matters.** Proof-of-concept code is already public, and researchers expect scanning to start right after the release, so the gap between release and update is the riskiest window.

## **Timeline: How It Unfolded**

We will update this timeline as new details arrive.

- **20 October 2026:** PHP publishes an advance notice of a critical security release fixing two vulnerabilities rated CVSS 9.2. Reports of the PHP2Shell exploit and its CVE IDs start circulating the same day.
- **21 October 2026, morning (UTC):** xCloud applies a temporary mitigation across its servers and emails each team a list of its protected servers and how many sites are on each.
- **21 October 2026, 14:00 UTC:** PHP releases the official fix, along with the affected and fixed versions.
- **Following hours:** the PHP package repositories build the patched packages. They show up in **xCloud → Manage PHP → Scan Patch** as they become available.
- **Daily at 19:00 UTC:** xCloud retries servers that were unreachable, so they get the mitigation within a day of reconnecting.

## **Are You Affected?**

If your site runs on PHP, assume yes until you have installed the fixed build. Early reports say every release from PHP 5.4 onward is vulnerable, and PHP will confirm the exact list with the release.

The bigger question is **whether a fix is coming for your version**. PHP only patches supported branches, and the fixed versions are confirmed with the release:

| **PHP version** | **Security support ends** | **Gets the PHP2Shell fix?** |
|---|---|---|
| PHP 8.5 | 31 Dec 2029 | Expected (confirmed with the release) |
| PHP 8.4 | 31 Dec 2028 | Expected (confirmed with the release) |
| PHP 8.3 | 31 Dec 2027 | Expected (confirmed with the release) |
| PHP 8.2 | 31 Dec 2026 | Expected (confirmed with the release) |
| PHP 8.1 | Ended 31 Dec 2025 | ❌ Not expected |
| PHP 8.0 | Ended 26 Nov 2023 | ❌ Not expected |
| PHP 7.4 and older | Ended 28 Nov 2022 or earlier | ❌ Not expected |

You can check the dates on PHP's [**supported versions page**](https://www.php.net/supported-versions.php). To see what you run on xCloud, open your server and go to **Management → Manage PHP**. Each site's version is also shown under **Site → Settings → PHP**. On any other server, run **`php -v`** over SSH.

## **How to Install the Official PHP Patch on xCloud**

The fix is a **patch release** for the PHP version you already run, not a new PHP version. Your sites stay on the same version, and one update per PHP version covers every site on that server.

The patched packages appear a few hours after PHP's 14:00 UTC release, once the package repositories have built them. OpenLiteSpeed builds can arrive at a different time than NGINX builds. Until then, Scan Patch showing no update is expected.

### **Step 1: Open Manage PHP**

Open your server in xCloud and go to **Management → Manage PHP**. You will see every PHP version installed on the server and how many sites use each one.

### **Step 2: Click Scan Patch**

Click **Scan Patch**. xCloud checks the package source for every installed version, and any version with an update shows it in the **Patch** column (for example **8.3.x → 8.3.y**).

![Scan Patch in xCloud Manage PHP](/_landing/docs/how-to-upgrade-php-version-with-xcloud-hosting-patch-available.png)

### **Step 3: Update to the Patched Version**

Open the three-dot menu on that version, choose **Update to …**, and confirm with **Yes, Update!** PHP and the web server reload in a moment, with no server reboot needed.

![Update PHP to the patched version in xCloud](/_landing/docs/how-to-upgrade-php-version-with-xcloud-hosting-update-to.png)

### **Step 4: Repeat for Each Version and Server**

Repeat for every PHP version that shows a patch, on every server. If you run PHP in your own Docker containers, rebuild those images with the fixed PHP version too. 👉 The full walkthrough is in our guide to [**installing PHP security patches**](/docs/how-to-upgrade-php-version-with-xcloud-hosting/#step-5-install-php-security-patches).

### **Optional: Let Your Servers Patch Themselves**

PHP patches are not installed automatically by default. To change that, go to **Security → Security Update**, turn on **Include PHP, database and Redis updates**, and pick a quiet update time. Your server then installs patches like this one on its next daily run. 👉 See [**how automated security updates work**](/docs/reboot-server-with-automated-security-updates/).

![Include PHP, database and Redis updates in xCloud Security Update](/_landing/docs/reboot-server-with-automated-security-updates-third-party-updates.png)

## **On PHP 8.1 or Older? Upgrade Now**

This is the group most at risk. PHP 8.1, 8.0, 7.4 and older are end of life, so **no official PHP2Shell fix is expected for them**. The xCloud mitigation reduces the risk for now, but these sites need to move to a supported version.

Aim for **PHP 8.3 or 8.4**. PHP 8.2 is supported, but its security fixes end on 31 December 2026, so you would be migrating again within weeks.

1. **Take a backup** of the site. 👉 See [**site backups in xCloud**](/docs/site-backups-in-xcloud/).
2. **Clone it to staging** and switch the staging copy to PHP 8.3 under **Site → Settings → PHP**. 👉 See [**how to create a staging environment**](/docs/how-to-create-a-staging-environment-in-xcloud/).
3. **Test what matters:** login, forms, checkout, payments, API endpoints and anything that runs on a schedule. Check the error log for warnings.
4. **Switch the live site** and check it again right away.

Moving from PHP 8.1 is usually smooth, and the most common side effect is deprecation warnings, not errors. Moving from 7.4 is a bigger jump, so expect to update old plugins or themes first. 👉 Our [**PHP version upgrade guide**](/docs/how-to-upgrade-php-version-with-xcloud-hosting/) and [**PHP compatibility notes**](/docs/php-versions-compatibility-in-xcloud/) cover the details.

## **Not on xCloud? What to Do Today**

The same principles apply wherever you host:

- **Find every PHP install** you are responsible for, including staging, containers and forgotten side projects.
- **Ask your host** whether they are mitigating this before the patch, and when they will install the fixed build.
- **If you manage your own VPS,** watch your package source (for most Ubuntu servers, the PHP packages from Ondřej Surý's repository) and run your package upgrade as soon as the fixed build lands. Then reload PHP-FPM or your web server.
- **Plan upgrades** for anything on PHP 8.1 or older, since no fix is expected for those.

Our guide on [**how to maximize your VPS security**](/maximize-your-vps-security/) covers the rest of the hardening basics.

## **Quick Checklist**

- ✅ Check your team's inbox for xCloud's list of your protected servers and how many sites are on each
- ✅ Note any servers listed as unreachable and make sure xCloud can connect to them
- ✅ Update PHP inside your own Docker containers yourself; the mitigation does not reach them
- ✅ As soon as the official release is available, run **Scan Patch** in **Manage PHP** and update every server immediately
- ✅ Turn on **Include PHP, database and Redis updates** so future patches install themselves
- ✅ Move every site on PHP 8.1 or older to PHP 8.3 or newer, testing on staging first

## **Let xCloud Handle the Next One**

Critical bugs below your application will happen again, and the hard part is never the fix itself. It is noticing in time, acting across dozens or hundreds of servers at once, and doing it before attackers do. Your time is the hidden cost.

On xCloud, that work is built in:

- **Platform-wide temporary mitigations** applied for you when a critical bug lands, like the one we rolled out for PHP2Shell.
- **One-click PHP patching** in **Manage PHP**, with **Scan Patch** across every installed version.
- **Automated security updates**, including optional PHP, database and Redis patches on a schedule you choose.
- **Staging sites and backups** that make version upgrades safe to test.

If you want your servers looked after by people who were watching this one at 3 a.m., look at [**xCloud Managed Hosting**](/managed-hosting/), or explore [**PHP hosting on xCloud**](/php-hosting/). **We care about security, and our goal is to keep your sites and servers secure at all times.**

## **Patch Today, and Retire Old PHP for Good**

PHP2Shell is serious, but the path through it is clear. If you are on xCloud, the temporary mitigation already reduces the risk on your connected servers. It is not a complete solution, so your job is to update every server and site from Manage PHP the moment the official release appears, and to stop running PHP versions that no longer get fixes.

Do the patch today. Then schedule this week's upgrades for anything still on PHP 8.1 or older, starting with the sites that handle logins, payments or customer data.

If you have found this blog helpful, feel free to [**subscribe to our blogs**](https://xcloud.host/blog/) for valuable tutorials, guides, knowledge, and tips on web hosting and server management. You can also join our [**Facebook community**](https://www.facebook.com/groups/xcloud.community) to share insights and engage in discussions.

## **Frequently Asked Questions**

### **What are CVE-2026-109618 and CVE-2026-109619?**

They are two critical remote code execution vulnerabilities in PHP itself, nicknamed PHP2Shell. The PHP security team rated both CVSS v4.0 9.2 and scheduled the fix for 21 October 2026 at 14:00 UTC.

### **I'm an xCloud customer. Are my servers already covered?**

Yes, for PHP installed on your connected xCloud servers. We applied a temporary mitigation automatically, on both Managed and Self-Managed servers, and emailed your team a list of your protected servers and how many sites are on each. It is not a complete fix, so update PHP as soon as the official release is available.

### **Is PHP2Shell a WordPress vulnerability?**

No. It is a core PHP issue, so it sits below WordPress, WooCommerce, Laravel or any other app. Updating WordPress or plugins does not fix it; only a PHP update does.

### **Which PHP versions are affected by CVE-2026-109618?**

PHP publishes the exact affected and fixed versions with the release. Early reports say every release from PHP 5.4 onward is affected, so treat every PHP version as vulnerable until you have installed the fixed build.

### **"I'm on PHP 8.1. Will I get a patch?"**

Almost certainly not. PHP 8.1 reached end of life on 31 December 2025, and PHP only patches supported branches. Move those sites to PHP 8.3 or newer after testing on a [**staging copy**](/docs/how-to-create-a-staging-environment-in-xcloud/).

### **Does the xCloud mitigation replace the official PHP update?**

No. It switches off the part of PHP the leaked reports point to, which reduces the risk until the official patch is out. Only the official PHP update fully fixes the vulnerabilities, so update immediately once it is released.

### **Does the mitigation cover PHP inside my Docker containers?**

No. The mitigation changes PHP installed on the server itself. If you run PHP inside your own Docker containers, update those images as soon as the official release is available.

### **My server was listed as unreachable in the xCloud email. What now?**

xCloud retries unreachable servers once a day, at 19:00 UTC, so the mitigation is applied within a day of the server reconnecting. If it stays unreachable, contact xCloud support so the team can help you restore the connection.