PHP2Shell: Check and Update PHP on VPS and Docker

A familiar maintenance trap is checking php -v, seeing a current version and assuming every website uses it. A server can have several PHP installations: one for the shell, another for a domain, and more inside containers or background workers.

The useful question is: which PHP build actually handles this request, and has its vendor fixed both vulnerabilities? Work through the paths below for the services you operate.

What is PHP2Shell?

PHP2Shell is the name used for CVE-2026-109618 and CVE-2026-109619, two PHP memory-handling vulnerabilities that can lead to remote code execution. PHP's advisories describe out-of-memory corruption and stale request state.

The PHP announcement covers web handlers including PHP-FPM, Apache with mod_php, CGI, FrankenPHP and LiteSpeed. Changing the web server or putting a proxy in front does not establish that the runtime is patched.

PHP2Shell fixed versions and support dates

These are the first fixed upstream releases for the two vulnerabilities, rather than a promise that a branch will need no further updates. Use a current supported build and review subsequent advisories.

Patch thresholds come from the PHP release announcement; lifecycle dates come from the PHP support schedule. PHP 8.1 and earlier are no longer supported upstream. A distribution or commercial vendor may provide a backport; obtain confirmation for the exact package.

For example, use the Ubuntu records for CVE-2026-109618 and CVE-2026-109619, or the Debian records for CVE-2026-109618 and CVE-2026-109619. Check the entry for your operating-system release and configured package source.

Choose the update path you control

1. Inventory PHP and verify the web runtime

On a Linux VPS, start with the command-line installation:

command -v php
php -v
php --ini
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'

These commands identify the PHP executable and configuration available in that shell. The PHP command-line manual documents the options; PHP's SAPI reference explains handler names such as cli, fpm-fcgi and litespeed.

Next, inspect the web application's own authenticated diagnostics. In WordPress, open Tools → Site Health → Info → Server and note the PHP version. The WordPress Site Health documentation describes this server information.

For another application, use its administrator diagnostics or an access-controlled temporary endpoint that reports only the required PHP version and handler. Remove temporary diagnostics after checking. Avoid leaving a public phpinfo() page that exposes detailed configuration.

• Check each domain and subdomain that can select a different runtime.
• Include queue workers, scheduled commands and containers in the inventory.
• For a replicated service, verify every serving instance.
• Pair runtime output with the package or image build record when backports are involved.

2. Prepare a recoverable update

Keep an application-consistent database backup, site files, configuration and a record of extensions before changing packages or images. Store the recovery copy away from the server being updated. A snapshot can help with a failed change, but it should be part of a recovery plan that also covers database consistency.

Use a staging copy to check application compatibility where possible. For an exposed vulnerable service, keep that rehearsal short and restrict access or take the service offline if you cannot patch promptly. Do not leave it exposed while waiting for a convenient maintenance date.

For backup planning, see our VPS backup guide. Encrypt configuration and database copies stored on a HYEHOST Storage Box, and test that you can recover the application.

3. Update PHP packages on an Ubuntu or Debian VPS

First establish who supplies PHP. The following inventory example is for a server using PHP 8.3 packages; substitute the branch and package names you actually have:

dpkg-query -W 'php*'
apt-cache policy php8.3-fpm php8.3-cli php8.3-common
systemctl list-units --type=service --all 'php*-fpm.service'

Refresh package metadata, inspect the proposed change and then install the updates. This example targets PHP 8.3 FPM and CLI packages; include installed extension packages that also need updating:

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

Read the simulation before running the final command. If the configured repository has no fixed candidate, check its advisory and supported upgrade route. Reinstalling an unchanged package does not establish remediation. For PHP managed by DirectAdmin CustomBuild or another panel, use that system's update process instead.

Validate configuration and restart the relevant serving processes so they load the new binaries. For the same PHP 8.3 FPM example:

sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

Apache modules, LiteSpeed and other handlers have their own service names and restart procedures. Restart any long-running application workers that use PHP too. Return to the authenticated web diagnostic and test the site through its usual hostname.

4. Update PHP inside Docker containers

Updating PHP on the VPS host does not change PHP inside an existing image. Docker published patched PHP images after the disclosure; applications built on them still need to be refreshed and deployed. Read Docker's PHP2Shell response.

From the existing Compose project directory, list the services and images:

docker compose config --services
docker compose images
docker compose ps

In the examples below, php is the Compose service name. Replace it with your PHP application's service name. For an image supplied by an application vendor, select a compatible release that the vendor confirms contains the fix, updating the tag or pinned digest in compose.yaml.

When you use a published application image

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

Pull downloads the configured image; it does not replace the running container. The up command recreates it. The CLI version check remains an inventory check: verify the website through its real PHP handler afterwards. Check all replicas and other services that embed PHP.

When you build your own application image

Update the Dockerfile's PHP base to a patched, compatible tag or digest. For example, an application already using upstream PHP 8.4 FPM can use FROM php:8.4.27-fpm as the minimum-fixed starting point. Preserve the existing distribution variant and extensions; do not switch from Apache to FPM as part of a routine patch.

docker compose build --pull --no-cache php
docker compose up -d --no-deps --force-recreate php
docker compose exec php php -v

The build options refresh the base image and avoid reusing cached build steps. If a package is pinned to a vulnerable version in your Dockerfile, change that pin as well. Check the resulting image and the running service, not just a successful build message.

These Compose examples are for an existing single-project deployment and can interrupt that service. Clustered deployments need their own rollout process. Retain persistent volumes, and follow our Docker Compose update guide for backup and recovery planning.

5. Check DirectAdmin shared and reseller hosting

In DirectAdmin, review the PHP selection under Domain Setup. Subdomains may use an override, so check those separately. DirectAdmin documents the per-domain PHP selection.

A selector showing “PHP 8.3” identifies a branch, not its exact security build. Shared and reseller customers should ask the server administrator to confirm the serving build and whether both CVEs are fixed. For a reseller, make a list of customer domains and older PHP requirements before coordinating a change.

For server administrators: DirectAdmin exposes individual component updates under Admin → CustomBuild → Updates. The read-only inventory command is:

da build versions

Review and apply the relevant PHP component update, then verify each enabled handler. Avoid rebuilding every service simply to patch PHP. The CustomBuild update documentation explains the available controls.

6. Review the follow-up PHP notices

On 23 October, PHP also advised setting session.upload_progress.enabled=0 pending a regular fix for an additional, configuration-dependent issue. Check that guidance against the active web-handler configuration and the current release notes. Changing the CLI's php.ini alone may not affect the website. This follow-up does not replace the original security update. Read the session upload progress notice.

For Windows PHP installations, the 26 October notice covers rebuilt -1 packages with an updated Brotli dependency. A PHP runtime version alone does not identify that package rebuild. Check the Windows build notice.

7. Verify the site and record what changed

If the application breaks, keep access restricted while you repair compatibility or deploy a compatible patched build. Returning a known vulnerable runtime to public service reintroduces the original risk.

If you see signs of compromise, patching alone is not a clean-up procedure. Isolate the affected service, preserve relevant logs and investigate changed files and credentials before rebuilding from a trusted source.

Where HYEHOST services fit

A HYEHOST Cloud VPS gives administrators control over packages, containers and maintenance timing, with deployment in Wolverhampton, Ashburn or Auckland. That control comes with responsibility for keeping the guest operating system and application runtime updated.

For websites that fit a hosted control-panel workflow, compare shared hosting or reseller hosting. HYEHOST uses DirectAdmin and LiteSpeed for these services. Runtime checks and application testing still matter whichever service you choose.

PHP2Shell hosting FAQ