PHP2Shell on Forge, Ploi, RunCloud, ServerPilot and Cloudways: Who Updates PHP?

As of 23 October 2026, ServerPilot and Cloudways say they updated PHP on their customers' servers for PHP2Shell, Laravel Forge and Ploi ship fixed PHP that you must install yourself on each server, and RunCloud had published no statement that we could find. Exploitation attempts are widely reported, confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: a server manager is a service that sets up and runs software on a cloud server you rent, and each one splits the patching job differently. On ServerPilot and Cloudways, the provider pushed the fix. On Forge and Ploi, you click an update button for each server. On RunCloud, there is no public word, so check your servers yourself. In every case, confirm the PHP that actually serves your sites.

PHP2Shell is the name for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Who Updates PHP: The Short Version

Here is each provider's position, from its own published statement, as of 23 October 2026:

None of these providers published a ranking or a comparison, and status-page times are when a post went up, not when every server was done. This table only describes who acts. For the broader question of how hosting models split security work, see our comparison of managed and shared hosting security.

ServerPilot: Patched for You, Including Old Versions

ServerPilot's post, "Critical PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619)", dated 21 October 2026, says: "ServerPilot has updated PHP on all servers." It goes further than most on old PHP:

• "PHP 7.4, PHP 8.0, and PHP 8.1: We have updated PHP to versions that include the official patches."
• "PHP 7.0 through PHP 7.3: We have backported the official patches."
• PHP 5.6 got partial mitigations only: "session.upload_progress.enabled is now 0 (disabled). max_input_nesting_level is now 16. post_max_size is now 32M."

ServerPilot also describes a behavior change in its old-version backports: "When a request reaches PHP's memory_limit, the PHP process now exits immediately instead of ending the request with a PHP fatal error... PHP shutdown functions do not run." It adds that these patches "also disable PHP's session upload progress feature." If an old app relies on shutdown functions to finish its work, test it.

To check a server, ServerPilot gives dpkg --list 'sp-php*'. Fixed builds include sp-php8.5 8.5.12-1, sp-php8.4 8.4.27-1, sp-php8.3 8.3.36-1, sp-php8.2 8.2.35-1, sp-php8.1 8.1.34-2, sp-php8.0 8.0.30-4 and sp-php7.4 7.4.33-6. The full list is in ServerPilot's post. If a server shows an older build, ServerPilot's manual command is sudo apt update && sudo apt install --only-upgrade 'sp-php*'.

PHP 5.6 on ServerPilot is mitigated, not fixed. Move those apps to a supported version.

Cloudways: Rolled Out to All Active Servers

Cloudways tracked its rollout on its status page. On 21 October at 22:19 UTC it said the patch was "covering PHP 5.6 and above." On 22 October at 10:11 UTC: "The PHP security patch rollout is complete, and all active servers have been successfully updated." Its customer instruction: "No action is needed from the customers." The incident was marked resolved on 23 October.

Cloudways also addressed the third issue PHP announced on 23 October, CVE-2026-115560. Its update said its security team "implemented mitigations before the vulnerability was formally disclosed" and that "Customers continue to be protected against the new CVE-2026-115560. No action is required from customers at this time."

A separate Cloudways incident on 23 October reported "a potential double-free issue affecting PHP 8.4.27 and 8.5.12," which it described as "a stability and memory-safety concern, not a critical security issue." That matches a PHP bug report about the new releases, GH-24488, closed on 22 October. It is not a way around the PHP2Shell fix. If you see crashes on 8.4.27 or 8.5.12, check Cloudways' status page for its current advice.

Laravel Forge: Click Update PHP on Every Server

Forge sets up your server, but you run the PHP update. Laravel's response post says: "Go to your server in Forge and click 'Update PHP.' Do this for each server." Forge's knowledge base article adds the reason: "Laravel Forge's automatic security updates do not patch PHP. Forge installs PHP from a dedicated package repository, and Ubuntu's unattended upgrades only apply updates from Ubuntu's own security repository."

The steps from Forge's article:

1. Open your server's dashboard and click the PHP tab.
2. For each PHP version, open its dropdown menu and click "Update PHP X.X."
3. "Repeat these steps for every PHP version installed on the server, including versions that your sites do not currently use."
4. Restart long-running processes such as queue workers, Horizon, Octane and Reverb, which "keep running the old version of PHP until they are restarted."
5. Verify with php8.4 -v and php-fpm8.4 -v over SSH (replace 8.4 with your version).

Forge notes that "Updating PHP restarts the PHP-FPM service for that version," which can cause a few seconds of downtime. Two warnings. First, old servers: "If your server runs Ubuntu 20.04 or older, you will not be able to update PHP. Create a new server on a supported Ubuntu version and move your sites to it. Until you do, we recommend powering down the old server." Second, Laravel's own pages disagree about PHP 8.1 and older. The blog says patched versions exist "from PHP 5.6 to 8.5," while Forge's knowledge base lists 8.1 and earlier as "Not patched." Move those sites to PHP 8.2 or newer, preferably 8.3 or newer. For older branches, a php -v number can't prove a fix; check the package changelog. Forge, Vapor, Cloud and Octane are covered in full in our PHP2Shell and Laravel guide.

Ploi: Press Patch, or Run Updates

Ploi posted its guidance on its status page on 21 October: "Update your server in one of these ways: Press Patch in the PHP tab of your server Go to Manage → Updates and press Run now." Like Forge, Ploi leaves the click to you, server by server.

On day one the package builders were busy. Ploi said that if your version wasn't patched yet, you could try again later or "switch to packages.sury.org, which gets the builds first," then run the updates again. Ondřej Surý's repository supplies PHP for many of these platforms; our guide to the Sury and Remi repositories explains the move from the old Launchpad PPA.

Ploi also offered a marketplace script that "turns off session.upload_progress.enabled," and it is honest about what that does: "PHP lists it as a partial mitigation, not a fix." For old PHP, its advice is short: "PHP 8.1 and older get no official release. Upgrade those applications to PHP 8.4 or 8.5."

RunCloud: No Statement Found

As of 23 October 2026, we found no PHP2Shell statement from RunCloud. Its blog had no post about it; the newest post was from 16 October. Its status page listed a 22 October "High Server Load" incident, since resolved, which did not mention PHP. That doesn't mean RunCloud did nothing. It means there is no public statement to rely on.

If your servers are on RunCloud:

1. Check the PHP version and build each site actually runs, using a temporary phpinfo() page through the site. Delete it afterward.
2. Compare it with the fixed releases (8.5.12, 8.4.27, 8.3.36 or 8.2.35). For older branches, ask for the package changelog that names both CVEs.
3. Look in your RunCloud dashboard for a PHP or system update option, and contact RunCloud support in writing to ask whether PHP has been updated on your servers and whether PHP was restarted.
4. Until you have a clear answer, treat the server as unpatched and consider PHP's temporary measures.

Laravel Cloud and Vapor

Two more Laravel platforms come up in the same conversations. Laravel Cloud patched for customers: "We have patched every running application on Laravel Cloud... We applied the patches in place, so your applications stayed online, and no redeploy was needed." Vapor needs a redeploy: "If your applications use a native runtime on PHP 8.2 or later, you will need to redeploy them." Laravel adds: "If you're running PHP 8.0, or 8.1 no patch is available." Details are in our Laravel guide, linked above.

After the Update: Restarts and Long-Running Processes

Whoever installed the fix, PHP only uses it after the processes restart. Forge's update restarts PHP-FPM for you. Background processes are a different story: queue workers, schedulers and app servers started from the command line keep the old PHP in memory until they restart. Forge's examples include php artisan queue:restart and php artisan horizon:terminate; use your own app's equivalent.

One more trap on Ubuntu servers. Ubuntu's automatic security updates are on by default, but Ubuntu's documentation warns: "Just adding another package repository to an Ubuntu system WILL NOT make unattended-upgrades consider it for updates!" Forge says it installs PHP from such a repository, which is why automatic updates did not patch PHP there. Ploi's advice to switch to packages.sury.org points to the same kind of source, so don't count on automatic updates on Ploi servers either. Every restart method, by server type, is in our guide to restarting PHP workers after a security update.

How to Verify on Each Platform

The command-line PHP can differ from the PHP serving your sites, so a web request is the final word. Our guide on how to check your PHP version covers each method, and the PHP2Shell version lookup tells you whether a given build is fixed.

Whatever the platform, keep session upload progress off for now. PHP's 23 October advisory for CVE-2026-115560 suggests you "set session.upload_progress.enabled=0 until the next regular bugfix release," in php.ini or the FPM pool, not with ini_set() or .user.ini.

Conclusion

With server managers, "who patches PHP" has a different answer on each platform. ServerPilot, Cloudways and Laravel Cloud say they patched for you. Forge and Ploi gave you the fixed packages and a button to press on every server. RunCloud has said nothing public yet, so check those servers yourself. In every case, restart long-running PHP processes, confirm through a real web request, and move apps off PHP 8.1 and older. If you'd like help checking and patching a fleet of managed servers, our emergency PHP patching service can work through them with you. The wider split of duties is explained in the shared responsibility model for websites. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions