Built For Designers & Developers

PHP security update

A security vulnerability known as PHP2Shell was recently reported in PHP. PHP2Shell is the name for two critical vulnerabilities recently reported in PHP, the software that powers many websites. They are recorded in the Common Vulnerabilities and Exposures (CVE) system as CVE-2026-109618 and CVE-2026-109619.

To help protect your website, we’ve implemented temporary security protections while we deploy patches across affected servers. These protections may affect certain website functions, including uploads, imports, migrations, backups, and large form submissions.

If you experience other service issues, please contact support for assistance.

Stay informed

Security updates for PHP have been released. Our team is working to verify and apply them as quickly as possible. We’ll keep monitoring the situation and share updates as soon as they’re available.

Note: If you have a WordPress website, we recommend updating WordPress to the latest version and making sure all your installed plugins are up to date. Outdated versions can leave your site more exposed to security issues.

In this article, we’ll explain the symptoms you may experience and recommend workarounds for the following issues:

• Large uploads, imports, or forms are failing
• Upload progress bars appear stuck
• All uploads return a 403 error
• Only one plugin or tool is affected in WordPress

If you manage your own Virtual Private Server (VPS), we’ll also show you how to check whether it’s patched and how to update PHP:

• How to check if your server is patched
• How to find the PHP version your websites use
• How to update PHP on self-managed VPS servers

Large uploads, imports, or forms are failing

You may experience issues such as:

• Media uploads failing
• Plugin or theme installation failures
• Backup restoration failures
• Website migration failures
• CSV or database import failures
• “Link Expired” or “419 Page Expired” errors
• Forms failing to submit or save correctly

Likely cause

The request exceeds temporary upload or request-size limits introduced as part of our security mitigation.

Recommended workarounds

• Use SFTP or File Manager to upload files
• Use File Manager to transfer backup and migration files
• Compress large files before transferring them
• Split large imports into smaller files, where supported
• Refresh the upload page to check whether the upload completed

Upload progress bars appear stuck

You may experience issues such as:

• An upload remains at zero percent
• The progress bar does not advance

Likely cause

Upload progress tracking has been temporarily disabled as part of our security protections.

Recommended workaround

Use SFTP or File Manager to transfer your files.

All uploads return a 403 error

You may experience issues such as:

• Every upload fails with a 403 error
• Media uploads fail regardless of file size

Likely cause

A temporary server security rule is preventing uploads.

Recommended workaround

Use SFTP or File Manager to transfer files until the restrictions are lifted.

Only one plugin or tool is affected in WordPress

You may experience issues such as:

• Uploads fail within a specific plugin or application
• Certain functionality returns a 403 error while other uploads work normally

Likely cause

A security rule may be blocking that specific request pattern.

Recommended workaround

• Use SFTP for large file uploads
• Use File Manager for backups and migrations
• Compress large files before uploading
• Split large imports into multiple smaller uploads
• Refresh the upload page to check whether the upload completed

How to check if your server is patched

These sections are for customers who manage their own VPS. Where the steps differ, we show them for cPanel and Web Host Manager (WHM), Plesk, and common Linux setups.

The PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) are fixed in the PHP versions below. Compare your version with the table to see if you’re patched.

To find the version your websites run, follow the steps in How to find the PHP version your websites use.

Check every PHP version on cPanel/WHM servers

Run this as root to check every installed PHP version at once:

for b in /opt/alt/php[0-9]*/usr/bin/php /opt/cpanel/ea-php*/root/usr/bin/php; do
  [ -e "$b" ] || continue
  p=$(rpm -qf "$b")
  if rpm -q --changelog "$p" | grep -q 'CVE-2026-109618'; then
    echo "$p: FIXED"
  else
    echo "$p: NOT FIXED"
  fi
done

If a package you have updated still shows NOT FIXED, the vendor may have left the CVE out of its changelog. Contact support to confirm.

Confirm PHP restarted after the update

Run this as root. It should print nothing:

grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

If it prints anything, PHP is still running the old code. Contact support, and we’ll restart the services for you.

How to find the PHP version your websites use

Check the PHP your websites run, not just the PHP installed on the server. The two can be different.

Note: Don’t rely on running php -v over Secure Shell (SSH). The command-line PHP often differs from the PHP that serves your websites.

cPanel

1. Log in to cPanel
2. Go to Software > MultiPHP Manager
3. Find your domain in the list and check the PHP version shown next to it

MultiPHP Manager shows the PHP series, such as 8.3, rather than the full version number. To compare your version against the patched versions, use the phpinfo steps below.

Plesk

1. Log in to Plesk
2. Go to Tools & Settings > PHP Settings
3. Check the full version number shown for each PHP version

Any server type: create a phpinfo file

1. Create a file called check.php in your website’s main folder with this content:
   <?php phpinfo(INFO_GENERAL);
2. Open https://yourdomain.com/check.php in a browser, replacing yourdomain.com with your own domain
3. Compare the PHP Version and Build Date with the table in How to check if your server is patched
4. Delete the file afterward, since it shows details about your server

How to update PHP on self-managed VPS servers

Updating PHP takes three steps: update it, restart it, and verify the update worked.

Step 1: Update PHP

Run the commands for your setup.

cPanel/WHM

/scripts/upcp
dnf upgrade 'ea-php*' 'alt-php*'

On CentOS 7 and CloudLinux 7, use yum instead of dnf. cPanel ships backported fixes for ea-php74, ea-php80, and ea-php81.

Plesk

Go to Tools & Settings > Updates, or run:

plesk installer update

Ubuntu and Debian (operating system packages)

apt update && apt upgrade

Ubuntu and Debian keep the original version number when they backport a fix. Confirm the fix with:

zgrep CVE-2026-109618 /usr/share/doc/php*-common/changelog.Debian.gz

AlmaLinux, Rocky Linux, and Red Hat Enterprise Linux (RHEL)

dnf upgrade 'php*'
rpm -q --changelog php-common | grep CVE-2026-109618

If you use the Remi repository, check that Remi has published the fixed versions before you rely on it.

Step 2: Restart PHP

PHP keeps running the old code until you restart it. Use the commands for your setup.

cPanel/WHM

/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd --stop && /scripts/restartsrv_httpd --start

Plesk

systemctl restart 'plesk-php*-fpm'

Other servers with PHP FastCGI Process Manager (PHP-FPM)

systemctl restart 'php*-fpm'

Apache with mod_php

A reload or graceful restart keeps the old PHP loaded. Stop Apache fully, then start it (use apache2 in place of httpd on Ubuntu and Debian):

systemctl stop httpd && systemctl start httpd

LiteSpeed and OpenLiteSpeed

systemctl restart lsws

Confirm the restart worked

Run this as root. It should print nothing:

grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

Step 3: Verify from the web

Command-line checks can show a different PHP from the one your websites use. Follow the phpinfo steps in How to find the PHP version your websites use and confirm the PHP Version matches the table in How to check if your server is patched. For 8.1, 8.0, and 7.4, the Build Date should be October 21, 2026, or later.

If you cannot update right away

Add these to php.ini or your PHP-FPM pool configuration. Settings in .user.ini have no effect here.

session.upload_progress.enabled = 0
post_max_size = 32M          ; 8M if your sites accept no uploads
upload_max_filesize = 30M

On PHP 8.5, also add fatal_error_backtraces = 0. Limit request body size at the web server too (LimitRequestBody on Apache and client_max_body_size on Nginx). Restart PHP after any change.