PHP2Shell on Ubuntu

Ubuntu fixes PHP2Shell in its own PHP packages and keeps the old PHP number. On Ubuntu 24.04 the fixed package is 8.3.6-0ubuntu0.24.04.13, and PHP still calls itself 8.3.6. Compare the package version, then restart PHP.

Last reviewed 22 October 2026. Rules of 22 October 2026.

Fixed packages

Install the version for your release, or a newer one. The fix is in every binary package of the branch. The website uses the -fpm, -cgi or libapache2-mod-php package, not -cli.

USN-8948-1 lists these binary packages for each branch: php8.3-fpm, php8.3-cgi, php8.3-cli and libapache2-mod-php8.3 (use your branch).

On 20.04 and 18.04 the fix comes through Ubuntu Pro. On 16.04 and 14.04 it needs Ubuntu Pro with the Legacy Support add-on. Without them, apt upgrade does not install the fix. Run pro status to see whether Pro services are on.

See the installed build

# every installed PHP package and its version
    dpkg -l 'php*' 'libapache2-mod-php*' | grep '^ii'
    # installed and candidate version, and where it comes from
    apt policy php8.3-fpm

Use your branch in the package name: php8.1 on 22.04, php8.3 on 24.04, php8.5 on 26.04 and 26.10. A server can have more than one branch, so check each one.

Read the Installed: line of apt policy. If it is lower than the table, the fix is missing. The lines below it show where the package comes from. If it is not an Ubuntu archive (archive.ubuntu.com, security.ubuntu.com or esm.ubuntu.com), for example a PPA, the table does not apply. That PHP uses upstream numbers: compare it with the fixed releases.

Install the update

sudo apt update
    # only the PHP packages that are installed (use your branch)
    sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-cgi libapache2-mod-php8.3
    # or everything
    sudo apt upgrade

--only-upgrade skips packages that are not installed.

Restart PHP

sudo systemctl restart php8.3-fpm
    # Apache with mod_php, or Apache in front of PHP-FPM
    sudo systemctl restart apache2

A running PHP process keeps the old code in memory until it stops. Restart Apache, every PHP-FPM pool and any long-running PHP workers, such as queue workers (php2shell.com). In a container, rebuild the image and recreate the container (our advice).

To see that PHP-FPM started after the update, compare the two times (our advice):

# when the package was upgraded
    zgrep ' upgrade php8.3-fpm' /var/log/dpkg.log*
    # when PHP-FPM last started: must be later
    systemctl show -p ActiveEnterTimestamp php8.3-fpm

php -v does not show the fix

• The number stays the same. Ubuntu keeps the upstream number, such as 8.3.6, before and after the fix. Only the package version shows the fix.
• php -v is the command-line build. It comes from php8.3-cli. The website runs php8.3-fpm, libapache2-mod-php8.3 or php8.3-cgi, which are separate packages. Check the one that serves the site.
• The php command can be another branch. With several branches installed, php can point at 8.3 while the site runs on 8.1.
• A process that did not restart runs the old code. The package can be new while PHP-FPM still runs the old build.

To find what serves the site: ls /run/php/ lists the PHP-FPM sockets, such as php8.3-fpm.sock. apache2ctl -M | grep php shows whether Apache loads mod_php. A short phpinfo() test shows the branch and the Server API.

Check your site

The php2shell.fyi checker reads the PHP version your site shows in public. A header is a hint, not proof. A distribution build often reports an old number, so confirm the package version on the server. A result never proves that a site is not exposed.

Sources

• Ubuntu: USN-8948-1
• Ubuntu: USN-8948-2
• Ubuntu: CVE-2026-109618
• Ubuntu: CVE-2026-109619
• Ubuntu: release cycle
• php.net: Security advisory, 21 October 2026
• php-src: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• php-src: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• php2shell.com: research site