PHP2Shell: how to check your server and fix the dangerous PHP Vulnerability

Two critical vulnerabilities have been discovered in PHP. They are known as PHP2Shell. These vulnerabilities allow an attacker to execute their own code on your server without needing a password.

The vulnerabilities were patched on October 21, 2026. Attacks are already underway. If your server hosts a PHP-based website, update PHP today. Below is a simple step-by-step guide that will take 10-15 minutes.

What Happened?

PHP works like a waiter in a restaurant. A customer (the browser) places an order. The waiter (PHP) takes it to the kitchen (the server) and brings back the result: the website page.

Now imagine two situations.

The first vulnerability (CVE-2026-109618). The waiter carries a tray that's too heavy and drops it halfway. Then, while cleaning up the broken dishes, they mistakenly treat the fragments as intact plates. PHP behaves similarly: when it runs out of memory, it can leave data in an incomplete state. An attacker can deliberately trigger this situation and inject their own code.

The second vulnerability (CVE-2026-109619). A customer leaves, but their belongings are still on the table. The waiter forgets to clear them away. The next customer sits down and may use those belongings. PHP can behave similarly: after one request, data from that request remains in memory. The next request may be able to read or use that data in an attack.

Both vulnerabilities have been assigned a severity score of 9.2 out of 10, indicating a very high level of risk.

Who Is Affected?

Anyone running a PHP-based website or service on their server. For example:
 

• WordPress, WooCommerce, Joomla, Drupal, OpenCart;

• 1C-Bitrix, Magento, Laravel;

• phpMyAdmin, Nextcloud, forums, custom-built websites;

• Control panels such as ISPmanager, cPanel, aaPanel, and HestiaCP.

All PHP versions from 5.4 through 8.5.11 are vulnerable. It doesn't matter how PHP is integrated with the web server: via PHP-FPM, Apache (mod_php), LiteSpeed, or another method. Websites running Apache with mod_php are at the highest risk.

If you're not sure whether your server uses PHP, chances are it does. PHP powers around 70% of websites on the internet.

How dangerous is it?

Very. Here's what we know so far:
 

• The first attack attempts were detected on October 17, four days before patches were released.

• After October 21, the number of attack attempts surged from tens of thousands to millions in a single day.

• The Mirai botnet has joined the attacks. It's a network of infected devices that automatically scans the internet for vulnerable servers.

The good news is that researchers report most publicly available exploits don't yet work against standard configurations. But that's no reason to wait.

Imagine you find out that the lock on your building's front door is broken. No burglars have entered yet. Would you wait until they do? It's the same here. Bots are already scanning servers across the internet. The only question is when they'll get to yours.

Check your PHP Version

Connect to your server via SSH and run the following command:

php -v

The output will contain a line similar to PHP 8.3.30 (cli). Compare your version with the table below.

Important: Your server may have multiple PHP versions installed. The php -v command only shows one of them, and your website may be running a different version. To see all running PHP versions, run:

systemctl list-units --type=service | grep php

If the version number hasn't changed after an update, that's not necessarily a bad sign. Ubuntu, Debian, AlmaLinux, and other distributions often backport security fixes to older versions. The version number stays the same, but the vulnerability is already patched. You can verify this by checking the package changelog.

For Ubuntu and Debian:

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php*-common/changelog.Debian.gz

For AlmaLinux, Rocky Linux, and CentOS Stream:

rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

If the command returns lines containing CVE IDs, the fix is installed. If the output is empty, proceed to Step 2.

Update PHP

Before updating, back up your website and database. If anything goes wrong, you can quickly restore everything.

Ubuntu и Debian

sudo apt update
sudo apt upgrade

After that, restart PHP. Replace 8.3 with your PHP version:

sudo systemctl restart php8.3-fpm

If your website runs on Apache, restart it as well:

sudo systemctl restart apache2

AlmaLinux, Rocky Linux, CentOS Stream

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd

Control Panels

• cPanel. PHP versions (the ea-php packages) are updated along with the system. Run the update through WHM or use the sudo yum update command.
• ISPmanager, aaPanel, HestiaCP, and others. Update PHP through the PHP versions section in the control panel or via system packages, as described above.
• Docker. Rebuild the image using an updated PHP version and restart the container.

