In short: The sury PHP repository is a widely used third-party source for PHP packages on Debian (packages.sury.org) and Ubuntu (PPA ondrej/php). It allows several PHP versions side by side and newer branches than the distribution. After PHP2Shell, according to reports, builds were provided there for all branches from 5.6 to 8.5. Proof for your server, however, comes only from package version and changelog, not from the security announcements of Debian or Ubuntu.
What the sury repository is
Behind sury.org is Ondřej Surý. According to his project page, he has packaged the PHP packages for Debian as a Debian developer since PHP 5, and the official PHP packages of Debian and Ubuntu are based on his work. Alongside this work, he runs a repository of his own with PHP packages that can be installed in parallel.
For Debian the repository is at packages.sury.org; for Ubuntu it is offered as the PPA ondrej/php. According to the project page, bugs are reported via an issue tracker on Codeberg, not by email. By his own account, maintenance is done mostly in his free time; for older distribution versions there is a commercial offering via Freexian.
Many admins and hosting providers use the repository because it offers newer PHP branches than the distribution ships, or because applications need a particular version.
What distinguishes it from the Debian packages
The most important difference for security: packages from sury.org do not fall under the security announcements of Debian or Ubuntu. The Debian Security Tracker only shows the status of the official packages. If it says there that php8.4 in trixie is corrected, that says nothing about a php8.4 from sury.org on the same server.
| Feature | Official Debian and Ubuntu packages | sury.org |
|---|---|---|
| Publisher | Debian or Canonical | Ondřej Surý as an individual |
| Security announcements | DSA, DLA, USN | none of these announcements |
| Versions | one branch per release | several branches in parallel |
| Version number after fix | Debian partly new upstream version, Ubuntu mostly old number with new package version | generally current upstream version |
| Proof | announcement and changelog | changelog and package version |
For companies, this means depending on an individual for a central component. That is no reason to avoid the repository, but it is a reason to bear the dependency consciously: with monitoring, proof and a plan B.
The sury PHP repository after PHP2Shell: checking the status
First, establish whether and for which packages the server uses sury. The commands are purely read-only.
# Is sury registered as a package source?
grep -rEl "sury|ondrej" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
# Which source does the installed package come from?
apt policy php8.3-fpm
# Installed version and changelog entry for the CVEs
dpkg-query -W -f='${Package}\t${Version}\n' 'php*-fpm' 'libapache2-mod-php*' 2>/dev/null
zgrep -E "CVE-2026-10961[89]" /usr/share/doc/php8.3-fpm/changelog.Debian.gz
For current branches, you can generally recognise the fix by the upstream version 8.5.12, 8.4.27, 8.3.36 or 8.2.35 in the package name. For old branches such as 7.4 or 8.1 there is no official target version; there, the changelog entry is the most important evidence. If it is missing, ask via the project's issue tracker or treat the package as unresolved.
Old PHP branches from sury: a deceptive comfort
The repository makes it easy to run PHP 7.4 or even 5.6 on a current Debian. According to reports, builds against PHP2Shell were also provided for these branches. That is helpful for the acute situation but merely postpones the basic problem: the PHP project no longer maintains these branches, and the next vulnerability will hit them again.
Anyone keeping an old application alive this way should ask themselves honestly for how much longer. What applies to PHP 8.1 and older is summarised on the page PHP 8.1 and older: what applies now. Commercial alternatives and their limits are described in the article Long-term support for old PHP versions.
Do not mix PHP packages from the distribution and from sury.org on one server in an uncontrolled way. Dependencies between extensions and libraries can lead to unexpected package switches at the next update.
Recommendations for operating with sury
- Document which servers use sury and for which branches.
- Fix the origin, for example with APT pinning, so that PHP packages come from only one source.
- Monitor updates, because without a DSA or USN the usual notice is missing. A regular check of
apt list --upgradablehelps. - Restart after every update, individually for each installed version. How many run in parallel is shown by the article Several PHP versions on one server.
- Support the project if your company depends on the repository. The project page names donations and commercial support as options.
Back to the distribution packages?
Not every server that uses sury today still needs it. The repository was often added years ago because the distribution at the time only shipped an older PHP version. Meanwhile, Debian 13 trixie, for example, ships PHP 8.4, which according to the Debian Security Tracker is corrected against PHP2Shell. If your application runs with this version, going back can end the dependence on a third-party source.
Going back is a small migration project. First check which extensions the application needs and whether the distribution offers them. Test the application with the distribution package on a copy before you remove the sury source. After that, security announcements come again via the usual routes, and the proof rests on DSA or USN rather than on a changelog alone.
Where a newer or older version than the distribution's remains necessary, sury is still a sensible choice. But the decision should then be made deliberately and documented.
How does PHP SOS help?
- We establish which PHP packages on your servers come from sury.org, from the distribution or from other sources.
- We check the PHP2Shell status per branch via package version and changelog and restart all services.
- We set up pinning and update monitoring and remove branches no longer needed as part of server hardening.
- For old branches, we plan the move to a supported version.
Frequently asked questions
Is the sury repository an official Debian repository?
No. It is operated by Ondřej Surý, who, according to his own site, has long packaged PHP for Debian as a Debian developer. But it is not Debian's security archive, and there are no Debian security announcements for its packages.
Has sury.org provided packages against PHP2Shell?
According to reports, builds were provided for all branches from 5.6 to 8.5. Still check the status on your server yourself via package version and changelog, because the reports are no substitute for proof for your system.
Does sury.org make old PHP versions safe again?
A build for an old branch can close a specific vulnerability. It changes nothing about the fact that the PHP project no longer maintains these branches. For permanently safe operation, moving to a supported version remains necessary.
How do I find out whether my server uses sury?
Search the package sources under /etc/apt for sury or ondrej and use apt policy to check which source the installed PHP packages come from.