How to patch PHP for CVE-2026-109618 and CVE-2026-109619

This page gives example steps for updating PHP on the server that hosts rConfig to a release that fixes CVE-2026-109618 and CVE-2026-109619 (known as PHP2Shell). It covers the rConfig Docker image, Ubuntu, CentOS / Rocky Linux and RHEL, and accompanies the rConfig Security Advisory rCFG-SA-2026-01.

Guidance only: confirm with your systems team

PHP is part of your server’s operating environment, which you manage. These are vulnerabilities in PHP, not in rConfig’s own code. The steps below are general guidance based on the advisory and on how rConfig’s install scripts set up PHP. Package names, versions and paths can differ on your servers, so confirm the exact steps with your systems team or OS vendor before applying them, and test in a non-production environment where possible.

When to use this

Use this page as a reference when you and your systems team update PHP on a server running rConfig Pro, Vector or Core. The PHP project says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php. The rConfig Docker image runs PHP as an Apache module (mod_php).

Prerequisites

• Root or sudo access to the rConfig server, or to the Docker host
• A current backup of the rConfig application directory and database. See backing up rConfig before an update
• A maintenance window agreed with your team. Apache, PHP-FPM and the Horizon queue workers restart during the update
• Your rConfig version, so you can match it to the PHP version it runs on in the advisory’s rConfig Pro and Core tables

Which PHP version fixes the vulnerabilities?

The PHP project released the fixed versions on 21 October 2026. Update to the fixed release for the PHP version you already run.

Your PHP version	First fixed release	Notes from the advisory
8.5.x	8.5.12	Replaces 8.5.11
8.4.x	8.4.27	Replaces 8.4.26
8.3.x	8.3.36	Replaces 8.3.35
8.2.x	8.2.35	Replaces 8.2.34. PHP 8.2 reaches end of life on 31 December 2026
8.1 or older	No update from the PHP project	Use a vendor backport, build from source with the PHP security team’s backport, or upgrade to a supported PHP version. Restrict access and contact prosupport@rconfig.com before changing PHP

Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. Third-party repositories can take longer. The advisory’s Availability of fixed PHP packages table shows the latest known status for Remi, ppa:ondrej/php and the rConfig Docker image.

Example steps: patch PHP

1. Restrict access to rConfig

If you have not already, restrict access to rConfig, ideally to a VPN or trusted management IP addresses. Do not expose the web interface directly to the internet. Keep the restriction in place until PHP is updated.

For firewall examples, see rConfig security hardening.

2. Check your current PHP version and how PHP is served

1. Check the PHP CLI version:

   php -v

2. Check whether Apache runs PHP as a module (mod_php):

   # Ubuntu
   apache2ctl -M 2>/dev/null | grep -i php
   # CentOS / Rocky / RHEL
   httpd -M 2>/dev/null | grep -i php

   A line such as php_module (shared) means mod_php.

3. Check whether PHP-FPM is running:

   systemctl list-units --type=service | grep -i fpm

Note the results. They tell you which services to restart and, if needed, which workaround applies.

3. Update PHP

Docker

rConfig V8 Pro Docker image

The rConfig image is built on the official php:8.4-apache-bookworm image. That base image was updated on Docker Hub on 21 October 2026, but the rConfig image has to be rebuilt on it. PHP in the image is compiled from source, so it cannot be patched with apt inside the container.

1. Check the advisory or contact prosupport@rconfig.com to confirm the updated rConfig image is available. Until it is, see what to do if the fix is not available yet.

2. Record the PHP version the container runs today, so you can compare it after the update:

   docker exec rconfig8docker-app-1 php -r 'echo PHP_VERSION, PHP_EOL;'

3. Back up the data directory from the root of your rconfig8docker clone:

   tar -czf rconfig-data-backup-$(date +%Y%m%d).tar.gz ./data

4. Pull the updated image:

   docker compose pull

   Check the output for the app image. Pulled or Downloaded newer image means a new image arrived. Image is up to date means nothing changed, so the updated image is not on your tag yet. Stop here and contact prosupport@rconfig.com.

5. Recreate the container so it runs the new image:

   docker compose up -d --force-recreate

6. Confirm the PHP version inside the container is now 8.4.27 or later:

   docker exec rconfig8docker-app-1 php -r 'echo PHP_VERSION, PHP_EOL;'

   If it still shows the version you recorded in step 2, the container is not running the updated image. Do not treat the server as patched. Keep access restricted, apply the interim measures

7. Confirm all services are running:

   docker exec rconfig8docker-app-1 supervisorctl status

Ubuntu

Ubuntu 20.04 / 22.04 / 24.04

rConfig’s Ubuntu scripts install PHP from ppa:ondrej/php. At the time of the advisory, fixed builds for Ubuntu 22.04 and 24.04 began appearing on the evening of 21 October 2026, and some architectures (arm64, for example) were still being published on 22 October. Check that your Ubuntu release and architecture show the fixed version before relying on it.

