On October 21, 2026, the PHP project released emergency security updates addressing two critical vulnerabilities now commonly referred to as PHP2Shell:
- CVE-2026-109618
- CVE-2026-109619
Both vulnerabilities can potentially allow an unauthenticated remote attacker to execute code on a vulnerable server.
Because PHP powers a significant portion of websites and web applications worldwide, the vulnerabilities have potentially broad impact. Administrators of Internet-facing PHP systems should treat this as a high-priority security update.
The PHP project strongly recommends updating immediately and states that there is currently no complete configuration-based mitigation that can replace installing the security fixes.
What is PHP2Shell?
PHP2Shell is the informal name being used for two vulnerabilities discovered in PHP’s core request-processing functionality.
Unlike vulnerabilities in WordPress, Joomla, Laravel, Drupal or another PHP-based application, these issues exist in PHP itself.
This distinction is important.
A website does not necessarily need to run a vulnerable plugin, theme or CMS component to be exposed. The affected code can be reached while PHP processes incoming web requests.
The two vulnerabilities affect different parts of PHP’s request lifecycle.
CVE-2026-109618 — Remote Code Execution via Out-of-Memory Corruption
CVE-2026-109618 relates to the way PHP handles certain out-of-memory conditions during request processing.
Under specific circumstances, PHP can encounter an allocation failure while internal request data is only partially initialized.
During request cleanup, PHP may subsequently treat invalid or incomplete data as though it were valid.
Successful exploitation can result in memory corruption and ultimately remote code execution.
CVE-2026-109619 — Remote Code Execution via Stale Request State
CVE-2026-109619 involves internal state associated with a request surviving after the memory backing that state has already been released.
A later request handled by the same PHP worker can potentially interact with this stale state before normal initialization replaces it.
Under exploitable conditions, this can also lead to remote code execution.
The issue is particularly important in persistent PHP execution environments where workers process multiple requests over their lifetime.
Who is affected?
According to the PHP project, all PHP installations serving web requests should be considered at risk until patched.
This includes common deployment models such as:
- PHP-FPM
- Apache with mod_php
- php-cgi
- LiteSpeed
- FrankenPHP
The PHP security team has specifically identified Apache mod_php as presenting particularly high risk, with a demonstrated attack path where an unauthenticated request can trigger exploitation before normal application code begins executing.
This means that security controls implemented only inside a PHP application should not be considered sufficient protection.
Which PHP versions contain the fixes?
The PHP project released the following patched versions on October 21, 2026:
| PHP branch | Patched version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Administrators running one of these supported PHP branches should update to the listed version or a later vendor-supplied version containing the same security fixes.
What about PHP 8.1, 8.0, 7.4 and older?
PHP 8.1 and older versions no longer receive normal security releases directly from the PHP project.
However, because of the severity of PHP2Shell, the PHP security team has published minimal source backports for:
- PHP 8.1
- PHP 8.0
- PHP 7.4
Linux distributions, commercial LTS providers and hosting platform vendors may additionally provide their own backported security packages.
For this reason, the version number displayed by php -v does not always provide enough information to determine whether a distribution-maintained PHP installation is vulnerable.
Administrators using older PHP releases should check their operating system, control panel or LTS vendor security advisory rather than relying solely on the upstream PHP version number.
Where possible, we strongly recommend planning migration away from end-of-life PHP versions.
cPanel & WHM environments
cPanel has also issued a security notification relating to PHP2Shell.
It is important to note that these vulnerabilities are in PHP and not in the cPanel & WHM application code itself.
However, cPanel & WHM installations can include or use affected PHP packages, making these systems relevant to the vulnerability.
cPanel identified affected builds in the following release branches at the time of its notification:
- cPanel & WHM 110
- cPanel & WHM 134
- cPanel & WHM 136
- cPanel & WHM 138
cPanel is distributing updated PHP packages through its normal cPanel & WHM and EasyApache update channels.
Administrators running cPanel servers should therefore:
- Ensure cPanel and EasyApache updates are not disabled.
- Review any pinned package or version configurations.
- Verify all installed PHP versions, not only the system-default PHP interpreter.
- Pay particular attention to legacy PHP versions provided through additional repositories or PHP selectors.
- Verify package versions again after updates have completed.
Multi-PHP environments require extra attention
Hosting servers frequently contain several PHP versions at the same time.
For example, checking:
php -v
may only show the command-line system PHP version.
Individual websites may still run a completely different PHP runtime through:
- cPanel MultiPHP
- EasyApache PHP packages
- CloudLinux PHP Selector
- ALT-PHP
- custom PHP-FPM pools
- containerized PHP installations
- manually compiled PHP versions
Administrators should therefore inventory every PHP runtime actually serving web traffic.
Updating one PHP installation does not automatically prove that every website on the server has been protected.
Is WordPress specifically vulnerable?
PHP2Shell is not a WordPress vulnerability.
WordPress is relevant simply because it runs on PHP.
The same applies to other PHP applications, including:
- WooCommerce
- Drupal
- Joomla
- Magento / Adobe Commerce
- Laravel
- Symfony
- WHMCS
- custom PHP applications
Updating WordPress, plugins or themes does not fix PHP2Shell.
The vulnerable PHP runtime itself must be patched.
Application updates should of course continue to be maintained as a separate part of normal security practice.
Does an attacker need to authenticate?
The vulnerabilities are classified as unauthenticated remote code execution vulnerabilities.
This means exploitation may occur without a valid customer account, CMS administrator account or other application-level authentication.
The exact exploitability of an individual environment depends on its PHP configuration, SAPI, surrounding infrastructure and other technical factors.
However, Internet-facing administrators should not attempt to determine whether their particular application is “probably safe” before deciding whether to patch.
The appropriate response is to install the security update.
Are exploits publicly available?
Information about PHP2Shell became public ahead of the originally coordinated disclosure schedule.
Proof-of-concept material began circulating before the official PHP security releases became available.
The Netherlands National Cyber Security Centre (NCSC-NL) established a dedicated PHP2Shell information repository and warned organisations to prioritize Internet-facing PHP installations.
This significantly reduces the time administrators can reasonably expect between vulnerability disclosure and widespread exploitation attempts.
For critical Internet-facing software, the safest assumption is therefore that scanning and exploitation attempts may occur quickly after publication.
Has active exploitation been confirmed?
During the disclosure period, NCSC-NL stated that it had not yet seen confirmed evidence of active exploitation while also considering large-scale exploitation likely in the short term.
Because public proof-of-concept information is available, organisations should not use the absence of known exploitation as a reason to delay patching.
The distinction is important:
“No confirmed compromise” does not mean “not vulnerable.”
Can a WAF protect against PHP2Shell?
A Web Application Firewall can provide useful defence in depth, but it should not be treated as a replacement for patching PHP.
Rules limiting unusual multipart requests, oversized request bodies or known exploit patterns may reduce exposure to individual exploitation techniques.
However, PHP’s own security guidance explicitly states that the currently known mitigations do not provide a complete solution.
Similarly, Cloudflare, ModSecurity or another WAF should not be used as justification for postponing an available PHP security update.
Temporary mitigation when immediate patching is impossible
The PHP project has published several temporary risk-reduction measures.
These should only be considered temporary controls while preparing the actual update.
CVE-2026-109618
PHP recommends reviewing the PHP memory limit and request-size configuration.
One temporary measure is setting:
memory_limit = -1
preferably at an administrative configuration level that an individual PHP application cannot override.
PHP also recommends restricting request sizes.
For applications that do not require substantial file uploads, a relatively low post_max_size can reduce exposure.
Administrators should also enforce suitable limits at the web server or reverse proxy layer where possible.
These measures reduce particular exploitation paths but do not completely remove the vulnerability.
CVE-2026-109619
One recommended temporary mitigation is:
session.upload_progress.enabled = 0
After changing this setting, all affected PHP workers must be restarted.
The setting needs to be applied before PHP begins parsing the incoming request. Changing the value dynamically from application code is therefore not sufficient.
For PHP 8.5, the PHP project additionally recommends temporarily setting:
fatal_error_backtraces = 0
and restarting workers.
Again, these measures only block currently confirmed attack paths.
They do not make an otherwise vulnerable PHP installation equivalent to a patched system.
Why restarting PHP workers matters
Some mitigations and package updates require running PHP processes to be replaced before they become effective.
Depending on the environment, this can mean restarting:
- PHP-FPM pools
- Apache
- LiteSpeed
- relevant containers
- other persistent PHP workers
Simply updating files on disk does not necessarily mean existing processes are immediately executing the patched code.
Administrators should verify that services were restarted successfully after package installation.
Don’t forget containers and appliances
PHP may exist in places that are not immediately obvious.
NCSC-NL specifically warns administrators to separately review:
- container images
- appliances
- network devices
- management interfaces
- vendor applications
- embedded PHP runtimes
Updating PHP installed on the host operating system does not update PHP inside an existing Docker image or third-party software package.
For containers, administrators should check whether an updated base image has been published, rebuild affected images and redeploy running containers.
For third-party appliances and commercial software, follow the vendor’s security advisory and install the vendor-supported update rather than replacing embedded PHP manually unless specifically instructed to do so.
What should server administrators do now?
We recommend the following response plan.
1. Inventory every PHP installation
Identify all servers, containers and applications running PHP.
Prioritize systems directly reachable from the Internet.
2. Identify the PHP SAPI
Determine whether applications use:
- PHP-FPM
- mod_php
- CGI
- LiteSpeed
- FrankenPHP
- another PHP execution model
mod_php environments deserve particularly urgent attention based on the PHP project’s advisory.
3. Install vendor security updates
For upstream PHP installations, update to:
- PHP 8.5.12 or newer
- PHP 8.4.27 or newer
- PHP 8.3.36 or newer
- PHP 8.2.35 or newer
For distribution or control-panel packages, use the security packages supplied by your vendor.
4. Restart PHP-serving processes
Make sure patched binaries are actually loaded by restarting the appropriate services or containers.
5. Verify every installed PHP version
Do not assume that updating the default command-line PHP version updated all web-hosting PHP versions.
This is especially important on shared hosting and cPanel environments.
6. Review end-of-life PHP installations
Identify websites that continue to depend on PHP 8.1, PHP 8.0, PHP 7.x or PHP 5.x.
Check whether your vendor provides a maintained security backport.
Where a maintained security package is unavailable, migrate the application to a supported PHP release as soon as possible.
7. Review logs and security monitoring
Administrators should review recent HTTP, WAF, PHP, process and endpoint-security logs for unusual activity.
Particular attention should be paid to:
- unexpected processes created by PHP or web-server users
- unexplained outbound network connections
- unexpected files created inside website directories
- modified application files
- suspicious multipart POST traffic
- unusual PHP worker crashes
- unexpected privilege or persistence mechanisms
Finding one of these indicators does not by itself confirm PHP2Shell exploitation, but unexpected behaviour should be investigated.
8. Don’t rely on version banners alone
HTTP response headers such as X-Powered-By can be hidden, inaccurate or irrelevant when a distribution has backported a security patch without changing the upstream-looking version in the expected way.
The authoritative source should be the installed package status and the security advisory from the vendor maintaining that package.
What should AltusHost customers do?
The required action depends on the type of service you use.
Shared Hosting customers
Platform-level PHP and web-server package maintenance is handled at the hosting infrastructure level.
Customers do not need to modify the underlying operating system themselves.
We nevertheless recommend keeping websites, CMS installations, plugins, themes and other application components fully updated as part of normal security practice.
Managed VPS and Managed Dedicated Server customers
If PHP and the operating system are included within your management scope, relevant security updates should be handled according to the management service associated with your server.
If you are unsure whether a particular application or custom PHP installation falls within that scope, please contact our support team.
Unmanaged VPS and Dedicated Server customers
Customers operating unmanaged servers are responsible for maintaining their own operating systems, PHP packages and applications.
If your server processes Internet-facing PHP requests, we strongly recommend reviewing it immediately and installing the appropriate PHP or operating-system vendor security update.
Do not assume that your server is safe simply because you are not running WordPress or another well-known CMS.
The vulnerability exists in PHP itself.
How can I check my PHP version?
If you have shell access, you can usually check the default command-line PHP version with:
php -v
However, this only verifies the PHP interpreter selected for that shell environment.
On servers containing multiple PHP versions, you should inspect the PHP version configured for each website or PHP-FPM pool.
If you are using cPanel, check the PHP version assigned through MultiPHP Manager and review installed EasyApache PHP packages.
If you use CloudLinux PHP Selector or another multi-version PHP platform, those PHP installations must be checked separately as well.
Do I need to change my website code?
Normally, no application-code change is required specifically to resolve PHP2Shell.
The primary remediation is to update the PHP runtime or install the security package supplied by the vendor maintaining your PHP installation.
Applications depending on very old PHP versions may require compatibility changes before they can be migrated to a currently supported PHP branch.
This incident is another strong reason to avoid allowing applications to remain indefinitely on end-of-life PHP releases.
PHP 8.2 users should plan another upgrade
Although PHP 8.2.35 contains fixes for PHP2Shell, PHP 8.2 itself reaches end of life on December 31, 2026.
Systems currently using PHP 8.2 should therefore install PHP 8.2.35 immediately for this vulnerability while also planning migration to a newer supported PHP branch.
Security is a layered process
Patching PHP is the immediate priority.
However, organisations should also maintain defence-in-depth controls such as:
- application and server isolation
- least-privilege permissions
- separate PHP-FPM pools where appropriate
- filesystem isolation
- properly configured WAF protection
- outbound network restrictions where practical
- security monitoring
- timely operating system updates
- regular application patching
- backups and tested recovery procedures
These controls can reduce the impact of an application or runtime compromise, but they are not replacements for applying the PHP2Shell security update.
Final recommendation
If you operate an Internet-facing PHP environment, do not postpone this update.
PHP2Shell affects the PHP runtime itself and may allow an unauthenticated attacker to execute code before an application’s own security controls can meaningfully intervene.
The preferred remediation is straightforward:
Update PHP or install your vendor’s PHP2Shell security package, restart the affected services and verify that every PHP runtime serving web traffic has been updated.
Temporary mitigations can reduce exposure while updates are being deployed, but the PHP project is explicit that they are not a complete solution.
AltusHost customers who are uncertain whether their server requires action are encouraged to contact our support team.
Need Help?
If you are unsure whether your server, website, or PHP environment is affected by PHP2Shell, please contact the AltusHost Support Team.
We can help you identify the PHP versions currently in use, verify whether relevant security updates are available, and advise you on the appropriate next steps for your hosting environment.
Shared Hosting customers: no operating-system-level action is required on your side, as AltusHost manages the underlying PHP platform.
VPS and Dedicated Server customers: if you manage your own operating system or PHP installation, we strongly recommend reviewing and updating your environment as soon as possible.
If you have any questions or need assistance, please open a support ticket through the AltusHost Client Area.