PHP vulnerability remediation: Ubuntu, Debian, RHEL and Docker

1. Choose the right maintenance path

Only work on servers you are authorized to administer. Inventory web nodes, background jobs, queue workers and standby systems. For a load-balanced service, agree how to drain and restore each node.

Read the technical analysis of the two vulnerabilities →

2. Record the OS, PHP and active services

The following commands inspect the environment. php -v, php --ini and php -m describe CLI PHP, which can differ from the website’s runtime. Map it to FPM pools, Apache configuration, containers or the hosting panel.

cat /etc/os-release
command -v php
php -v
php --ini
php -m
systemctl list-units --type=service --state=running --no-pager

Where multiple binaries exist, map each domain to its actual runtime. An authorized administrator should review frontend socket and FPM configuration. Configuration files and logs may contain secrets; do not paste them into public forms.

3. Prepare backups and a tested recovery path

• Record application files, uploads, database, PHP/web-server configuration and current packages or images.
• Keep backups outside public web directories with restricted access. Confirm restoration tests and ownership.
• Plan for orders and reservations created during maintenance. A VM snapshot may not provide an application-consistent database backup.
• Agree a maintenance window, communications, console access and recovery criteria. Package scripts may restart services during the update.

A copy of PHP configuration alone is not a full backup. Stop if you cannot establish recovery or preserve transaction consistency.

4. Ubuntu and Debian: inspect installed packages

dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' 'php*' 'libapache2-mod-php*'
apt-mark showhold

The pattern can include multiple branches and extensions. A not-found result can refer to an uninstalled package. Investigate holds before changing them. Third-party packages need confirmation from their supplier.

The next example assumes Ubuntu 24.04 standard PHP 8.3, FPM and CLI. USN-8948-1 lists 8.3.6-0ubuntu0.24.04.13 as fixed: the older upstream prefix illustrates a vendor backport. Match the current notice and repository candidate.

5. APT: review candidates and simulate before applying

This refreshes package metadata and simulates installation without replacing PHP packages. Adapt the names to the installed runtime and review extensions and other branches separately.

sudo apt-get update &&
apt-cache policy php8.3-common php8.3-fpm php8.3-cli &&
sudo apt-get -s install --only-upgrade php8.3-common php8.3-fpm php8.3-cli

Stop if no fixed candidate exists, dependencies are unclear, removals are proposed or a branch changes unexpectedly. Do not improvise by adding repositories, forcing upgrades or deleting packages.

sudo apt-get install --only-upgrade php8.3-common php8.3-fpm php8.3-cli

These three packages are not a complete inventory for every installation. CGI, Apache modules and other PHP branches may also require updates. Review configuration-file prompts instead of blindly replacing custom settings.

apt-cache policy php8.4-common php8.4-fpm php8.4-cli &&
sudo apt-get -s install --only-upgrade php8.4-common php8.4-fpm php8.4-cli

Complete sudo apt-get update first and confirm the Debian security package. Other releases require their own notice and package names. Do not mix Ubuntu packages into Debian.

6. PHP-FPM: validate, then replace the workers

This example uses the versioned PHP 8.3 FPM binary. For Debian PHP 8.4, verify and adapt the binary and service name. A failed configuration test is a stop condition.

sudo php-fpm8.3 -t

Old processes may still have the previous runtime loaded after package installation. Drain the target node and restart the correct service during maintenance. A reload message alone does not prove all old workers have exited.

sudo systemctl restart php8.3-fpm &&
systemctl is-active php8.3-fpm &&
sudo journalctl -u php8.3-fpm --since '10 minutes ago' --no-pager

An Nginx frontend does not necessarily need restarting for a PHP-only update. Validate frontend changes separately where relevant. Treat journal output as potentially sensitive.

7. Apache mod_php: update the module used by Apache

Apache can use FPM rather than mod_php. Check the loaded modules; proxy_fcgi points toward the actual FPM maintenance path. This example assumes Ubuntu-style mod_php 8.3 is already installed.

sudo apache2ctl -M
sudo apache2ctl configtest
apt-cache policy libapache2-mod-php8.3
sudo apt-get -s install --only-upgrade libapache2-mod-php8.3 php8.3-common

sudo apt-get install --only-upgrade libapache2-mod-php8.3 php8.3-common &&
sudo apache2ctl configtest

Confirm successful configuration validation before executing the separate restart below. Shared Apache services may serve several sites.

sudo systemctl restart apache2 &&
systemctl is-active apache2

8. RHEL family: verify supplier and package coverage

RHEL, Rocky Linux and AlmaLinux have distinct notices and delivery policies. Confirm enabled repositories, maintenance coverage and any module stream or third-party packaging.

rpm -qa 'php*'
dnf repolist --enabled
dnf updateinfo list --security
dnf list --upgrades 'php*'
sudo dnf upgrade --assumeno 'php*'

