PHP2Shell and Third-Party PHP Repos: Sury (ondrej) and Remi

As of 23 October 2026, both of the big third-party PHP repositories have fixed PHP2Shell builds. Ondřej Surý's repositories (packages.sury.org and the ondrej/php PPA) carry PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, plus backported builds for PHP 5.6 through 8.1. Remi's repository carries 8.2.35 to 8.5.12 for Fedora and Enterprise Linux, plus backported 7.4, 8.0 and 8.1 builds.

The direct answer: if your server gets PHP from one of these repositories, your operating system's automatic updates may not have installed the fix. Update the PHP packages yourself, restart PHP, and check the installed version. One trap to know about: Sury's PHP 8.6 test builds are still on release candidate 3, which does not contain the fix.

You probably use one of these repositories if your server runs a PHP version your distribution doesn't ship, or several versions side by side. Many server-management tools install PHP from Sury, including Laravel Forge and HestiaCP.

Why Third-Party Repos Need Extra Attention

A package repository is a server that your operating system downloads software from. Ubuntu and Debian come with their own. Sury and Remi are separate repositories, run by long-time PHP packagers, that you add on top.

That matters for PHP2Shell in two ways:

• Automatic updates may skip them. Ubuntu installs its own security updates once a day through unattended-upgrades, but its automatic updates documentation warns that an added repository is not included unless you configure it. Laravel Forge says the same about its servers: "Ubuntu's unattended upgrades only apply updates from Ubuntu's own security repository. You must update PHP on each of your servers yourself."
• The version numbers follow different rules. Ubuntu's own php8.3 on 24.04 is fixed at 8.3.6-0ubuntu0.24.04.13. Sury's php8.3 is fixed at 8.3.36. Same package name, different numbering. You need to know which one you have.

To see where a package comes from, use apt-cache policy php8.3-fpm (replace 8.3 with your version). It lists the installed and candidate versions and the repository each one comes from. Forge's own guidance uses the same command: "The Candidate version should match the fixed version."

Sury: Fixed Versions

Ondřej Surý is a Debian developer who maintains Debian's own PHP packages. His site says "The PHP packages in my Ubuntu PPA and Debian DPA matches the official packages in Debian." He publishes PHP in two places: the ondrej/php PPA on Launchpad, for Ubuntu, and packages.sury.org, which serves Debian (trixie, bookworm, bullseye) and, as of 23 October, Ubuntu suites too (noble, jammy, resolute).

The fixed builds in packages.sury.org, read on 23 October 2026, are the same across those suites apart from a suffix:

The changelogs for Sury's 5.6, 7.4 and 8.1 builds name the fix directly: "[CVE-2026-109618, CVE-2026-109619]: Avoid state corruption via bailout." The 5.6, 7.0 and 7.1 packages were rebuilt again on 22 October. The 5.6 rebuild adds an older fix, "Backported from 8.0.28 + [CVE-2023-0662]", so if you installed 5.6.40-104 on 21 October, update again. The changelog for 5.6.40-105 is on Launchpad.

Sury serves fixed builds even for Debian 11 bullseye, which Debian itself now covers only through paid extended support. Backported end-of-life builds are a stopgap. The branches still get no other upstream fixes, so plan the move to 8.2 or newer. Our security patching best practices guide covers how to schedule and test that kind of upgrade.

The PHP 8.6 Release Candidate Trap

PHP 8.6 is not out yet. PHP's own 8.6.0 RC4, released 21 October, "contains the fixes for two critical vulnerabilities," and PHP says "Everyone running earlier builds of PHP 8.6.0 is strongly encouraged to update immediately."

As of 23 October 2026, Sury's php8.6 is still 8.6.0~rc3, published 12 October, in both packages.sury.org and the PPA. Anyone testing PHP 8.6 from Sury is running an unfixed build. Keep those machines off the public internet, or remove php8.6 until a fixed build appears. Remi's repository did move to 8.6.0 RC4 on 23 October.

Sury: How to Update and Verify

Sury packages update through apt like any other package:

sudo apt update && sudo apt upgrade

Then restart PHP for each version you have installed, for example sudo systemctl restart php8.3-fpm (replace 8.3 with your version), or Apache if you use mod_php. Forge's advice applies to every Sury server: repeat for "every PHP version installed on the server, including versions that your sites do not currently use."

To verify:

