PHP Critical RCE Fix: Find, Patch and Restart Every Server

1. Identify every runtime serving PHP requests

Start with the default case: Ubuntu 24.04 LTS on a single VPS. Inventory the installed packages before changing anything, then identify how your web server reaches PHP. A command-line interpreter can differ from the runtime handling your website, so finding a patched CLI binary does not clear the server.

cat /etc/os-release
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' | awk '$3 == "installed" && ($1 ~ /^php/ || $1 ~ /^libapache2-mod-php/) { print }'
if command -v php >/dev/null 2>&1; then
  php -v
  php --ini
else
  printf '%s\n' 'No PHP executable found on PATH; check web services and containers separately.'
fi

Inspect the active site configuration for FPM sockets, CGI handlers or an Apache PHP module. Include containers, panel-managed runtimes and binaries installed outside the package manager. The PHP advisory includes PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed in its warning about installations serving web requests. Use the official PHP release notice to check the scope against your deployment.

2. Prioritize exposed workers and choose the fixed release

Treat an internet-facing PHP application as urgent, even when its application dependencies are current. CVE-2026-109618 involves out-of-memory corruption during request handling, and its advisory reports unauthenticated remote code execution as the web worker account. The demonstrated mod_php attack runs before application code, so an application login or upload validation cannot establish that the runtime is protected. Read the CVE-2026-109618 advisory before accepting an application-level workaround.

The PHP project released the listed upstream fixes on 21 October 2026 for both vulnerabilities. CVE-2026-109619 is a use-after-free involving worker global state retained from a finished request; exploitation requires both requests to reach the same worker. Its stale global state advisory explains why patching files without replacing workers leaves an operational gap. We prioritize mod_php deployments, while treating the other web runtimes as requiring the same patch work.

3. Confirm the package candidate and preserve recovery

Refresh package metadata before judging whether your repository has the fix. On the default Ubuntu installation, inspect the candidate for each installed PHP binary package and check whether any PHP packages are held. A successful metadata refresh does not prove that a third-party repository has published corrected packages.

sudo apt-get update
apt-cache policy php8.3-fpm php8.3-cli php8.3-cgi libapache2-mod-php8.3
apt-mark showhold

Ubuntu published USN-8948-1 on 21 October 2026, covering the Apache module, CGI, CLI and PHP-FPM packages. For Ubuntu 24.04 LTS, the fixed php8.3 package revision is 8.3.6-0ubuntu0.24.04.13. Keep that full revision in your change record; the upstream-looking portion alone is misleading for a distribution backport.

Before installing, confirm that your existing backup is available and that you can reach the server through your normal recovery access. Record any custom PHP configuration that a package prompt could affect. If your recovery process is uncertain, use the server backup tool comparison to establish one, while keeping this security update moving through your existing recovery method.

4. Upgrade the installed PHP packages

For distribution-managed PHP, upgrade the installed PHP packages together so that extensions and runtime packages remain aligned. The following block discovers installed packages and asks APT to upgrade them without introducing a separate PHP installation. It preserves existing configuration files when a package supplies a changed default, so review relevant configuration differences afterward.

mapfile -t php_packages < <(dpkg-query -W -f='${binary:Package}\t${db:Status-Status}\n' | awk '$2 == "installed" && ($1 ~ /^php/ || $1 ~ /^libapache2-mod-php/) { print $1 }')
if ((${#php_packages[@]})); then
  sudo env DEBIAN_FRONTEND=noninteractive apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold install --only-upgrade "${php_packages[@]}"
else
  printf '%s\n' 'No distribution PHP packages found. Patch the container, bundled runtime or source installation instead.'
fi

For a container, update the runtime in its build inputs, rebuild the image and replace the deployed container. Updating the VPS package manager does not replace PHP inside an image. For a panel-managed or bundled installation, use that vendor's documented update path and record its evidence that both vulnerabilities are fixed.

Do not silently remove package holds or switch repositories to make the command finish. If Claude Code is assisting, let it inspect the package plan and report blockers, then approve the concrete production change. Our production agent guardrails explain how to keep that access bounded without handing the agent unrestricted maintenance authority.

5. Restart every worker that can execute PHP

Restart the runtime after the package update so requests reach processes running the corrected code. For the default Ubuntu PHP-FPM installation, restart its service; for mod_php, restart Apache. The block below handles those services when active, but it does not discover a custom process supervisor or replace containers.

if systemctl is-active --quiet php8.3-fpm.service; then
  sudo systemctl restart php8.3-fpm.service
  systemctl is-active php8.3-fpm.service
fi
if systemctl is-active --quiet apache2.service; then
  sudo apache2ctl configtest
  sudo systemctl restart apache2.service
  systemctl is-active apache2.service
fi

A restart can interrupt requests, so perform it deliberately and watch the application immediately afterward. If a configuration test fails, correct the error before restarting that service. Where Apache proxies to FPM, ensure that the FPM workers themselves were replaced; restarting only the front-end web server does not establish that.

Repeat this step for every installed PHP branch that serves a site, including internal applications and forgotten virtual hosts. A successful restart of the default service says nothing about another pool managed by a separate service. Keep each application mapped to its runtime until verification is complete.

6. Verify the package revision and application path

Read the package database again after the upgrade, then inspect the executable used by the active service. For Ubuntu's default PHP-FPM package, its version output helps identify the runtime, while the package revision establishes whether the distribution fix is installed. CLI output remains supporting evidence because it follows a different execution path.

dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' | awk '$3 == "installed" && ($1 ~ /^php/ || $1 ~ /^libapache2-mod-php/) { print }'
if command -v php >/dev/null 2>&1; then
  php -v
fi
if [ -x /usr/sbin/php-fpm8.3 ]; then
  /usr/sbin/php-fpm8.3 -v
fi

Open your application's normal dynamic page and exercise an authenticated workflow if the application has one. Check its upload flow when applicable, using ordinary valid input rather than an exploit payload. Review service and application logs for new startup errors or failed requests after the restart.

Avoid leaving a public phpinfo page behind as verification evidence. Prefer your service configuration, package records and existing application diagnostics. Add the dynamic route to your minimum viable server monitoring so that a healthy static page cannot hide a failed PHP backend.

7. Contain exposure when a fixed runtime is unavailable

Updating is the only complete fix described by the PHP advisory. If your supplier has no corrected runtime, restrict access to the affected application or take it out of public service while arranging the update. We would choose a controlled interruption over treating a configuration workaround as equivalent to a patch.

• For CVE-2026-109619, disable session upload progress in php.ini, an FPM pool or server configuration, then restart every worker. Do not rely on ini_set() or .user.ini.
• The stale global state advisory also lists fatal_error_backtraces=0 on PHP 8.5 and pm.max_requests=1 if performance allows. Apply these only in the appropriate configuration context.
• The PHP advisory describes memory_limit=-1 and a low post_max_size as reductions for specific attack paths. Removing PHP's memory limit needs a deliberate resource boundary and does not complete remediation.
• Do not introduce RLIMIT_AS or RLIMIT_DATA as the memory boundary. The advisory warns that they can trigger vulnerable allocation failures and recommends a container or cgroup limit instead.

PHP 8.1 and older receive no updates from the PHP project, although a distribution may supply its own fixes. Ubuntu's notice includes fixed PHP packages for Ubuntu 22.04 LTS, so check the supplier before declaring an older upstream branch unpatchable. Minimal source backports exist for PHP 7.4, 8.0 and 8.1, but building those into a maintained runtime is a separate operational responsibility.

If you depend on PHP 8.2, schedule its replacement because its end of life is 31 December 2026. Keep the immediate security update separate from that migration so compatibility work does not delay today's fix. Attach an owner and an explicit removal condition to every temporary mitigation.

8. Check the remaining fleet and record the next action

Repeat the inventory against every server and deployment artifact you operate. Record the application, runtime source, installed fixed package or image reference, and worker restart evidence. Include staging systems that accept public requests; their exposure does not disappear because their data is less important.

Patching closes the vulnerable runtime path, but it cannot establish whether an earlier compromise occurred. Review available access and application logs for unusual activity, and investigate unexplained worker crashes or unexpected changes using your incident process. Do not run a public proof of concept against production as a substitute for checking package provenance and deployment state.

Your next action is to select the next unchecked host and run the inventory from the first step. Once the inventory has no unresolved web runtimes, assign remaining repository or migration blockers to a named owner. Then use the Ubuntu hardening verification checklist to check the surrounding server controls without confusing those controls with this runtime patch.