{"id":18307,"date":"2026-11-01T23:22:06","date_gmt":"2026-11-02T05:22:06","guid":{"rendered":"https:\/\/www.supportpro.com\/blog\/?p=18307"},"modified":"2026-11-02T03:40:04","modified_gmt":"2026-11-02T09:40:04","slug":"php2shell-cpanel-plesk-directadmin-cwp-checklist","status":"publish","type":"post","link":"https:\/\/www.supportpro.com\/blog\/php2shell-cpanel-plesk-directadmin-cwp-checklist\/","title":{"rendered":"PHP2Shell: What cPanel, Plesk, DirectAdmin, and CWP Administrators Must Check Now?"},"content":{"rendered":"\n

PHP security updates should be a priority for hosting administrators after the disclosure of two critical vulnerabilities known as PHP2Shell<\/strong>. Tracked as CVE-2026-109618<\/strong> and CVE-2026-109619<\/strong>, these vulnerabilities affect PHP’s core runtime and can allow unauthenticated attackers to execute code remotely on vulnerable servers.<\/p>\n\n\n\n

Both vulnerabilities carry a CVSS v4.0 score of 9.2. Security authorities have also reported exploitation in the wild, making this an issue that requires immediate attention. For hosting providers, updating a single PHP installation is not enough. A server may have several PHP versions installed, with different websites using different handlers and configurations.<\/p>\n\n\n\n

First, identify every PHP runtime serving web requests, verify its security status, and apply the appropriate vendor updates.<\/strong> This includes PHP-FPM, Apache mod_php, CGI, and LiteSpeed environments, as well as PHP installations bundled with applications or containers. If you manage a hosting environment with multiple domains and PHP versions, check the following.<\/p>\n\n\n\n

<\/p>\n\n\n\n

What Is the PHP2Shell Vulnerability?<\/h2>\n\n\n\n

PHP2Shell<\/strong> refers to two critical PHP remote code execution vulnerabilities<\/strong>, CVE-2026-109618 and CVE-2026-109619.<\/p>\n\n\n\n

Both vulnerabilities involve PHP’s internal request processing and memory management.<\/p>\n\n\n\n

CVE-2026-109618: Remote Code Execution Through Memory Corruption<\/h3>\n\n\n\n

CVE-2026-109618 is related to improper handling of memory allocation failures. When PHP runs out of memory while processing a request, some internal data may remain partially initialized. Subsequent cleanup operations can access this invalid state, creating an opportunity for remote code execution.<\/p>\n\n\n\n

CVE-2026-109619: Remote Code Execution Through Use-After-Free<\/h3>\n\n\n\n

CVE-2026-109619 involves a use-after-free condition. PHP can retain references to memory after it has been released. If a later request accesses that memory before the relevant state is properly initialized, it can result in memory corruption and potentially remote code execution.<\/p>\n\n\n\n

These vulnerabilities affect PHP itself, not just a particular website application. Updating WordPress, installing a security plugin, or changing application-level authentication settings will not fix a vulnerable PHP runtime. Administrators must address the PHP installation directly. That is why\u00a0PHP security updates\u00a0should be part of your server maintenance<\/a> process, not something handled only at the application level.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Which PHP versions need attention?<\/strong><\/h2>\n\n\n\n

The PHP project released security fixes for its supported branches on October 21, 2026.<\/p>\n\n\n\n

PHP branch<\/th>First fixed release<\/th><\/tr>
PHP 8.2<\/td>8.2.35<\/td><\/tr>
PHP 8.3<\/td>8.3.36<\/td><\/tr>
PHP 8.4<\/td>8.4.27<\/td><\/tr>
PHP 8.5<\/td>8.5.12<\/td><\/tr><\/tbody><\/table><\/div><\/figure>\n\n\n\n

These are upstream reference versions. However, administrators should not rely on version numbers alone when checking older installations. Linux distributions and hosting vendors sometimes backport security fixes without changing the upstream PHP version the package displays.<\/p>\n\n\n\n

For example, Plesk identifies patched PHP 8.1.34, 8.0.30, and 7.4.33 builds using their build dates rather than new version numbers. Check the package release details and vendor security changelog for both CVE identifiers. If no confirmed fix exists, treat the installation as exposed and plan an upgrade or other appropriate mitigation.<\/p>\n\n\n\n

For a more detailed explanation of the original vulnerability and its fixed releases, read more on the PHP CVE-2026-109618 and CVE-2026-109619 update<\/a>.<\/p>\n\n\n\n

<\/p>\n\n\n\n

How to Check PHP2Shell on cPanel, Plesk, DirectAdmin, and CWP?<\/h2>\n\n\n\n

The PHP2Shell remediation<\/strong> process depends on how PHP is installed and maintained. Here is where administrators using the four common hosting control panels should begin.<\/p>\n\n\n

\n
\"PHP<\/a><\/figure>\n<\/div>\n\n\n

Let’s look at what each control panel administrator should check.<\/p>\n\n\n\n

PHP2Shell cPanel: What Should Administrators Check?<\/h3>\n\n\n\n

Start with EasyApache 4 and identify all installed PHP packages.<\/p>\n\n\n\n

MultiPHP Manager can help determine which PHP versions each domain uses. Administrators using CloudLinux should also check alt-php installations separately. Updating EasyApache packages does not automatically confirm that alternative PHP builds are patched.<\/p>\n\n\n\n

For a PHP2Shell cPanel fix<\/strong>, check the relevant cPanel security advisory and package changelogs for both CVEs. Also verify the PHP components WHM uses internally, where applicable.<\/p>\n\n\n\n

The key point is that the PHP version assigned to a domain and the PHP version used internally by the control panel may differ.<\/p>\n\n\n\n

<\/p>\n\n\n\n

PHP2Shell Plesk: How to Verify the PHP Security Update<\/h3>\n\n\n\n

Plesk administrators should review every PHP version installed through the panel, including versions assigned to individual domains.<\/p>\n\n\n\n

Plesk has published specific patched builds for PHP 8.2 through 8.5. Older branches require additional attention because their version numbers may remain unchanged after a security backport.<\/p>\n\n\n\n

Check the build date and package information rather than relying only on the output of php -v<\/code>.<\/p>\n\n\n\n

Also review the Plesk component updates identified in its advisory. The PHP runtime used by hosted websites and the PHP engine used internally by the control panel are separate components that need verification.<\/p>\n\n\n\n

For example, Plesk’s official advisory identifies patched builds of PHP 8.1.34, 8.0.30, and 7.4.33 by build date.<\/p>\n\n\n\n

<\/p>\n\n\n\n

PHP2Shell DirectAdmin: What Needs to Be Updated?<\/h3>\n\n\n\n

DirectAdmin commonly uses CustomBuild to install and maintain PHP versions.<\/p>\n\n\n\n

Check the versions configured through CustomBuild and identify which one each domain uses.<\/p>\n\n\n\n

If several PHP versions are installed, updating only one branch leaves the others unchecked.<\/p>\n\n\n\n

After applying the relevant package updates or rebuilding PHP, verify the installed builds and restart the affected PHP-FPM services according to the server configuration.<\/p>\n\n\n\n

A successful CustomBuild operation is not the end of the PHP2Shell patch verification<\/strong> process. You still need to confirm that the affected websites are using the updated runtime.<\/p>\n\n\n\n

PHP2Shell CWP: How to Check PHP Installations<\/h3>\n\n\n\n

CWP administrators should first determine where their PHP packages come from.<\/p>\n\n\n\n

Depending on the configuration, PHP may be managed through the panel’s PHP Selector, PHP-FPM, or external package repositories.<\/p>\n\n\n\n

Check the security advisory and changelog provided by the package maintainer. Address both PHP2Shell vulnerabilities before deeming the installation patched.<\/p>\n\n\n\n

A general system package update is not sufficient evidence that every CWP-managed PHP version is secure.<\/p>\n\n\n\n

For hosting providers managing multiple servers, documenting the package source and patch status for each PHP installation can make future vulnerability reviews easier.<\/p>\n\n\n\n

Why php -v<\/code> Is Not Enough to Verify PHP2Shell<\/h2>\n\n\n\n

One common mistake during a PHP version security check<\/strong> is running:<\/p>\n\n\n\n

php -v<\/code><\/pre>\n\n\n\n
and assuming the displayed version represents every website on the server.<\/p>\n\n\n\n
This command reports the PHP CLI version selected by the system. Websites may use a different PHP binary through PHP-FPM, CGI, Apache, or LiteSpeed.<\/p>\n\n\n\n
For example, the command line might report PHP 8.3 while a website continues running PHP 8.1 through a separate PHP-FPM pool.<\/p>\n\n\n\n
That means a server can appear updated from the command line while one or more hosted websites continue using a vulnerable PHP runtime.<\/p>\n\n\n\n
Administrators should check the following for every active domain:<\/p>\n\n\n\n