How We Patched PHP Across KnownHost’s Managed Infrastructure

We have been applying the fix for a critical remote code execution vulnerability in PHP across our shared hosting servers and the managed cPanel, DirectAdmin, and Plesk servers we maintain for customers. cPanel, CloudLinux, DirectAdmin, and Plesk each released patched PHP builds, and we have been installing them as each one became available.

This post explains what was fixed, how we rolled it out, and why the PHP version number on many servers did not change even though the fix is installed. If you want confirmation for your own server or account, our support team can check it for you.

If you are on one of our shared hosting plans or a managed server, there is nothing you need to do.

What issue was corrected

The PHP project released fixes for two critical vulnerabilities on October 21, 2026, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS 9.2 and allow an attacker to run code on a server without logging in. The first is memory corruption that occurs when PHP runs out of memory while processing a specially crafted form or file upload. The second lets data left over from an earlier request be reused after its memory is freed, for example through PHP’s session upload progress feature (CloudLinux incident page).

The fix changes PHP so allocation failures are reported safely instead of aborting partway through, and clears leftover request data when each request finishes. On cPanel, patched EasyApache 4 packages cover PHP 7.4 and newer, and cPanel points customers on older PHP versions to TuxCare Extended Lifecycle Support (cPanel advisory). CloudLinux’s EasyApache 4 builds cover PHP 5.2 and newer.

If your cPanel server runs PHP 7.3 or older and does not use CloudLinux or Imunify360, cPanel’s packages do not include the fix for those versions. We recommend either adding a CloudLinux or Imunify360 license, which provide patched builds for older PHP versions, or upgrading your sites to PHP 7.4 or newer. Open a ticket and our team can help with either option.

How we rolled out the PHP patch

Our shared hosting servers run CloudLinux, which publishes its own builds of the EasyApache 4 PHP packages. CloudLinux takes cPanel’s source packages and rebuilds them so PHP works correctly with CageFS, LVE limits, and the PHP Selector. On those servers, the fix arrives through CloudLinux’s repository, not directly from cPanel.

When the advisory came out, we checked each server for updated packages and read the changelog of every available build before installing it. Once CloudLinux’s patched builds were available, we updated all ea-php packages and restarted the web server so no PHP process was left running the old code.

We followed the same process on the managed cPanel VPS and dedicated servers we maintain. Servers using cPanel’s standard repositories receive cPanel’s own patched builds, and servers running CloudLinux receive CloudLinux’s builds. In both cases we confirm the fix from the installed package itself, not the PHP version number.

DirectAdmin released patched PHP builds covering PHP 5.6 through the current release, and we’ve been working through our DirectAdmin servers to apply it. Plesk servers received the fix through Plesk’s own update repositories.

Why your PHP version number may not have changed

Not every patched build came with a new PHP version number. For PHP 8.1 and older, cPanel, DirectAdmin, and Plesk backported the fix into the version servers were already running. CloudLinux went further and backported it into every PHP version it ships. On our servers, for example, PHP 8.4 still reports as 8.4.26 after the update. The change shows up only in the package release, which moved to 8.4.26-2.cloudlinux.1, and in the package changelog, which lists both CVEs.

Backporting is common practice for operating system vendors. It delivers a security fix without changing anything else about the software, which lowers the risk of an update breaking a site. The side effect is that anything judging PHP by its version number alone can be misleading. A phpinfo() page, a security scanner, or a plugin that reports your PHP version may still show 8.4.26 and suggest the server is unpatched when it is not.

CloudLinux is now rolling out builds that carry the incremented PHP version number, matching the new upstream PHP releases such as PHP 8.4.27 (CloudLinux incident page). Once those are installed, version checks will reflect the fix and these false positives should stop. On managed servers, we install these builds as they become available.

How to verify your server

If you would like confirmation that the fix is installed on your server or for your hosting account, open a ticket with our support team. We will check the installed PHP packages and confirm which builds you are running. This is also the best route if a scanner or audit has flagged your PHP version and you need documentation that the fix is in place.

cPanel and CloudLinux

If you have root access to a cPanel VPS or dedicated server, you can check this yourself. The following command searches the PHP 8.1 package changelog for the fix. To check your own version, replace 81 with your PHP version number, for example ea-php83 for PHP 8.3 or ea-php74 for PHP 7.4.

rpm -q ea-php81-php-cli --changelog | grep -i cve-2026-10961

On a standard cPanel server, a patched package returns a line like this:

- EA-13611: Backport fix for CVE-2026-109618 and CVE-2026-109619

On a CloudLinux server, it looks like this:

- EA4D-1101: CVE-2026-109618, CVE-2026-109619

If the fix is installed, the command returns a line naming both CVEs, like the examples above. If it returns nothing, contact us.

DirectAdmin

On DirectAdmin servers, how you check depends on your PHP version. PHP 8.2 and newer were updated to the new upstream PHP releases, so the version number changes. PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12, or later include the fix.

For PHP 5.6 through 8.1, the version number stays the same, because DirectAdmin applies the fix as patches when CustomBuild compiles PHP. To confirm on those versions, first check that the patch files are present:

ls -la /usr/local/directadmin/custombuild/patches/php-*/*-cve-2026-10961?.patch

You should see a patch file for each PHP version from 5.6 through 8.1, such as 114-php-8.1-cve-2026-109618.patch for PHP 8.1. Then check whether CustomBuild has any PHP updates waiting:

da build versions | grep avail

If the patch files are present and no PHP updates are listed, the fix is in place. If the patches are missing or a PHP update is still available, contact us.

Plesk

On Plesk servers, there are two things to check: the PHP versions your sites use, and the PHP that runs the Plesk control panel itself. The panel’s PHP updates along with Plesk, so start by checking the Plesk version:

plesk version | grep 'Product version'

Plesk 18.0.81.4 (18.0.81 Update 4) or later includes the fix, as does 18.0.80.11 or later on the 18.0.80 branch. Then check each PHP version installed for your sites:

for p in /opt/plesk/php/*/bin/php; do "$p" -v | head -1; done

For PHP 8.2 and newer, the version number tells you whether the fix is installed: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12, or later. For PHP 7.4, 8.0, and 8.1, Plesk backported the fix without changing the version number, so check the build date in the output instead. A build date of October 21, 2026 or later means the fix is included. If the Plesk version or any PHP version falls short, or the list includes PHP older than 7.4, contact us.

If your server is not patched

We work through every server we manage when an update like this is released, but we cannot guarantee that every server was updated, since configurations vary from server to server. If you find that your server is not patched, open a ticket and we will get it updated.