An empty update list is not proof of a fix. Investigate metadata, support coverage and package names. Names such as remi-php83-php are not covered by the php* example.

sudo dnf upgrade 'php*' &&
sudo php-fpm -t

After a successful test, restart only if the standard php-fpm service is the runtime in question. A different Apache integration requires its supplier’s service procedure.

sudo systemctl restart php-fpm &&
systemctl is-active php-fpm &&
sudo journalctl -u php-fpm --since '10 minutes ago' --no-pager

9. Docker: identify the actual PHP service and image

The service is named php in these examples. Verify the Compose project, files and environment; your service may instead be app or wordpress. Updating host PHP does not update PHP inside an existing container.

docker compose config --services
docker compose config --images
docker compose ps
docker compose images php
docker compose exec -T php php -v

Change the Compose image reference or Dockerfile FROM to a tag or digest verified to contain the fix. Pulling an old pinned digest cannot introduce a fix. For custom OS-package images, review the build steps too.

10. Docker: pull or rebuild, then recreate

For a prebuilt image, first select the approved fixed reference, then pull it. Pulling does not replace the running container.

docker compose pull php

For a custom Dockerfile, select a patched base before rebuilding. This is an alternative to the prebuilt-image path. --pull does not change an explicitly pinned vulnerable digest.

docker compose build --pull --no-cache php

Verify PHP, extensions and application behaviour in the resulting image, then deploy through the approved process. This single-service maintenance example is not a zero-downtime rolling deployment; handle dependencies and replicas through your operational design.

docker compose up -d --no-deps --force-recreate php &&
docker compose ps php &&
docker compose exec -T php php -v &&
docker compose logs --tail=100 php

docker compose restart does not apply a changed image reference or configuration. Do not add volume deletion, down -v or unrelated cleanup to this process.

11. Verify package, process and web runtime separately

dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php8.3*'
php -v
systemctl show php8.3-fpm -p ActiveState -p MainPID -p ExecMainStartTimestamp

Confirm the installed package matches the supplier’s fix and the relevant process started afterwards. Then map real web requests to the runtime through authenticated administration or an existing internal health check. There is no need to publish phpinfo().

curl --fail --silent --show-error --max-time 15 \
  --output /dev/null --write-out 'HTTP %{http_code}\n' \
  https://example.com/

The curl result checks reachability, not patch status. A CDN cache may return 200 without reaching PHP. Inspect all nodes, pools and subdomains for old instances.

12. Verify the application’s important journeys

• Administration, public pages, search and images.
• Enquiry submission and receipt, bookings, and approved test payment or checkout paths.
• Uploads, image processing, external APIs, scheduled tasks and queues.
• Error rates, startup failures, worker churn, latency, CPU and memory.

Avoid combining unnecessary changes that obscure diagnosis. Record results. Successful update tests do not establish that no earlier compromise occurred.

13. Handle errors, missing fixes or compromise concerns

Stop additional changes on failed validation, failed updates, 500/502 responses or inconsistent data. Record what happened, consider maintenance mode or draining the node, and contact the responsible administrator.

Check new orders and reservations before database restoration. If compatibility forces consideration of an unpatched runtime, do not leave it publicly exposed as the final remedy; coordinate a supported recovery path.

Unexpected files, accounts or outbound connections require more than patching. Preserve relevant evidence and work with the administrator or incident-response team on isolation, investigation, clean recovery and credentials.

14. Record completion and hand over open questions

• Domain, OS/supplier, actual web PHP and the official evidence supporting the fix.
• Before/after package versions or image digests, restarted services and timestamps.
• Recovery information, tested functions, unresolved issues and next owner.

Tsumira Japan can help from environment identification through post-update verification. Send only the URL and situation in the public form. Arrange any access after scope and cost are agreed; do not submit SSH keys, root passwords, tokens or personal-data logs.

Questions and answers

Is there one command that always fixes this?

No. Identify the supplier and web runtime, select the applicable fix, replace the relevant processes and verify the application.

The CLI version changed. Are we done?

Not necessarily. Confirm the web runtime and running workers or containers were replaced too.

I have no server experience. Should I try copying the commands?

Stop if you cannot assess meaning, impact or recovery. Contact your supplier or Tsumira Japan; paid work requires agreement on scope and cost.

Have these commands been executed on every supported OS?

The examples were checked against official documentation and checked for syntax. They are not execution-tested across every production configuration or a guarantee for your environment.

Official references

• PHP: security advisory and fixed releases ↗
• Ubuntu: USN-8948-1 ↗
• Debian: PHP 8.4 security package ↗
• Debian: apt-get reference ↗
• Red Hat: identify security updates ↗
• Docker: compose pull ↗
• Docker: compose build ↗
• Docker: compose up ↗
• PHP: FPM configuration ↗
• WordPress: database and file backups ↗

Official guidance and interfaces can change. Confirm your actual plan, configuration and the supplier’s latest notice. This guide does not certify the security or patch status of any individual environment.