PHP2Shell on Ubuntu: Fixed Packages, Updates and Ubuntu Pro

As of 23 October 2026, Ubuntu has published fixed PHP packages for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on every Ubuntu release that ships PHP. Ubuntu 26.10, 26.04 LTS, 24.04 LTS and 22.04 LTS get the fix through normal security updates. Ubuntu 20.04 and 18.04 need Ubuntu Pro, and 16.04 and 14.04 need Ubuntu Pro with the Legacy Support add-on.

The short answer for most servers: run sudo apt update && sudo apt upgrade, restart PHP-FPM or Apache, then confirm the installed package version. Do not judge the result by php -v. Ubuntu fixes the bug inside its own packages and keeps its own version numbers, so a fully patched Ubuntu 24.04 server still reports PHP 8.3.6.

This page covers Ubuntu's own PHP packages only. If your PHP comes from the ondrej PPA, a control panel or a container image, the update path is different, and we point you to the right guide below.

Fixed Ubuntu Packages by Release

These are the "Fixed in" versions on Ubuntu's CVE-2026-109618 page, read on 23 October 2026. Ubuntu rates both CVEs "Critical" priority. Support dates come from Ubuntu's release cycle page.

No Ubuntu release ships PHP 8.4 or 8.2, so if you see those on an Ubuntu server, they came from somewhere else. The fixed binary packages in USN-8948-1 include php8.x-fpm, libapache2-mod-php8.x, php8.x-cgi and php8.x-cli. Every one you have installed needs the update, not just the CLI.

Why Ubuntu Still Says PHP 8.3.6

Ubuntu does not move a stable release to a new upstream PHP version. It copies the security fix into the version it already ships. This is called backporting. The upstream fixed release for the 8.3 branch is 8.3.36, but Ubuntu 24.04's fixed package is still PHP 8.3.6 with a higher Ubuntu revision on the end.

So the PHP version number tells you nothing on Ubuntu. What matters is the full package version, including the part after the dash. PHP 8.3.6 with package revision 0ubuntu0.24.04.13 or later is fixed. PHP 8.3.6 with an older revision is not. Our guide to PHP2Shell fixed versions explains backporting across all vendors, and the PHP2Shell version lookup lets you check a specific version string.

A practical consequence: website scanners and some security tools compare version numbers. They may report a patched Ubuntu server as vulnerable to every PHP bug since 8.3.6. That is a false positive, not a missed patch.

How to Update PHP on Ubuntu

Ubuntu's own guidance is short. USN-8948-1 says "In general, a standard system update will make all the necessary changes," and Ubuntu's CVE help page says "We recommend not to cherry-pick updates from individual packages."

1. Take a backup or snapshot if your host offers one.
2. Run the standard update. These are Ubuntu's documented commands:
   sudo apt update && sudo apt upgrade
3. Restart every PHP service that serves websites (next section).
4. Confirm the installed package version against the table above.

On Ubuntu Pro machines you can also let the Pro client do the work. Ubuntu documents sudo pro fix CVE-YYYY-XXXX, which upgrades the affected packages and reports whether the CVE is resolved, and a dry run, pro fix --dry-run CVE-XXXX-XXXX, which changes nothing. For example: pro fix --dry-run CVE-2026-109618, then the same command without --dry-run and with sudo. See Ubuntu's pro fix guide.

What Automatic Updates Did, and What They Did Not

Most Ubuntu servers have automatic security updates switched on. Ubuntu's automatic updates documentation says Ubuntu "will apply security updates automatically, without user interaction" through the unattended-upgrades package, which "is installed by default" and "runs once per day." Ubuntu also says "security updates are never phased," so the fix was not held back for a gradual rollout.

That means a stock Ubuntu server with Ubuntu's own PHP very likely installed the fixed package within a day of 21 October. Two gaps remain:

• Added repositories are skipped. The same page warns: "Just adding another package repository to an Ubuntu system WILL NOT make unattended-upgrades consider it for updates!" PHP from the ondrej PPA was not updated automatically unless someone configured that. Laravel Forge, for example, states that its automatic security updates do not patch PHP for this reason.
• Installing is not restarting. A PHP-FPM or Apache process that started before the update can keep running the old code. Check that the services restarted after the package was installed.