1. Run apt-cache policy php8.3-fpm and check that the installed version matches the table above.
2. For 8.2 to 8.5, php8.3 -v and php-fpm8.3 -v should show the fixed upstream number (8.3.36 here). The command-line PHP and the FPM binary are checked separately because they can differ.
3. For the backported 5.6 to 8.1 builds, the version banner does not change. Check the package changelog instead: Debian's security FAQ says to use apt-get changelog with the package name "and search for the entry announcing the fix."

Day-one problems to know about. On 21 October the Launchpad PPA returned "503 Service Unavailable" for some users, and HestiaCP staff advised moving to packages.sury.org. Ploi's status page said packages.sury.org "gets the builds first." ARM builds also lagged by hours. If an update failed on 21 October, run it again. If you decide to switch from the PPA to packages.sury.org, follow the setup instructions on deb.sury.org or in your server tool's official documentation, and remove the old repository entry so the two don't conflict.

The Ubuntu and Debian pages in this series cover the distribution's own packages: see PHP2Shell on Ubuntu and PHP2Shell on Debian.

Remi: Fixed Versions

Remi Collet maintains rpms.remirepo.net, the most widely used third-party PHP repository for Fedora and the RHEL family (RHEL, AlmaLinux, Rocky Linux and CentOS). His release post dated 22 October 2026 says: "These Versions fix 2 critical security bugs (CVE-2026-109618, CVE-2026-109619)."

The release post itself lists only the four supported branches. The 7.4, 8.0 and 8.1 builds are in the repository, and their changelogs read: "Mitigation fix Avoid state corruption via bailout CVE-2026-109618, CVE-2026-109619." We checked the base (modular) packages. We did not check whether the remi-safe Software Collection packages for those old branches were also rebuilt.

You may have read that Remi "will not have updates on release day." The repository listings date the fixed files 21 October, with the announcement on 22 October. Either way, they are there now.

Remi: How to Update and Verify

Remi documents these commands in the release post. Replace 8.5 with the branch you use.

dnf module switch-to php:remi-8.5/common (Enterprise Linux, dnf 4)

dnf module reset php
dnf module enable php:remi-8.5
dnf update (Fedora, dnf 5)

yum install php85 (Software Collection)

If you already run the branch you want, a regular dnf update picks up the new build. Then restart PHP. On the RHEL family the base FPM service is php-fpm, so sudo systemctl restart php-fpm, or sudo systemctl restart httpd for mod_php. Software Collections use their own service names, which we have not verified. Check yours with systemctl list-units | grep fpm rather than guessing.

Verifying Remi builds has its own trap. The rebased 8.2 to 8.5 packages say only "Update to 8.3.36" in their RPM changelog, with no CVE ID. So rpm -q --changelog php-common | grep CVE-2026-109618 returns nothing on a fixed 8.3.36 build. Check the version with rpm -q php-common instead. On the 7.4, 8.0 and 8.1 backports, the changelog grep does work. Red Hat's own rebased packages behave the same way; our RHEL, Rocky and Oracle Linux guide explains it.

Restart, Then Confirm What Serves Your Site

The repository is only half the job. Every PHP worker started before the update keeps running the old code. Our guide to restarting PHP workers covers every setup and how to confirm the restart happened. Then check the PHP that actually serves pages, not just the command line, using our guide on how to check your PHP version. The PHP2Shell version lookup tells you whether a given number is a fixed one.

Third-party repositories are part of your software supply chain, like plugins and packages. Our guide to plugin, app and package supply chain security covers how to keep track of what you have added.

Paid Support for Old Branches

Both maintainers do this work largely as volunteers. Sury's site says he does it "mostly in my free time" and asks businesses to "consider buying commercial support from Freexian." Freexian's paid PHP LTS works with deb.sury.org and says its customers got PHP2Shell fixes "on the day of the coordinated disclosure." If your business depends on an end-of-life PHP branch from these repositories, paid support or an upgrade is the safer plan.

Conclusion

As of 23 October 2026, Sury and Remi both offer fixed PHP2Shell builds for every supported branch and for several end-of-life ones. Your operating system may not install them on its own, so update the PHP packages, restart every PHP version, and verify by version (Sury 8.2 to 8.5, Remi 8.2 to 8.5) or by changelog (the backports). Leave Sury's PHP 8.6 RC3 off public servers. If you run many servers on these repositories and want a second pair of hands, our emergency PHP patching team can patch and verify them. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions