Update PHP Immediately to Fix PHP2Shell, Among the Most Severe Vulnerabilities

On October 21, 2026, PHP released emergency fixes for two critical vulnerabilities in PHP. Attackers can exploit an affected installation without logging in to run code with the permissions of the account that runs PHP. They can also steal passwords, tokens and other sensitive data from memory without first executing malicious code. Any website still running an affected PHP build is at risk, whatever application it uses.

Does this affect my website?

If your website runs on an affected PHP version, yes. WordPress, Drupal, Joomla, Magento, PrestaShop and Laravel all use PHP. The affected environments include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

The vulnerable code is in PHP itself, so secure application code does not remove the risk—even a simple "Hello World" page can be affected. WordPress automatic updates do not fix these vulnerabilities because they do not update the PHP software running on your server.

What can an attacker do to my server?

An attacker can run code without logging in, with the permissions of the account running your PHP web processes. Full remote code execution was demonstrated against Apache with mod_php using default PHP input and memory limits, including a setup with multiple workers.

An attacker can also read sensitive data from PHP's memory, including passwords, authentication tokens, API keys and certificates from other requests or the server itself. That theft can happen without running malicious code, making it harder for tools focused on code execution to detect. The attack described by Wiz works even when the application never calls session_start().

What is the one thing I must do?

Install a fixed PHP build wherever PHP runs your site, then restart the services and long-running workers that use it. That is the only complete fix.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your PHP comes from a Linux distribution or a long-term support vendor, use its updated package. Updating your website application alone does not update PHP underneath it.

My site is on shared hosting, cPanel or Plesk. What do I do?

Contact your hosting provider and ask for written confirmation that the fixes for CVE-2026-109618 and CVE-2026-109619 have been applied to the PHP version running your website. The release of a patch does not establish that your particular server has received it.

In its 21 October announcement, cPanel said the fixes were being delivered through its security update system, without a separate manual action. It also listed backports for PHP 7.4.33, 8.0.30 and 8.1.34. An administrator could trigger an update with /scripts/upcp or yum update.

CloudLinux had a separate rollout: its announcement listed alt-php fixes for 7.4 and 8.0 on most platforms and 8.1 on some, with other alt-php branches still in testing and ea-php packages to follow. Plesk's Linux fixes covered PHP 8.2–8.5; its fixes for 7.4.33, 8.0.30 and 8.1.34 retained the same version numbers but used builds dated 21 October 2026. These differences are why confirmation from your host matters.

I run my own server or cloud instance. What exactly do I need?

First identify where your PHP comes from: your Linux distribution, a third-party repository, Docker or FrankenPHP. Once that source provides a fixed build, install it, restart every process that runs PHP and check that none is still running the old build. The commands depend on that environment.

For Apache with mod_php, use sudo systemctl restart apache2 on Debian or Ubuntu, or sudo systemctl restart httpd on RHEL. A reload or apachectl graceful is not enough. For LiteSpeed or OpenLiteSpeed, update the lsphpXY packages from LiteSpeed's repository, then run sudo pkill lsphp. For Docker, pull the new PHP image, rebuild your own images with docker build --pull and recreate the containers.

The PHP announcement made a specific exception for rpms.remirepo.net: it said updates would not be available there on 21 October and urged users to switch to distribution packages or build from source so they could apply the fix immediately. After updating, undo temporary mitigations that are no longer needed, as described below.

How do I check that the fix is really installed?

Check the installed package and your vendor's security notice, rather than relying on the PHP version string alone. A vendor can put the fix into an older PHP release without changing its main version number. Ubuntu 24.04, for example, can still show PHP 8.3.6 after receiving a patched package.

In WordPress, open Tools > Site Health > Info > Server to see the PHP information. In Plesk, open Tools & Settings > PHP Settings; the versions should appear in the handler names. On a cPanel server, an administrator can inspect the packages with rpm -qa | grep ea-php##, replacing ## with the PHP branch in use.

Those checks provide the version or package details to confirm with your host or the vendor's security notice. php -v alone cannot establish whether a backported fix is installed.

I am on PHP 8.1 or older. Do I need developers to rebuild the site before I can be safe?

Not necessarily. If your vendor provides a patched build for the PHP version you already run, you can address these vulnerabilities without first rebuilding the website. Getting that fixed PHP build installed is the immediate priority.

PHP 8.1 and older no longer receive regular updates from the PHP project, but some distributions and long-term support vendors provide backported fixes. The PHP security team also released minimal source backports for PHP 7.4, 8.0 and 8.1 for people building from source. If you cannot obtain a fixed build for your existing branch, the other route is to move to a supported PHP version.

