Updated 23rd October 2026 | 05:59 UTC
On the 21st of October we published an article regarding the two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619).
Since then, NetShop’s support team has patched more than 300 VPS and dedicated servers for customers who were struggling to handle the issue on their own.
This article aims to provide a more in-depth explanation about this PHP vulnerability, understand if your servers are exposed to PHP2Shell and how to mitigate the situation so your websites and applications are safe.
What is PHP2Shell
PHP2Shell is a pair of high-impact vulnerabilities in PHP that allow remote code execution (RCE). It affects PHP versions from 5.4 to 8.5. Their existence was publicly announced on 20 October 2026. An emergency patch for versions 8.2, 8.3, 8.4 and 8.5 and details about the vulnerabilities were released the following day.
Since our original article on the 21st of October, a few things have changed:
- Amazon announced that they recorded the first attempt on 17 October, four days before disclosure.
- Backported fixes now exist for end-of-life PHP 7.4, 8.0 and 8.1 through cPanel, Plesk, CloudLinux, Debian/Ubuntu and AlmaLinux.
- CISA advises taking PHP systems offline if they cannot be patched immediately, or if they run PHP 8.1 or older without a backport.
- A related path can leak live server memory without running any code, so secrets may be exposed even where RCE fails.
Who is Affected
Any PHP installation that serves web requests is potentially vulnerable, from PHP 5.x through 8.5.
The risk varies by how PHP is executed:
| PHP setup | Risk |
|---|---|
| Apache mod_php | Highest: a demonstrated attack runs before your application code starts |
| PHP-FPM (Nginx, Apache, cPanel, Plesk) | High: validated exploit path, depends on application behaviour |
| php-cgi, FrankenPHP, LiteSpeed (LSAPI) | Potentially affected |
| PHP CLI only (cron, scripts) | Not web-exposed, but patch anyway |
This covers WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel and Symfony sites, as well as control panels, billing systems and the PHP-based CRMs and client portals common among forex brokers and fintech firms. If you run WordPress hosting or a custom PHP application, you are in scope.
The biggest exposure is outdated PHP. One analysis found that 59% of internet-facing PHP hosts run versions that receive no official fix from php.net.
Which PHP versions fix PHP2Shell?
Update to the patched release for your PHP branch. Configuration changes alone cannot fully mitigate these flaws.
| PHP branch | Fixed version | Notes |
|---|---|---|
| PHP 8.5 | 8.5.12 | Official php.net release |
| PHP 8.4 | 8.4.27 | Official php.net release |
| PHP 8.3 | 8.3.36 | Official php.net release |
| PHP 8.2 | 8.2.35 | Official release; PHP 8.2 reaches end of life on 31 December 2026 |
| PHP 8.1, 8.0, 7.4 (EOL) | No php.net release | Vendor backports only (see below) |
| PHP 7.3 and older | Mostly none | Only CloudLinux and paid extended-support vendors |
For end-of-life PHP versions, php.net did not publish any new releases, but the PHP security team released minimal source patches for 7.4, 8.0 and 8.1, and several vendors have backported the fix:
| Platform | Fixed EOL versions |
|---|---|
| cPanel (EasyApache ea-php) | 7.4, 8.0, 8.1 |
| cPanel with CloudLinux (alt-php / PHP Selector) | 5.2 to 8.5 |
| Plesk Obsidian | 7.4.33, 8.0.30, 8.1.34 (same version number, look for a 21 Oct 2026 build date) |
| Debian / Ubuntu via Sury PPA | 5.6, 7.4, 8.0, 8.1 |
| Ubuntu 22.04 | 8.1 |
| AlmaLinux 8–10 | All shipped PHP streams |
| RHEL 8, 9 | Some streams, others in progress |
| CentOS 7 | No fix: upgrade the OS |
| Official Docker php image | No fix for 8.1 or older |
If your platform has no backport, CISA’s guidance is to take the system offline until it is upgraded. In practice, this is the right moment to plan a move to PHP 8.3 or 8.4, since 8.2 also goes EOL in ten weeks. NetShop’s support team can help by raising a ticket (existing customers) or simply contact us and we will respond straight away.
How To Check If Your Server is Patched or Exposed
First step is to login on your server via SSH. Depending on the Operating system your server runs, run the following commands to find out the PHP versions installed:
# CLI version
php -v
# Debian / Ubuntu: confirm the CVE fix is in the package changelog
zcat /usr/share/doc/php8.1-common/changelog.Debian.gz | grep CVE-2026-109618
# RHEL / AlmaLinux / Rocky (Remi packages: use php81-php-common etc.)
rpm -q –changelog php-common | grep CVE-2026-109618
# cPanel EasyApache: list all installed PHP versions
rpm -qa | grep -E ‘ea-php[0-9]+-php-cli’
# Plesk: check build date of each PHP handler
plesk bin php_handler –list
Temporary Mitigation Steps If Patching is Not an Option
These following measures come straight from PHP’s official advisory to reduce exposure of a server. They are a short-term stopgap, not a substitute for patching.
Apply them in php.ini, the FPM pool or server config, never via ini_set() or .user.ini, and restart every worker.
CVE-2026-109618 (out-of-memory corruption):
- Set
memory_limit=-1usingphp_admin_valueso applications cannot override it, and confirm no pool or directory reintroduces a finite limit. - Lower
post_max_size: 8M if you don’t accept uploads, 32M if you do, withupload_max_filesizebelow it. Also cap request size, field count, multipart parts and headers at the web server or proxy. - Use a container or cgroup memory limit that kills only the affected worker. Do not use
RLIMIT_ASorRLIMIT_DATA, as they can trigger the vulnerable path.
CVE-2026-109619 (stale global state):
- Set
session.upload_progress.enabled=0. This blocks the most actively attacked path. - On PHP 8.5, set
fatal_error_backtraces=0. - Remove invalid or deprecated per-request settings that emit diagnostics early. Hiding errors with
display_errorsor@does not help. - Fix fatal errors and timeouts that attackers can trigger, including in upload, import and cleanup code.
Need help with PHP2Shell? Contact NetShop ISP
In the past 24 hours we have helped hundreds of customers patch their servers which include a variety of operating systems and control panels.
If you are a NetShop ISP Managed SLA customer, contact our support team to schedule the update. All PHP2Shell patching requests are handled with high priority. If you manage your own dedicated server or VPS and need help patching, upgrading from end-of-life PHP or checking for compromise, our engineers are available to assist.
Want on-going protection? Contact us today for a free PHP version audit.
