Critical PHP Security Update (PHP2Shell)

C

As you’ve all probably heard by now, on October 20, details of two critical remote code execution (RCE) vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, leaked online before their coordinated disclosure and before patches were released.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

For PHP2Shell, the minimum patched upstream versions are:

PHP VersionPatched PHP package version
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

Our fleet and demos have all been fully upgraded to the patched versions of PHP.

To see the timeline on mitigation and patching, see the incident on our status page. We have no evidence that any of our hosted fleet’s data has been compromised.

Docker Users

Docker users can get the patched version of the Snipe-IT image by pulling from the latest tagged release. We don’t pin the patch versions in the docker images, so a rebuild will get whatever is latest for the distro.

Ubuntu

Ubuntu back patches their packages and then gives them a sub-version (the 24.0.13) version. Run this to see the full installed PHP package versions:

apt list --installed 2>/dev/null | grep -E '^(php[0-9]|libapache2-mod-php)'

For example:

apt list --installed | grep php

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libapache2-mod-php8.3/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php-common/now 2:93ubuntu2 all [installed,local]
php-memcached/now 3.2.0+2.2.0-4ubuntu3 amd64 [installed,local]
php8.3-bcmath/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-cli/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-common/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-curl/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-dev/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-gd/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-igbinary/now 3.2.13-1ubuntu3 amd64 [installed,local]
php8.3-ldap/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-mbstring/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-memcached/now 3.2.0+2.2.0-4ubuntu3 amd64 [installed,local]
php8.3-msgpack/now 1:2.2.0~rc2-3ubuntu1 amd64 [installed,local]
php8.3-mysql/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-opcache/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-readline/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-redis/now 5.3.7+4.3.0-3ubuntu1 amd64 [installed,local]
php8.3-xml/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]
php8.3-zip/now 8.3.6-0ubuntu0.24.04.13 amd64 [installed,local]

For Ubuntu in Docker:

docker exec sh -c 'apt list --installed 2>/dev/null | grep -E "^(php[0-9]|libapache2-mod-php)"'

Compare the versions with these minimum patched versions for Ubuntu’s official packages:

Ubuntu VersionPatched PHP package version
22.048.1.2-1ubuntu2.28
24.048.3.6-0ubuntu0.24.04.13
26.048.5.4-0ubuntu1.5
26.108.5.9-0ubuntu2.1

Those versions or newer updates for the same Ubuntu release include the PHP2Shell fixes. See the Ubuntu advisory, including older releases.

php -v alone isn’t enough to determine which version you’re running: Ubuntu’s backported fix may leave the upstream version showing 8.3.6 even though it was updated. Restart Apache/PHP-FPM, or recreate the updated container, to ensure the serving processes use the patched binaries.

An output like php84-8.4.27-r0 includes the fix. A higher revision alone does not prove it’s patched.

Alpine

To see the full installed PHP package versions, including Alpine’s patch revision:

docker exec sh -c 'apk info -v | grep -E "^php[0-9]+-"'

Or, from inside the container:

apk info -v | grep -E '^php[0-9]+-'

Self-hosted users are urged to upgrade their version of PHP immediately, and check for any Indicators of Compromise (IOCs).

Indicators of Compromise (IOCs)

  • Potential pre-exploit indicators: Bursts of requests to one endpoint, PHP worker crashes, out-of-memory, or fatal errors in logs, and multipart POSTs carrying PHP_SESSION_UPLOAD_PROGRESS (one sample confirmed path, but not the only one).
  • Potential post-exploit indicators: Monitor for behaviors that indicate an attacker has already gained code execution on a PHP host. New or changed .php files, shells spawned by PHP, unusual outbound connections. New cron jobs, systemd units, users, or SSH authorizedkeys, changes to autoprepend_file in php.ini, .user.ini, or .htaccess, unexpected PHP extensions, or new outbound connections from the web user.

Via Huntress:

“Florian Roth, who released a free tool called process-watcher (a Linux-based process monitoring tool aimed at detecting exploitation) put it well: exploitation of these bugs will most likely show up as suspicious child processes spawned by PHP. 

In practice, that means a PHP worker process like php-fpm, php-cgi, php-cgi.exe, httpd, or apache2 would launch something abnormal:

  • Shells like sh, bash, cmd.exe, or powershell.exe
  • Interpreters like python or perl
  • Download or networking tools like curl, wget, nc, or certutil.exe

It’s worth taking a closer look at command lines that include reverse shell patterns:

  • /dev/tcp/ 
  • fsockopen
  • mkfifo 

It’s also worth looking at quick reconnaissance commands like whoami, id, uname -a, or ipconfigrun straight from the web server.”

Special thanks to Remi Collet for pushing those updates to his repo on his vacation. If you’re a self-hosted user and you use his repo, you should consider donating via his PayPal button.

Additional references:

About the author

A. Gianotto

Alison is the founder and CEO of Grokability, Inc, the company that makes the open source product Snipe-IT.

By A. Gianotto

Snipe-IT at Laracon

Open Source in Business Interview

Snipe-IT at Longhorn PHP

Recent Posts