1. Store your PHP minor version in a variable:

   PHPV=$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
   echo $PHPV

2. Refresh the package lists:

   sudo apt-get update

3. Check that the candidate version is the fixed release (for example 8.4.27):

   apt-cache policy php${PHPV}-cli

   If the Candidate line still shows the old version, the fixed build is not yet published for your release or architecture. See what to do if the fix is not available yet.

4. Upgrade the installed PHP packages for that version:

   sudo apt-get install --only-upgrade "php${PHPV}*" "libapache2-mod-php${PHPV}"

   Packages that are not installed are skipped.

5. Restart PHP-FPM (if you use it) and Apache:

   sudo systemctl restart php${PHPV}-fpm 2>/dev/null
   sudo systemctl restart apache2

6. Restart the Horizon queue workers so they load the new PHP binary:

   cd /var/www/html/rconfig8/current && sudo php artisan horizon:terminate

   Supervisor starts Horizon again automatically.

Using Ubuntu's own PHP packages instead of the PPA?

Ubuntu security updates usually backport fixes without changing the upstream version number, so php -v may still show an older patch release. Check the package changelog for the CVE IDs, or confirm with Ubuntu’s security notices:

apt changelog php${PHPV}-cli 2>/dev/null | grep -E "CVE-2026-10961(8|9)"

CentOS / Rocky

CentOS Stream / Rocky Linux / AlmaLinux 8 and 9

rConfig’s RHEL-family scripts install PHP from the Remi repository module stream (for example php:remi-8.4). At the time of the advisory, fixed Remi packages were not yet confirmed. The PHP project said the repository would not have updates on 21 October 2026.

1. Check which PHP module stream is enabled:

   sudo dnf module list --enabled php

2. Refresh metadata and list the available PHP updates:

   sudo dnf clean metadata
   sudo dnf --refresh list --upgrades 'php*'

   If no update to the fixed release (for example 8.4.27) is listed, the build is not yet published. See what to do if the fix is not available yet.

3. Upgrade the PHP packages:

   sudo dnf upgrade 'php*'

4. Restart PHP-FPM and Apache:

   sudo systemctl restart php-fpm httpd

5. Restart the Horizon queue workers so they load the new PHP binary:

   cd /var/www/html/rconfig8/current && sudo php artisan horizon:terminate

   Supervisor starts Horizon again automatically.

RHEL

Red Hat Enterprise Linux 8 and 9

A RHEL server gets PHP either from the Remi repository (installed by rConfig’s scripts) or from Red Hat’s own AppStream PHP module. Red Hat, as an OS vendor, received the patches in advance and publishes fixes as errata. Confirm availability for your RHEL release with Red Hat or your systems team. Make sure the subscription is active before you start:

sudo subscription-manager status

1. Check where PHP comes from:

   dnf info --installed php-cli | grep -E "Version|Release|From repo"

   A repository name containing remi means Remi. Anything else (for example rhel-9-for-x86_64-appstream-rpms) means Red Hat AppStream.

2. If PHP comes from Red Hat AppStream, check for the errata and apply them:

   sudo dnf updateinfo list --cve CVE-2026-109618 --cve CVE-2026-109619
   sudo dnf upgrade --cve CVE-2026-109618 --cve CVE-2026-109619

3. If PHP comes from Remi, refresh metadata and upgrade the PHP packages:

   sudo dnf clean metadata
   sudo dnf --refresh list --upgrades 'php*'
   sudo dnf upgrade 'php*'

   If no update to the fixed release is listed, see what to do if the fix is not available yet.

4. Restart PHP-FPM and Apache:

   sudo systemctl restart php-fpm httpd

5. Restart the Horizon queue workers so they load the new PHP binary:

   cd /var/www/html/rconfig8/current && sudo php artisan horizon:terminate

Red Hat backports keep the old version number

Red Hat AppStream packages carry fixes as backports, so php -v will not necessarily show 8.2.35 or 8.3.36. Check the package changelog for the CVE IDs, or confirm with the Red Hat errata:

rpm -q --changelog php-cli | grep -E "CVE-2026-10961(8|9)"

4. Check the update

1. Run php -v (or docker exec rconfig8docker-app-1 php -v for Docker) and confirm the version is a fixed release. Compare it with the version you noted in step 2: if it has not changed, PHP was not updated. For vendor backports, where the version number stays the same, confirm the package changelog lists both CVE IDs instead.
2. Log in to rConfig and open Settings → System & Health.
3. Check the PHP version in the System Info card. This is the PHP that Apache serves, which can differ from the CLI if a service was not restarted.
4. Run a device backup and open a few pages to confirm rConfig works normally.

What if the fixed PHP package is not available yet?

Updating PHP is the only complete solution. The measures in the advisory reduce exposure to specific attack paths but do not make an installation safe. Keep access restricted while you wait for the fixed package.

From the advisory:

• CVE-2026-109618 (OOM corruption): set memory_limit=-1 in a way applications cannot override (for example php_admin_value in the FPM pool or Apache configuration) and check that nothing puts a finite limit back. Set a low post_max_size (8M if you do not need file uploads, 32M if you do) and keep upload_max_filesize below it. Use a container or cgroup limit as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA.
• CVE-2026-109619 (stale global state): set session.upload_progress.enabled=0 and restart every PHP worker, using php.ini, an FPM pool or server configuration that applies before request parsing. On PHP 8.5, also set fatal_error_backtraces=0.

The examples below show one way to apply these settings on a standard rConfig install. The values are examples. Agree them with your systems team.

Apache mod_php (Docker, Ubuntu)

1. Create the configuration file. On a Docker host, run these commands inside the container after docker exec -it rconfig8docker-app-1 bash.

   cat > /etc/apache2/conf-available/zz-php-cve-2026-10.conf <<'EOF'
   <IfModule php_module>
       php_admin_value memory_limit -1
       php_admin_value post_max_size 32M
       php_admin_value upload_max_filesize 16M
       php_admin_flag session.upload_progress.enabled off
   </IfModule>
   EOF

2. Enable it:

   a2enconf zz-php-cve-2026-10

3. Restart Apache. On Ubuntu:

   sudo systemctl restart apache2

   Inside the Docker container:

   supervisorctl restart apache2

4. On a Docker host, set a container memory limit as an availability boundary. Size it for your server, for example:

   docker update --memory 4g --memory-swap 4g rconfig8docker-app-1

Docker: these changes do not survive container recreation

Files written with docker exec live in the container layer. They survive a restart, but docker compose up -d after a pull or a compose change recreates the container and removes them. Re-apply them if that happens before the updated rConfig image is available.

PHP-FPM (CentOS, Rocky, RHEL, Ubuntu)

1. Open the PHP-FPM pool file:

   • CentOS / Rocky / RHEL: /etc/php-fpm.d/www.conf
   • Ubuntu: /etc/php/<version>/fpm/pool.d/www.conf

2. Add these lines at the end of the [www] pool:

   php_admin_value[memory_limit] = -1
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 16M
   php_admin_flag[session.upload_progress.enabled] = off

3. Test the configuration:

   # CentOS / Rocky / RHEL
   sudo php-fpm -t
   # Ubuntu
   sudo php-fpm${PHPV} -t

4. Restart PHP-FPM so every worker picks up the change:

   # CentOS / Rocky / RHEL
   sudo systemctl restart php-fpm
   # Ubuntu
   sudo systemctl restart php${PHPV}-fpm

5. Set a cgroup memory limit on the service as an availability boundary. Size it for your server, for example:

   sudo systemctl set-property php-fpm.service MemoryMax=4G

   On Ubuntu, use php${PHPV}-fpm.service.

On PHP 8.5 only, also add php_admin_flag fatal_error_backtraces off (Apache) or php_admin_flag[fatal_error_backtraces] = off (PHP-FPM).

Once PHP is patched, review these settings with your systems team. memory_limit=-1 removes PHP’s per-request memory cap, so you may want to return it to your previous value.

After patching

If your rConfig server was reachable from the public internet, rotate all secrets and passwords on the server after you have patched. Depending on your environment, this can include OS account passwords and SSH keys, the database password in the rConfig .env file, rConfig user passwords and API tokens, and the device credentials stored in rConfig.

Do not regenerate APP_KEY on its own

rConfig encrypts stored device credentials with the APP_KEY in .env. Running php artisan key:generate without re-encrypting that data makes every stored credential unreadable. Contact prosupport@rconfig.com if you need to rotate APP_KEY.

Common gotchas

• Vendor backports keep the old version number. Ubuntu and Red Hat packages may still show an older patch release after patching. Check the package changelog or the vendor’s security notice for the CVE IDs instead of relying on php -v.
• The CLI and the web server can run different PHP builds. php -v only shows the CLI. Confirm the version in Settings → System & Health, which reports the PHP that Apache serves.
• Services not restarted keep the old PHP in memory. Restart Apache, PHP-FPM and the Horizon workers after upgrading packages or changing PHP settings.
• Vector servers need larger uploads. rConfig recommends a post_max_size of 128M on Vector servers for agent file uploads. With the lower workaround limits in place, larger agent uploads fail until the limits are raised again.

What’s next

• rConfig Security Advisory rCFG-SA-2026-01 for the latest status and per-release impact tables
• Updating PHP for rConfig for moving to a newer supported PHP version
• V8 Pro Docker setup and updates for the full container update and rollback procedure