PHP2Shell on HestiaCP, VestaCP and CyberPanel

As of 23 October 2026, HestiaCP has published fixed builds of the PHP its own panel runs on, CyberPanel has published tested update steps, and VestaCP has published no PHP2Shell 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: these are free, self-hosted panels, so you patch the server yourself. On each of them there are two kinds of PHP to fix. One is the PHP your websites use, installed from a package repository. The other is the separate PHP copy that runs the panel itself. HestiaCP and CyberPanel both keep their own panel PHP, and both vendors say it needs its own update. Updating site PHP alone leaves the panel exposed.

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

The Three Panels at a Glance

None of the three fixed this with a new panel release. Hestia's newest release is still 1.10.5 from September 2026, and CyberPanel says its fix "does not require or claim a new CyberPanel source release." The fixes are package updates.

HestiaCP: Site PHP and hestia-php

A Hestia staff member, eris, explained the split on 21 October: "We only able to push an auto update hestia and hestia-* packages If php8.5.12 becomes available we are able to download it and build Hestia-php packages So the rest need to be done manually." In other words, Hestia's team can ship the panel's PHP, but your site PHP comes from Sury's repository and you update it yourself. On 22 October eris added: "Hestia run it own php version for the backend."

The panel's PHP took a little longer. On 21 October, before the fixed panel build existed, staff advised stopping the panel: "you should stop Hestia ( systemctl stop hestia ) until we can build the new hestia-php package." Another staff member added that the hestia service had to be stopped along with the web server if you were shutting things down. Stopping the panel does not stop your websites once their PHP is updated; eris confirmed that.

The fixed panel build arrived on the morning of 22 October. When we checked Hestia's package repository on 23 October, hestia-php 8.5.12 was published for every release it covers:

The previous build was 8.5.9. If your server still shows hestia-php 8.5.9 or lower, the panel is unpatched.

HestiaCP: How to Patch

1. Take a backup or server snapshot. Our guide to backups and recovery explains what a usable backup includes.
2. Check which PHP repository your server uses. In the forum thread "PHP vulnerability", Hestia staff told users to move to packages.sury.org and "delete the old sources.list file of the old sury repo," because the old Launchpad PPA returned "503 Service Unavailable" errors on 21 October. Hestia's own upgrade documentation says that on Ubuntu 26.04, "PHP packages are now distributed exclusively through the official Sury APT repository." Our guide to Sury and Remi explains the repository change.
3. Update everything. Staff wrote: "apt update && apt upgrade -y should be enough." Asked whether that also patches hestia-php, staff answered: "yes, as written in this thread."
4. Restart PHP-FPM for every PHP version you have installed, for example systemctl restart php8.3-fpm (replace 8.3 with each version), and restart Apache if the server uses it.
5. Start or restart the panel: systemctl restart hestia.
6. Verify (see the verification section below).

Two known snags. First, ARM servers waited longer. A staff member said on 21 October that Sury had not finished building "the packages for that architecture yet." If you run ARM, check each package version rather than assuming. Second, some users saw an apt "Hash Sum mismatch" error on Hestia's repository on 22 October; staff said they purged a cache and that packages "should be delivered fine now."

Ubuntu 20.04 needs a decision. A staff member said Sury no longer supports it, and that a hestia-php build for 20.04 "means the Control Panel's PHP vulnerability will be fixed, but your websites running PHP will still be vulnerable. You should upgrade to a supported version of Ubuntu." Ubuntu itself ships fixed PHP 7.4 for 20.04 only through Ubuntu Pro.

The Hestia panel listens on port 8083 by default. If you can't patch the panel right away, keep it stopped or restrict who can reach that port. Our guide to access control and 2FA covers locking down admin screens.

VestaCP: No Statement Found

We found no PHP2Shell statement from VestaCP as of 23 October 2026. Its home page shows "Vesta 2.0 is coming soon!" and no security notice, and its forum returned a browser challenge when we tried to read it.

That leaves the job with you. Treat a VestaCP server like any self-managed Linux server:

