Two critical security vulnerabilities in PHP, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), can allow an attacker to run malicious code on an affected server without logging in.

PHP powers websites and applications such as WordPress, Moodle and Joomla, as well as parts of hosting panels such as cPanel and Plesk. Updating your website's plugins or application alone does not update the underlying PHP software.

For a plain-language explanation, see Malwarebytes:
https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates

If your VM serves PHP websites, please check for the security updates now. Install the patched packages and restart the processes running PHP. Please do not wait for our checking tool.

We are developing a tool to help customers identify their installed PHP packages and assess whether the PHP processes serving their websites need updating or restarting. Where supported, it may also offer a package update. The tool's capabilities and supported configurations are still being worked out. Please subscribe to this notice for updates.

The PHP project released fixes in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Linux distributions may instead apply the fixes to an older PHP version while keeping its existing version number. Check the complete package version against your distribution's security advisory.

PHP's security advisory:
https://www.php.net/archive/2026.php#2026-10-21-5

A build date of 21 October 2026 or later is not proof that PHP is patched. Also, php -v reports the command-line PHP installation, which may differ from the PHP version used by your websites.

For example, Ubuntu 24.04's fixed package is 8.3.6-0ubuntu0.24.04.13, despite its PHP version number being below 8.3.36. Ubuntu's package versions and update guidance:
https://ubuntu.com/blog/php2shell-vulnerability-fixes-available

If a patched package is unavailable, consider temporarily removing public access to affected PHP applications. A WordPress maintenance plugin or login page is insufficient: some attack paths run before the application's own code.

Updating your server yourself

These instructions are a starting point for servers using maintained package repositories. Servers with old operating systems, hosting panels, custom PHP builds or containers may need a different approach.

Before updating, check that you have a current backup and access to your VM's console. Package updates and restarts can briefly interrupt websites and other services. Run the commands over SSH. If you are already logged in as root, omit sudo.

1. Identify your operating system and PHP packages

These commands display operating-system information and the command-line PHP version:

cat /etc/*release /etc/debian_version 2>/dev/null
php -v

On Debian or Ubuntu, list matching packages:

dpkg-query -W -f='${Package} ${Version}\n' 'php*' 'libapache2-mod-php*'

On AlmaLinux, Rocky Linux, RHEL or CentOS:

rpm -qa '*php*'

If php -v reports "command not found", that does not establish that your websites do not use PHP. Hosting panels and custom installations may store their own PHP binaries elsewhere.

2. Install available updates

On Debian or Ubuntu, refresh the package information and preview the updates:

sudo apt-get update && sudo apt-get -s upgrade

If refreshing the package information reports repository or signature errors, resolve those before continuing. Review the proposed changes, then install the updates:

sudo apt-get upgrade

Check whether any PHP packages were held back. If they were, the update may be incomplete. dist-upgrade can resolve additional dependencies, but it can also remove packages, so review its proposed changes before using it.

On AlmaLinux, Rocky Linux or RHEL using DNF:

sudo dnf --refresh upgrade

On an installation using YUM:

sudo yum clean all
sudo yum update

Review the package transaction before confirming it. These commands update packages from your configured repositories; they do not guarantee that those repositories contain the PHP2Shell fixes.

"No updates available" is not confirmation that your server is safe. The fix may not yet be published for your distribution, your PHP stream may no longer receive updates, or PHP may come from another provider.

AlmaLinux's response, for example, distinguishes supported and retired PHP streams:
https://almalinux.org/ko/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/

If you use cPanel, Plesk or another hosting panel, follow that vendor's PHP update procedure too. Updating the operating system's default PHP package may leave the versions serving your websites unchanged.

3. Restart the processes using PHP

Package updates sometimes restart services automatically. Do not assume that happened successfully.

Once patched packages are installed, rebooting the VM is a straightforward way to replace running processes:

sudo reboot

This interrupts all services on the VM. Confirm it returns and your websites work.

Alternatively, restart the relevant services individually. On Debian/Ubuntu, for example, if you use PHP 8.3 FPM:

sudo systemctl restart php8.3-fpm

Replace 8.3 with your installed version. On RPM distributions, the service is commonly:

sudo systemctl restart php-fpm

These are examples: use your actual service names. Very old systems may use service or /etc/init.d/ instead of systemctl.

If Apache runs PHP directly through mod_php, restart Apache instead: its service is commonly called apache2 on Debian/Ubuntu or httpd on RPM distributions.

Restart every PHP version serving websites, plus long-running PHP workers. Restarting nginx alone does not restart PHP-FPM. Containers need their own updated images and replacement processes.

4. Check the result

Run the package-listing commands again and compare the installed revisions with the advisory for your package provider. Visit your websites and check that important functions still work.

On Linux, this command can help identify PHP and web-server processes and their start times:

ps -eo pid,lstart,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd|[n]ginx'

A recent process start time helps confirm a restart; it does not prove that the process loaded patched software.

Older servers or unavailable updates

Older servers may need migration to a maintained operating system, an extended-support service, or a carefully planned PHP upgrade. Some older Ubuntu releases have fixes through Ubuntu Pro/ESM, where that coverage is enabled.

We are investigating options for older installations, including third-party repositories such as Sury. Please do not add repositories or switch PHP versions blindly: compatibility and available fixes depend on the operating-system release and application.

If you cannot obtain a confirmed fix, remove public access to the affected PHP applications while arranging an update.

If you would like RimuHosting to assist you migrating your server to a currently supported distro - which may require a reinstall and migration - please reach out to us.  We can assist with these as time permits.  The process is described at https://rimuhosting.com/knowledgebase/rimuhosting/migration

The Dallas site team are replacing batteries in several UPS units. No service impact is expected

Schedule:
Day 1 - Monday, November 2, 2026
Day 2 - Tuesday, November 3, 2026
Day 3 - Wednesday, November 4, 2026
Day 4 - Thursday, November 5, 2026
Day 5 - Friday, November 6, 2026

Detail: The multi-day replacement of batteries followed by the verification of proper operation and functionality of the critical battery and Uninterruptible Power Supply (UPS) infrastructure. The actions involved are fully documented and may include the use of external vendors.

The Dallas site will be switchingload from utility to generator during the following window. No service impact is expected.

Maintenance Start: 10/28/2026 08:30 US/Eastern
Maintenance End: 10/28/2026 16:00 US/Eastern

In detail: This is to reduce the electrical load on the local or regional power grid, at the request of the upstream utility company. This process includes transferring the facility to generator for the duration of the requested timeframe. Upon notification, the facility will be returned to utility power as its primary source of power. The actions involved are fully documented.