A backport fixes this issue; it does not restore ongoing support for an old branch. The patch guide recommends installing the available fix first, then moving to PHP 8.4 or 8.5. PrestaShop separately advises against rushing a major PrestaShop upgrade as an emergency response: updating the shop software is not the fix for these PHP vulnerabilities.

Will the update itself break my site?

The recommended approach is to install the fixed release within the PHP branch your application already supports—for example, moving from PHP 8.3.x to 8.3.36. Mautic recommends this to avoid adding a branch upgrade to the security update.

The aaPanel guidance says extensions such as redis and imagick continue to work after a patch-level update within 8.3.x because the extension API stays the same. That is a specific compatibility statement, rather than a guarantee about every website.

Mautic recommends fresh backups of its database and files, plus a full, tested server backup so you can roll back if something goes wrong. The aaPanel advice is to update one server first, check a site and then repeat on the others.

I cannot update right now. What reduces the risk, and what does it break?

PHP's temporary measures reduce exposure to particular attack paths, but they do not make an installation safe. Only an update provides the complete fix.

For CVE-2026-109618, PHP advises setting memory_limit=-1, preferably through an administrative setting such as php_admin_value that the application cannot override, and lowering post_max_size to 8M without file uploads or 32M where uploads are needed. With the memory limit disabled, one request can consume all the server's memory, so memory use needs to be watched.

For the session-related path of CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration that takes effect before request parsing, then restart every worker. Do not rely on ini_set() or FPM .user.ini. On PHP 8.5, PHP also advises setting fatal_error_backtraces=0 and restarting every worker. Turning off upload progress does not cover both vulnerabilities.

If you also block multipart requests, file uploads can stop working, including product-image uploads. Some shops use multipart for cart or checkout forms too. Sansec advises placing a test order after adding that rule.

Should I just take the site offline?

If you cannot patch promptly, taking the public-facing PHP service offline is one of the recommendations in the advisories. php.watch qualifies this with "if possible"; CERT-EU recommends considering isolation from public networks until the fix has been applied and verified. PHP developer Gina Peter Banyard also acknowledged that a shutdown can be sensible without being practical for everyone.

Restricting access through a VPN, an allowlist or authentication at the edge is another option described in the material. For a maintenance page, Sansec advises stopping PHP-FPM and serving a static page from the web server. The maintenance modes inside WordPress or Magento do not provide that protection because PHP processes the request before the application checks its maintenance setting.

If going offline is not possible, Sansec describes allowing only GET and HEAD requests at the web server. Visitors can still browse the catalogue, but they cannot log in or place orders. This is a restricted browsing mode, not a complete fix. For PHP 8.1 or older with no vendor fix, the patch guide says to keep the early mitigations, move to a supported version as quickly as possible and keep the site offline in the meantime.

How would an attacker find my site, and does hiding the PHP version help?

An attacker can look for PHP websites by scanning the internet rather than choosing each target individually. Hiding the version does not stop PHP from being identified: VirusTotal describes recognising it through applications such as WordPress, Laravel and Nextcloud, PHPSESSID cookies and framework-specific headers.

Its estimate was that roughly four out of five PHP servers hid their version, yet these other signals still exposed their use of PHP. Setting expose_php=Off removes the PHP version header; it does not remove the vulnerability. Hiding that header is optional hardening, not a substitute for installing the fix.

How do I know whether I was already attacked?

Look for evidence in web-server and PHP logs and in the processes PHP starts, but a lack of obvious signs does not rule out an attack.

The researchers list unusually large or malformed PHPSESSID cookies in responses, unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and unexplained PHP worker crashes or restarts. Huntress also highlights suspicious child processes started by PHP, such as shells, Python or Perl interpreters, and tools including curl, wget, nc or certutil.exe.

These are investigation signals, not a verdict on their own. Some attacks can steal data from memory without running malicious code, and application logs may contain little context because the vulnerable processing happens below the application layer.

What do I change after the patch is in?

If you temporarily set memory_limit=-1, restore a finite memory limit after installing the patch. Remove the temporary block on multipart requests so file uploads can work again.

You can leave session.upload_progress.enabled=0 in place unless your application uses that specific PHP feature to display upload progress. Setting expose_php=0 is also optional: it reduces version disclosure but does not fix PHP2Shell.

One support deadline still matters after patching: PHP 8.2 reaches end of life on 31 December 2026, after which the PHP project will stop providing security fixes for that branch.

1. PHP, security advisory
2. GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
3. GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
4. php2shell.com
5. Wiz Research
6. cPanel Community
7. Plesk
8. CloudLinux
9. AlmaLinux
10. Ubuntu
11. PrestaShop
12. CIRCL TR-102
13. Wordfence
14. Tenable
15. Huntress
16. Sansec
17. VirusTotal