1. Find every PHP version installed and which repository each came from (your operating system's own packages or a third-party repository such as Sury).
2. Update through that same repository, then restart PHP-FPM and the web server.
3. Check whether the panel runs its own PHP copy. We could not confirm this for VestaCP, so look at the panel's service before assuming it's covered by your site updates.
4. If you can't confirm the panel's PHP is fixed, stop the panel service or block access to its port until you can.

If the server runs an operating system that no longer gets security updates, the PHP fix won't reach it through normal channels. That's a sign to plan a move to a supported OS and a maintained panel.

CyberPanel: Site PHP, Panel PHP and WebAdmin

CyberPanel runs on LiteSpeed, so site PHP comes from LiteSpeed's lsphp packages. CyberPanel's post, "Critical PHP security updates: CyberPanel response and testing plan" (21 October, updated 23 October), lists the pieces to fix separately: "Inventory Ubuntu OS PHP, LiteSpeed lsphp , CyberPanel's separate panel/phpMyAdmin PHP and WebAdmin as distinct runtime targets." It adds: "Updating an Ubuntu OS package does not replace a private-prefix LiteSpeed binary or a copied panel executable."

Its summary of the fix: "Update every affected PHP runtime and its matching modules, refresh CyberPanel's separate panel PHP copy, then recycle all relevant workers and verify real HTTP requests." On its Ubuntu 26.04 test server, the fixed LiteSpeed packages were "8.2.35-1+resolute, 8.3.36-1+resolute, 8.4.27-1+resolute and 8.5.12-1+resolute." On Ubuntu 20.04, fixed 8.2, 8.3 and 8.4 candidates appeared by 22 October.

The panel step is specific. CyberPanel's panel PHP lives at /usr/local/lscp/fcgi-bin/lsphp. On its test server, which used PHP 8.3 for the panel, CyberPanel "atomically replaced /usr/local/lscp/fcgi-bin/lsphp with the updated /usr/local/lsws/lsphp83/bin/lsphp" and checked that the file hashes matched. It warns: "Do not blindly use the 8.3 path on a server with a different panel runtime." Confirm which version your panel uses first.

WebAdmin is LiteSpeed's own admin console, and it runs on its own bundled PHP binary, admin_php. LiteSpeed Web Server 6.3.7 build 5 (22 October) says: "Update the admin_php binary for CVE-2026-109618 and CVE-2026-109619." If your server runs OpenLiteSpeed instead, check its release notes for the same fix. Our PHP2Shell on LiteSpeed guide covers that update.

CyberPanel: How to Patch

1. Take a provider snapshot or a verified backup, and list every installed PHP branch, "including the panel binary," as CyberPanel puts it.
2. Refresh your LiteSpeed repository metadata and confirm the fixed versions are offered: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. CyberPanel saw lagging repositories on 21 October, so check rather than assume.
3. Upgrade each installed lsphp branch together with its matching modules. CyberPanel found that "Updating PHP core while retaining an old OPcache module is incomplete."
4. Refresh the panel's PHP copy from the updated lsphp binary for the version your panel uses.
5. Restart PHP itself, not just the web server. CyberPanel warns that "Detached workers can outlive a web-service restart." LiteSpeed's documentation gives touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt followed by systemctl restart lsws for OpenLiteSpeed, or pkill lsphp.
6. Verify each site, the panel login and phpMyAdmin through real web requests.

Every restart method, by server type, is in our guide to restarting PHP workers after a security update.

How to Verify on Any of These Panels

Don't rely on php -v alone. The command-line PHP can be a different version from the one serving your sites, and Ubuntu's own fixed packages keep old version numbers. Delete any phpinfo() file once you've read it. 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.

Keep Session Upload Progress Off

On 22 October, a user asked whether the temporary settings could be reverted after patching, and a Hestia staff member replied: "After updating it is not needed any more." That reply came a day before PHP's 23 October informational advisory for a third issue, CVE-2026-115560, which affects patched releases too. PHP now suggests you "set session.upload_progress.enabled=0 until the next regular bugfix release." CyberPanel's 23 October follow-up says the same and adds: "Application ini_set() or FPM .user.ini is insufficient."

So the safe position is: you may restore memory and upload limits you lowered as stopgaps, but keep upload progress off in php.ini or the FPM pool for every PHP version, then restart. PHP notes that apps which never change the session serializer at runtime "can keep the feature enabled," so this is a precaution, not an emergency. The other temporary measures are in PHP2Shell interim mitigations.

Conclusion

On HestiaCP, VestaCP and CyberPanel, PHP2Shell is your job, and it has two parts: the PHP your sites run and the PHP the panel runs. On Hestia, apt update and apt upgrade now cover both, as long as your site PHP comes from packages.sury.org and your OS is still supported. On CyberPanel, update each lsphp branch with its modules, refresh the panel's copy and recycle detached workers. On VestaCP, update from your repository and confirm the panel's PHP yourself. If you'd like someone to patch and verify a self-hosted panel server with you, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions