DEV Community

Igor
Igor

Posted on AI-assisted

PHP2Shell on Ubuntu: How to Verify and Install the PHP Security Patch

#php #devops #security #ubuntu

PHP security advisory from October 21, 2026
On October 21, 2026, the PHP security team released emergency fixes for two critical vulnerabilities that could allow unauthenticated remote code execution (RCE).

The issues, commonly discussed as PHP2Shell, are tracked as:

  • CVE-2026-109618 — Remote code execution through out-of-memory corruption.
  • CVE-2026-109619 — Remote code execution through stale internal request state.

If you run PHP on an Ubuntu VPS, updating is important. But there's a detail that can easily cause confusion: an Ubuntu server can have the security fixes installed while php -v still reports an older upstream version.

For example, Ubuntu 24.04 can report PHP 8.3.6 even after installing the relevant security patches.

Here's how to check the actual package revision, identify which PHP runtime serves your website, apply the update, and verify the result.

This guide uses Ubuntu 24.04 LTS with PHP 8.3-FPM as its main example.

What exactly is PHP2Shell?

These vulnerabilities affect the PHP interpreter itself, not just applications built with PHP.

CVE-2026-109618: Out-of-memory corruption

PHP can encounter memory allocation failures while handling HTTP requests.

In affected versions, an out-of-memory condition can interrupt internal request initialization. During cleanup, PHP may subsequently treat partially initialized data as valid.

Under exploitable conditions, this can lead to memory corruption and remote code execution.

CVE-2026-109619: Stale global state

PHP workers can process multiple requests during their lifetime.

This issue involves internal request-owned state remaining accessible after its underlying memory has been freed.

A later request handled by the same worker may access stale state before normal initialization resets it.

That creates another potential remote code execution path.

Which environments are affected?

The official PHP security advisory identifies web-facing PHP installations, including:

  • PHP-FPM with Nginx
  • Apache with mod_php
  • PHP-CGI
  • FrankenPHP
  • LiteSpeed

The PHP team considers Apache with mod_php particularly high risk because a demonstrated attack can be triggered before application code executes.

Updating WordPress, Laravel, Drupal, or another PHP application does not fix these vulnerabilities in the underlying interpreter.

Which PHP versions contain the fixes?

On October 21, PHP published the following upstream security releases:

PHP branch First fixed upstream version
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

PHP 8.1 and older releases no longer receive regular upstream security updates, although some Linux distributions and long-term-support vendors maintain patched packages.

Here's the catch for Ubuntu administrators: upstream PHP version numbers and Ubuntu package revisions are not the same thing.

Why Ubuntu 24.04 may still show PHP 8.3.6

Canonical frequently backports security fixes into distribution packages instead of replacing the entire PHP version with the latest upstream release.

For Ubuntu 24.04 LTS, the first fixed PHP 8.3 package revision is:

8.3.6-0ubuntu0.24.04.13
Enter fullscreen mode Exit fullscreen mode

Notice that the upstream part remains 8.3.6.

If you only run:

php -v
Enter fullscreen mode Exit fullscreen mode

you might still see PHP 8.3.6 and conclude that your server is vulnerable.

That conclusion may be incorrect.

Canonical confirms the following fixed package revisions in Ubuntu Security Notice USN-8948-1:

Ubuntu release PHP branch First fixed package revision
22.04 LTS 8.1 8.1.2-1ubuntu2.28
24.04 LTS 8.3 8.3.6-0ubuntu0.24.04.13
26.04 LTS 8.5 8.5.4-0ubuntu1.5
26.10 8.5 8.5.9-0ubuntu2.1

These versions apply to the corresponding official Ubuntu packages.

If PHP was installed from a third-party PPA, a hosting control panel, or a custom source build, check that vendor's security advisory instead.

Step 1: Identify the Ubuntu release

Connect to your server through SSH.

Run:

cat /etc/os-release
Enter fullscreen mode Exit fullscreen mode

Look for the VERSION_ID value.

For example:

VERSION_ID="24.04"
Enter fullscreen mode Exit fullscreen mode

This tells you which Ubuntu security notice and package revisions apply to your system.

Now check the default PHP interpreter:

php -v
Enter fullscreen mode Exit fullscreen mode

Keep in mind that this checks the command-line PHP binary, which may differ from the PHP installation serving your website.

Step 2: Identify the web-facing PHP runtime

A server can have several PHP versions installed simultaneously.

List installed PHP packages with their complete revisions:

dpkg-query -W \
  -f='${binary:Package} ${Version}\n' \
  'php8.*' 'libapache2-mod-php*' 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Check the installed PHP-FPM services:

systemctl list-unit-files 'php*-fpm.service'
Enter fullscreen mode Exit fullscreen mode

If your website uses Nginx, inspect the configured FastCGI targets:

sudo nginx -T 2>/dev/null | grep fastcgi_pass
Enter fullscreen mode Exit fullscreen mode

This helps identify the PHP-FPM socket or upstream handling requests.

For Apache installations, inspect the loaded PHP-related modules:

sudo apachectl -M 2>/dev/null | grep -E 'php|proxy_fcgi'
Enter fullscreen mode Exit fullscreen mode

Only run the web-server checks that apply to your environment.

For Ubuntu 24.04 with PHP 8.3-FPM, examine the package information:

apt-cache policy php8.3-fpm
Enter fullscreen mode Exit fullscreen mode

The important fields are:

  • Installed: the package currently installed.
  • Candidate: the package available for installation.
  • Version table: where those packages come from.

Don't classify a server as patched solely because a newer package is available. Confirm the version that is actually installed and running.

Step 3: Install the Ubuntu security update

Before changing production packages, ensure that your application files, databases, and configuration are backed up.

For an installation using official Ubuntu repositories, refresh package indexes:

sudo apt update
Enter fullscreen mode Exit fullscreen mode

Review available updates:

apt list --upgradable
Enter fullscreen mode Exit fullscreen mode

During an appropriate maintenance window, apply the updates:

sudo apt upgrade
Enter fullscreen mode Exit fullscreen mode

Read the proposed changes before confirming.

For packages maintained by Ubuntu, Canonical states that a standard system update generally installs the necessary corrections.

If your server uses third-party PHP packages, check their maintainer's instructions instead.

Verify the installed PHP package revision

On Ubuntu 24.04:

dpkg-query -W \
  -f='${Package} ${Version}\n' \
  php8.3-fpm
Enter fullscreen mode Exit fullscreen mode

Compare the resulting revision with the version in USN-8948-1.

For example, an official Ubuntu package at revision:

8.3.6-0ubuntu0.24.04.13
Enter fullscreen mode Exit fullscreen mode

contains the October 21 fixes.

A later package revision from the same maintained Ubuntu repository should also be checked against Canonical's advisories.

Remember: the package name and revision are only part of the answer. You also need to establish which PHP runtime is handling HTTP requests.

Step 4: Restart PHP-FPM or Apache

Updated PHP packages must be loaded into the processes serving requests.

For PHP 8.3-FPM, start by checking its configuration:

sudo php-fpm8.3 -t
Enter fullscreen mode Exit fullscreen mode

If the configuration is valid, restart the service:

sudo systemctl restart php8.3-fpm
Enter fullscreen mode Exit fullscreen mode

Check its status:

sudo systemctl status php8.3-fpm --no-pager
Enter fullscreen mode Exit fullscreen mode

If the restart fails, inspect recent logs:

sudo journalctl -u php8.3-fpm -n 30 --no-pager
Enter fullscreen mode Exit fullscreen mode

For Apache with mod_php, validate its configuration and restart Apache instead:

sudo apachectl configtest
sudo systemctl restart apache2
Enter fullscreen mode Exit fullscreen mode

Avoid restarting unrelated services on a production system.

Check that the application is responding

You can perform a basic HTTPS check:

curl -fsS -o /dev/null \
  -w '%{http_code}\n' \
  https://example.com/
Enter fullscreen mode Exit fullscreen mode

Replace example.com with your application domain.

A successful response confirms basic availability. It does not prove that the PHP vulnerabilities have been fixed.

That requires checking the installed vendor-fixed package and the runtime serving your application.

An additional PHP advisory from October 23

Two days after the PHP2Shell security release, the PHP team published an informational advisory about session upload progress.

It concerns a separate potential remote code execution scenario associated with CVE-2026-115560.

The issue requires an unusual combination of application behavior:

  1. session.serialize_handler is configured as php_binary or php_serialize.
  2. Application code changes the handler to php using ini_set().
  3. The application calls session_start().
  4. Session upload progress is enabled.

Applications that never change the serialization handler at runtime are not exposed through this specific scenario.

As of October 29, PHP recommends temporarily setting:

session.upload_progress.enabled = 0
Enter fullscreen mode Exit fullscreen mode

For Ubuntu 24.04 with PHP 8.3-FPM, the main configuration file is typically:

/etc/php/8.3/fpm/php.ini
Enter fullscreen mode Exit fullscreen mode

Edit the configuration if the recommendation is appropriate for your application:

sudoedit /etc/php/8.3/fpm/php.ini
Enter fullscreen mode Exit fullscreen mode

After making the change, check for conflicting PHP-FPM pool or server configuration overrides.

Then validate and restart PHP-FPM:

sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
Enter fullscreen mode Exit fullscreen mode

The setting must be applied before request parsing. Don't rely on changing it through application-level ini_set() or .user.ini.

Disabling session upload progress may affect applications that depend on this feature, so assess its impact before changing production settings.

This measure does not replace the PHP2Shell security updates.

The PHP team has also published other temporary mitigations for specific attack paths. Those measures reduce exposure but do not provide complete protection. Installing the security fixes remains the recommended solution.

What if PHP runs inside Docker?

If you deploy PHP applications in containers, updating Ubuntu on the host does not automatically update PHP inside those containers.

First list running containers:

docker ps
Enter fullscreen mode Exit fullscreen mode

Identify the container serving your application.

Then check the installed PHP interpreter:

docker exec CONTAINER_NAME php -v
Enter fullscreen mode Exit fullscreen mode

Replace CONTAINER_NAME with the actual container name.

For Docker Compose deployments:

docker compose images
Enter fullscreen mode Exit fullscreen mode

Inspect the PHP image and check whether its upstream maintainer has released a patched version.

Depending on your deployment, you may need to pull an updated image or rebuild a custom image using a patched base.

For services that use published images, a typical deployment sequence is:

docker compose pull
docker compose up -d
Enter fullscreen mode Exit fullscreen mode

For custom-built images, rebuilding and redeploying may also be required.

After deployment, verify the PHP installation inside the replacement container.

The same rule applies here: a PHP version banner alone might not reveal whether a distribution-based image contains backported security fixes.

When rebuilding on a new VPS makes sense

For a supported Ubuntu system, applying the available security updates is usually the most practical option.

However, moving to a fresh server may be worth considering when the existing environment is no longer maintainable.

Examples include an unsupported operating system, an abandoned PHP repository, incompatible legacy dependencies, or a server whose integrity can no longer be trusted.

If you need a new environment, Cherry Servers offers virtual servers with Ubuntu installation options, including Ubuntu 24.04 LTS.

A migration should begin with a clean, updated operating system, followed by a maintained PHP runtime and properly configured web server.

Before switching production traffic, restore the application from verified backups and test its functionality.

Rebuilding does not automatically resolve PHP security issues. New servers require regular patching, access controls, monitoring, and maintenance just like existing ones.

Affiliate disclosure: The Cherry Servers link above is an affiliate link. I may earn a commission if you purchase through it, at no additional cost to you.

How to confirm that PHP2Shell has been patched

A reliable verification should answer four questions:

  1. Which PHP runtime serves incoming requests? The CLI interpreter may not be the same one your website uses.
  2. Where did the PHP package come from? Official Ubuntu repositories and third-party sources can use different security patch schedules.
  3. Does the installed package contain the vendor's fix? Compare its complete package revision with the corresponding security advisory.
  4. Are the patched workers running? Restart or replace the affected processes, then verify application availability.

If these checks are complete, you have a stronger basis for assessing remediation than simply reading the output of php -v.

For Ubuntu 24.04, the key detail is that a properly updated PHP 8.3.6 distribution package can contain the October 21 security fixes.

The package revision matters more than the upstream version banner.

Official references

Top comments (0)