PHP2Shell on Debian: Fixed Packages, LTS and ELTS

As of 23 October 2026, Debian has fixed PHP2Shell (CVE-2026-109618 and CVE-2026-109619) in its two supported releases. Debian 13 trixie's php8.4 is fixed in 8.4.27-1~deb13u1 (DSA-6574-1), and Debian 12 bookworm's php8.2 is fixed in 8.2.35-1~deb12u1 (DLA-4848-1). Testing (forky) and unstable (sid) have php8.4 8.4.27-1.

Older releases are a different story. Debian 11 bullseye, Debian 10 buster and Debian 9 stretch get the fix only through Freexian's Extended LTS (ELTS), a commercial subscription. The regular Debian archive has no PHP2Shell fix for them.

For a supported Debian server, the answer is short: run sudo apt update && sudo apt upgrade, restart PHP-FPM or Apache, and compare the installed package version with the advisory. This page explains which channel covers your release, how to verify, and where the checks stop proving anything.

Debian's Fixed PHP Packages by Release

Versions come from the Debian security tracker and Freexian's advisories, read on 23 October 2026. Support dates come from Debian's release table.

A note on the record: debian.org's release table still labels bullseye "under LTS support" even though its End of LTS date has passed. Freexian's tracker shows the regular bullseye-security package as vulnerable, so treat bullseye as ELTS-only.

Security Team, LTS and ELTS: Who Fixes Your Release

Debian has three layers of security support, and PHP2Shell landed in all three:

• The Debian Security Team covers the current stable release, trixie. Its advisories are DSAs.
• Debian LTS extends releases to at least five years. Debian says it "is not handled by the Debian security team, but by a separate group of volunteers and companies." Its advisories are DLAs. Bookworm's first three years of full support ended on 11 July 2026, which is why its PHP2Shell fix is DLA-4848-1. LTS "is limited to i386, amd64, armhf, arm64 and ppc64el," so bookworm on any other architecture has no fix.
• Freexian ELTS goes beyond LTS, up to ten years. Freexian describes it as a subscription that gives access to "a private repository containing the security updates," and it supports "only the packages used by the customers." Its advisories are ELAs.

If you run bookworm on a supported architecture with Debian's normal security sources, you do not need to change anything. The tracker lists the fix in "bookworm (security)", so a regular apt upgrade picks it up.

How to Update PHP on Debian

1. Take a backup or snapshot first.
2. Install the update with the standard commands:
   sudo apt update && sudo apt upgrade
3. Restart every PHP service that serves a site. Examples (replace 8.4 with your version):
   sudo systemctl restart php8.4-fpm
   sudo systemctl restart apache2
4. Confirm the installed version against the table.

Debian names the PHP-FPM service after the branch (php8.4-fpm on trixie, php8.2-fpm on bookworm). If Apache runs PHP as mod_php, restart Apache fully rather than with a graceful reload. Debian's own mod_php package uses a full restart when it reconfigures Apache. Our guide to restarting PHP workers covers every setup and shows how to confirm the processes are new.

How to Verify the Fix on Debian

Debian's security FAQ gives two methods: "looking at the package changelog, or comparing its exact version number with the version indicated in the Debian Security Advisory." It adds that "you can check the package changelog with apt-get changelog package-name and search for the entry announcing the fix." Examples:

dpkg -l 'php8*'
apt-get changelog php8.4-fpm

On trixie, the fixed changelog entry reads "New upstream version 8.4.27" followed by "(CVE-2026-109618, CVE-2026-109619): Avoid state corruption via bailout." Because trixie and bookworm moved to the upstream fixed releases (8.4.27 and 8.2.35), php -v on those packages also shows a fixed upstream number. That is not true on every Debian system:

• Bullseye and older ELTS packages are backports. The fixed bullseye package still reports PHP 7.4.33. Compare the full package version (7.4.33-1+deb11u14) with Freexian's advisory.
• Third-party packages have their own versions. PHP from packages.sury.org carries version strings such as 8.4.27-1+0~20261021.57. Debian's advisory does not describe those builds.
• A fixed package does not mean a fixed process. A worker that started before the upgrade still runs the old code until it restarts.

Our guide on how to check your PHP version explains how to find the PHP that actually serves your website, and the PHP2Shell version lookup checks a version string for you.

Debian 11 Bullseye and Older: Your Options

Bullseye ships PHP 7.4, which has been end of life upstream since November 2022. You have three realistic paths:

1. Freexian ELTS. The fixed php7.4 package is 7.4.33-1+deb11u14 (ELA-1853-1, 21 October 2026). Freexian's setup guide warns that when you add the ELTS repository "you should at the same time disable the Debian repositories," because they are likely to break over time.
2. Ondřej Surý's packages.sury.org. It serves fixed builds of PHP 5.6 through 8.5 for bullseye as well as bookworm and trixie. This is a third-party repository, and moving to a newer PHP branch is an application change, not a security update.
3. Upgrade the operating system. Moving to bookworm or trixie gets you a supported PHP from Debian itself. This is the long-term fix, and it needs testing, because PHP 7.4 to 8.2 or 8.4 is a large jump for older code.

If none of these is possible right away, follow PHP's interim mitigations and consider taking the site offline, as CISA advises for systems that cannot be updated. Our guide to upgrading old PHP safely covers the application side.

PHP From packages.sury.org on Debian

Many Debian servers run newer PHP branches from Ondřej Surý's repository. As of 23 October it has fixed php8.2 to php8.5 builds dated 21 October, plus rebuilt EOL branches. Two cautions: php8.6 there is still RC3, which does not contain the fix (PHP says RC4 does), and the version strings are Sury's own. Our page on Sury and Remi PHP repositories covers both repos. On Ubuntu instead of Debian, see PHP2Shell on Ubuntu.

Who Patches: You or Your Host?

If you have root on a Debian server, you patch it, whether it is a VPS, a cloud instance or hardware in a rack. On shared and managed hosting, the host updates PHP and you confirm. Our guide to the shared responsibility model explains where that line usually falls. Control panels and the official Docker php images bring their own PHP builds, which Debian's apt does not update. Our security patching best practices explain how to keep this routine.

After Patching: Keep Upload Progress Off

PHP's 23 October informational advisory for CVE-2026-115560 covers fully patched releases under an unusual configuration. PHP's advice is to "set session.upload_progress.enabled=0 until the next regular bugfix release." Put session.upload_progress.enabled=0 in php.ini or the FPM pool configuration (not ini_set() or .user.ini) and restart PHP. If you set it on 21 October, leave it in place.

Conclusion

As of 23 October 2026, Debian trixie and bookworm have fixed PHP packages through the normal security archive, and bullseye and older releases are covered only by Freexian ELTS or third-party builds. Update with apt, restart every PHP-FPM version and Apache, and verify the exact package version against DSA-6574-1, DLA-4848-1 or the ELA for your release. If you need help with an older server or an upgrade path, our emergency PHP patching team can work through it with you. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions