En bref : le dépôt PHP sury est une source tierce largement répandue de paquets PHP pour Debian (packages.sury.org) et Ubuntu (PPA ondrej/php). Il permet plusieurs versions de PHP côte à côte et des branches plus récentes que celles de la distribution. Après PHP2Shell, des builds y ont été fournis, selon des rapports, pour toutes les branches de 5.6 à 8.5. La preuve pour votre serveur ne vient toutefois que du niveau des paquets et du changelog, non des avis de sécurité de Debian ou d'Ubuntu.
Ce qu'est le dépôt sury
Derrière sury.org se trouve Ondřej Surý. Selon la page de son projet, il empaquette en tant que développeur Debian, depuis PHP 5, les paquets PHP pour Debian, et les paquets PHP officiels de Debian et d'Ubuntu reposent sur son travail. En parallèle, il exploite son propre dépôt de paquets PHP qui peuvent être installés côte à côte.
Pour Debian, le dépôt se trouve sous packages.sury.org, pour Ubuntu il est proposé comme PPA ondrej/php. Selon la page du projet, les erreurs se signalent via un suivi des tickets sur Codeberg, non par e-mail. L'entretien se fait, selon ses propres indications, surtout sur son temps libre ; pour les anciennes versions de distributions, il existe une offre commerciale via Freexian.
De nombreux admins et hébergeurs utilisent le dépôt parce qu'il offre des branches PHP plus récentes que celles fournies par la distribution, ou parce que des applications ont besoin d'une version précise.
Ce qui le distingue des paquets Debian
La principale différence pour la sécurité : les paquets de sury.org ne relèvent pas des avis de sécurité de Debian ou d'Ubuntu. Le Debian Security Tracker n'affiche que l'état des paquets officiels. Si l'on y lit que php8.4 est corrigé dans trixie, cela ne dit rien sur un php8.4 de sury.org sur le même serveur.
| Caractéristique | Paquets officiels Debian et Ubuntu | sury.org |
|---|---|---|
| Éditeur | Debian ou Canonical | Ondřej Surý à titre individuel |
| Avis de sécurité | DSA, DLA, USN | aucun de ces avis |
| Versions | une branche par version de distribution | plusieurs branches en parallèle |
| Numéro de version après correction | Debian parfois nouvelle version amont, Ubuntu le plus souvent ancien numéro avec nouveau niveau de paquet | en règle générale version amont actuelle |
| Preuve | avis et changelog | changelog et version du paquet |
Pour les entreprises, cela signifie une dépendance à l'égard d'une personne pour un composant central. Ce n'est pas une raison d'éviter le dépôt, mais une raison d'en assumer le poids en connaissance de cause : avec surveillance, preuve et un plan B.
Le dépôt PHP sury après PHP2Shell : vérifier le niveau
Commencez par clarifier si et pour quels paquets le serveur utilise sury. Les commandes sont en lecture seule.
# sury est-il enregistré comme source de paquets ?
grep -rEl "sury|ondrej" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
# De quelle source provient le paquet installé ?
apt policy php8.3-fpm
# Version installée et entrée du changelog pour les CVE
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
Pour les branches actuelles, vous reconnaissez la correction en règle générale à la version amont 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 dans le nom du paquet. Pour d'anciennes branches comme 7.4 ou 8.1, il n'existe pas de version cible officielle ; l'entrée du changelog y est la principale preuve. Si elle manque, demandez via le suivi des tickets du projet ou traitez le paquet comme non clarifié.
Anciennes branches PHP de sury : un confort trompeur
Le dépôt permet facilement d'exploiter PHP 7.4 ou même 5.6 sur un Debian actuel. Selon des rapports, des builds contre PHP2Shell ont aussi existé pour ces branches. C'est utile pour la situation aiguë, mais ne fait que repousser le problème de fond : le projet PHP n'entretient plus ces branches, et la prochaine faille les touchera de nouveau.
Qui maintient ainsi en vie une ancienne application devrait se demander honnêtement jusqu'à quand. Ce qui vaut pour PHP 8.1 et plus ancien est résumé sur la page PHP 8.1 et plus ancien : ce qui s'applique maintenant. Les alternatives commerciales et leurs limites sont décrites dans l'article Support à long terme pour d'anciennes versions de PHP.
Ne mélangez pas sans contrôle sur un serveur des paquets PHP de la distribution et de sury.org. Des dépendances entre extensions et bibliothèques peuvent entraîner des changements de paquets inattendus lors de la prochaine mise à jour.
Recommandations pour l'exploitation avec sury
- Documenter quels serveurs utilisent sury et pour quelles branches.
- Fixer l'origine, par exemple par APT pinning, afin que les paquets PHP ne viennent que d'une seule source.
- Surveiller les mises à jour, car sans DSA ni USN, l'avis habituel fait défaut. Un recoupement régulier avec
apt list --upgradableaide. - Redémarrer après chaque mise à jour, pour chaque version installée individuellement. Combien tournent en parallèle, l'article Plusieurs versions de PHP sur un serveur le montre.
- Soutenir, si votre entreprise dépend du dépôt. La page du projet cite les dons et le support commercial comme voies.
Retour aux paquets de la distribution ?
Tout serveur qui utilise sury aujourd'hui n'en a pas encore besoin. Souvent, le dépôt a été intégré il y a des années parce que la distribution d'alors n'apportait qu'une version de PHP plus ancienne. Entre-temps, Debian 13 trixie livre par exemple PHP 8.4, qui est, selon le Debian Security Tracker, corrigé contre PHP2Shell. Si votre application fonctionne avec cette version, le retour peut mettre fin à la dépendance à une source tierce.
Le retour est un petit projet de migration. Vérifiez d'abord quelles extensions l'application requiert et si la distribution les propose. Testez l'application avec le paquet de la distribution sur une copie avant de retirer la source sury. Ensuite, les avis de sécurité reviennent par les voies habituelles, et la preuve s'appuie sur DSA ou USN plutôt que sur un simple changelog.
Là où une version plus récente ou plus ancienne que celle de la distribution reste nécessaire, sury demeure un choix judicieux. La décision devrait alors toutefois être prise en connaissance de cause et documentée.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons quels paquets PHP de vos serveurs proviennent de sury.org, de la distribution ou d'autres sources.
- Nous vérifions le niveau PHP2Shell pour chaque branche via la version du paquet et le changelog et redémarrons tous les services.
- Nous mettons en place le pinning et la surveillance des mises à jour et retirons les branches qui ne sont plus nécessaires dans le cadre du durcissement de serveur.
- Pour les anciennes branches, nous planifions le passage à une version prise en charge.
Questions fréquentes
Le dépôt sury est-il un dépôt officiel de Debian ?
Non. Il est exploité par Ondřej Surý qui, selon son propre site, empaquette de longue date PHP pour Debian en tant que développeur Debian. Ce n'est toutefois pas l'archive de sécurité de Debian, et il n'existe pas d'avis de sécurité Debian pour ses paquets.
sury.org a-t-il mis à disposition des paquets contre PHP2Shell ?
Selon des rapports, des builds ont été fournis pour toutes les branches de 5.6 à 8.5. Vérifiez malgré tout vous-même le niveau sur votre serveur via la version du paquet et le changelog, car les rapports ne remplacent pas une preuve pour votre système.
sury.org rend-il à nouveau sûres les anciennes versions de PHP ?
Un build pour une ancienne branche peut fermer une faille précise. Cela ne change rien au fait que le projet PHP n'entretient plus ces branches. Pour une exploitation durablement sûre, le passage à une version prise en charge reste nécessaire.
Comment savoir si mon serveur utilise sury ?
Cherchez sury ou ondrej dans les sources de paquets sous /etc/apt et vérifiez avec apt policy de quelle source proviennent les paquets PHP installés.