Don't forget to restart the services.

This is the most common mistake. The new PHP version is installed, but the old one is still running in memory. It's like buying a new lock but leaving it in the box. The door is still secured with the old one. That's why you must restart PHP-FPM and the web server after updating.

After restarting, open your website and check that it's working properly.

Apply temporary mitigations

Everyone should take this step, even after updating. It also mitigates another vulnerability for which no patch is available yet (more on that below).

First, locate the PHP configuration file. Websites typically use the file in the following directory fpm:

ls /etc/php/*/fpm/php.ini

On AlmaLinux and Rocky Linux, the file is usually located here: /etc/php.ini.

Open the file and add the following line at the end:

session.upload_progress.enabled = 0

If you're using PHP 8.5, add one more line:

fatal_error_backtraces = 0

Save the file and restart PHP as described in Step 2.

How will this affect your website? Almost not at all. The only thing that will stop working is the upload progress bar for large files, if it's implemented using PHP. Most websites don't have one.

This is not a substitute for updating. Temporary protection is like a security chain on a door. It makes it harder for a burglar to get in, but it doesn't replace a proper lock. Update PHP first, then apply the configuration change.

If you're using PHP 8.1 or earlier

PHP versions 8.1, 8.0, 7.x, and 5.x are no longer supported by the PHP developers. No official patches will be released for them. There are still a huge number of such servers on the internet, accounting for around 70% of all PHP installations.

It's like owning a car for which the manufacturer no longer makes spare parts. You can still drive it, but every breakdown becomes a problem.

What you can do:

1. Check your system packages. Some builds have received security fixes. For example, Ondřej Surý's packages for Ubuntu and Debian (ppa:ondrej/php) and AlmaLinux packages. Update as described in Step 2, then check the changelog as described in Step 1.

2. Upgrade to a newer PHP version. This is the best long-term option, but an older website may not work with a newer PHP version. Test it before upgrading.

3. Purchase extended support. For example, TuxCare provides security patches for older PHP versions for a fee.

In any case, be sure to apply the temporary mitigation described in Step 3.

If your server runs CentOS 7, no PHP security patches will be available at all. This operating system has also reached end of life. It's best to migrate your website to AlmaLinux or Rocky Linux.

Two more developments that haven't received much attention

A third vulnerability remains unpatched. On October 23, PHP developers disclosed another flaw: CVE-2026-115560. It only affects websites with a rare configuration. No emergency patch will be released; the fix will be included in the next scheduled release. The mitigation is the same as in Step 3. If you've already added the session.upload_progress.enabled = 0 line, you're protected.

New versions have bugs of their own. Two memory-related issues have been discovered in versions 8.4.27 and 8.5.12. One of them was introduced in this very update. This is no reason to roll back to an older version: the older version poses a much greater risk. Just keep an eye on the latest security news. The next PHP update is likely to be released in the coming weeks, and you'll need to install that one too.

The bottom line is that a single update isn't enough. Keeping your server secure requires ongoing monitoring and maintenance.

Checklist:
 

• Checked the PHP version with php -v
• Checked whether other PHP versions are installed on the server
• Made a backup of the site and the database
• Updated PHP to a secure version
• Restarted PHP-FPM and the web server
• Added session.upload_progress.enabled = 0 to php.ini
• Verified that the site opens and works correctly
• Set a reminder to check for the next PHP update

Don't Want to Handle It Yourself?

Updating PHP is straightforward if you've done it before. But things don't always go smoothly. You update PHP, and your website shows a blank screen. Or your control panel lists three PHP versions, and you're not sure which one to change. Or your website is old, and you're worried about breaking it.

For situations like these, Zomro offers two options.

SOD: we'll take care of everything for you

You contact us, and our system administrator will:
 

Order PHP Update
 

Premium: fast support when you need it

A standard technical support request can take up to 10 hours to receive a response. If your website stops working after an update, that wait can be costly. With Premium, you'll receive a response from a specialist within 5-30 minutes.
 

Premium is for those who can't afford to lose money due to website downtime. New vulnerabilities, post-update errors, and other technical issues require a quick response. With Premium, you can count on prompt assistance from our specialists to restore your website faster and avoid wasting time troubleshooting the problem yourself.
 

Get Premium