Restart PHP After the Update

PHP's advisory says to restart every worker. On Ubuntu, the PHP-FPM service is named after the PHP branch, and Apache with mod_php is restarted through the Apache service. Examples (replace 8.3 with your version):

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2.service

Restart every PHP-FPM version that serves a site, not only the default one. Our guide to restarting PHP workers covers LiteSpeed, containers and control panels, and shows how to confirm the processes actually restarted.

How to Verify the Fix on Ubuntu

Check the package, not the PHP banner. These are standard commands. The package name is an example; use the one for your release.

dpkg -l 'php8*'
apt changelog php8.3-fpm

The first shows installed package versions to compare with the table. The second shows the package changelog. Ubuntu's fixed changelog for 24.04 includes a "SECURITY UPDATE" entry that names CVE-2026-109618 and CVE-2026-109619, and the same fix was published to noble's security pocket on 21 October 2026 at 13:41 UTC (Launchpad publishing record). If the changelog names both CVEs, the installed package carries the fix.

When this check does not prove anything:

• It only covers that package. If PHP-FPM runs from the PPA or a panel, Ubuntu's changelog for its own package is irrelevant. Our guide on how to check your PHP version shows how to find which PHP binary actually serves your site.
• It does not show the running process. A fixed package on disk with an unrestarted FPM master is still exposed.
• It does not cover CVE-2026-115560, the 23 October informational advisory that affects fully patched PHP releases (see below).

Ubuntu 20.04, 18.04, 16.04 and 14.04: You Need Ubuntu Pro

Older Ubuntu LTS releases are past standard support, and their PHP fixes are marked "Fix available with Ubuntu Pro" in USN-8948-2. 20.04 is covered by Pro until May 2030 and 18.04 until May 2028. 16.04 and 14.04 need the Legacy Support add-on on top of Pro.

Ubuntu says Pro "is and always will be free for personal use on up to 5 physical machines," with a "30-day trial for enterprises." To attach a machine, Ubuntu documents sudo pro attach with your token. Then run sudo pro fix CVE-2026-109618 (example) or the normal apt update and upgrade, and restart PHP as above.

Pro buys time; it does not fix the bigger problem. PHP 7.4, 7.2, 7.0 and 5.5 are years past their upstream end of life, and most current applications no longer support them. Plan the move to a supported Ubuntu release with a supported PHP branch.

PHP From the ondrej PPA or Another Source

Many Ubuntu servers run newer PHP branches from Ondřej Surý's PPA. That PPA published fixed builds for jammy and noble on 21 and 22 October 2026, but it is a separate source with its own version numbers, users reported "503 Service Unavailable" errors from it on the first day, and unattended-upgrades does not update it by default. Our page on Sury and Remi PHP repositories covers it. If you run Debian rather than Ubuntu, see PHP2Shell on Debian.

Control panels such as cPanel or Plesk install their own PHP builds, and the official Docker php images compile PHP from source. An Ubuntu apt upgrade does not touch either.

Who Patches: You or Your Host?

If you have root on an Ubuntu VPS, cloud instance or dedicated server, you patch it. Your hosting company runs the hardware, but the operating system and PHP are yours. If you are on shared or managed hosting, the host patches PHP, and your job is to confirm it with them. Our guide to the shared responsibility model for websites explains where that line usually sits, and our security patching best practices show how to make updates routine rather than an emergency.

After Patching: Keep Upload Progress Off

On 23 October 2026, PHP published an informational advisory for CVE-2026-115560, which affects fully patched releases under an unusual configuration. PHP's advice is: "We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release." Set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration, not with ini_set() or .user.ini, and restart PHP. If you already set it on 21 October, keep it.

Conclusion

As of 23 October 2026, Ubuntu's fix for PHP2Shell is a normal security update on 22.04 and newer, and an Ubuntu Pro update on 20.04 and older. Install it with apt, restart PHP-FPM and Apache, and confirm the package revision or changelog rather than the PHP version banner. If your PHP comes from a PPA or a panel, patch that source too. If you would rather have someone confirm the whole server for you, our emergency PHP patching team can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions