L’essentiel
- Le 22 octobre 2026, le projet PHP publie notamment les versions 8.4.27 et 8.3.36 avec des correctifs de sécurité sur le cœur du langage.
- Sur Debian et Ubuntu, une part importante des mises à jour passe par les paquets DEB.SURY.ORG et le PPA ondrej/php, maintenus par Ondřej Surý en activité bénévole.
- Sur les branches PHP que le projet ne corrige plus officiellement, des backports peuvent arriver via ce canal — ou ne pas arriver du tout sur certaines combinaisons OS.
- Pour une PME, la question n’est pas seulement « avons-nous patché ? », mais « par quel chemin le patch nous atteint-il, et qui le garantit ? ».
Votre prestataire vous annonce une faille sur le serveur qui héberge votre site ou votre application métier. Vous demandez quand la mise à jour sera appliquée. Il répond : « dès que le paquet est dispo sur le dépôt. » Vous ne savez pas quel dépôt. Vous ne savez pas non plus si votre version de PHP est encore maintenue par l’éditeur du langage ou seulement par un empaqueteur tiers. Pourtant, c’est ce détail qui fixe le délai — et parfois l’impossibilité — de corriger.
Deux mondes : le code PHP et le paquet sur votre serveur
Quand le projet PHP publie une version corrigée, ce n’est pas un bouton « mettre à jour » sur votre machine. Sous Debian ou Ubuntu, il faut un paquet `.deb` : dépendances, scripts d’installation, configuration par défaut. Beaucoup d’hébergeurs et de PME qui gèrent encore un serveur Linux passent par les dépôts DEB.SURY.ORG (Debian) ou le PPA ondrej/php (Ubuntu), qui permettent d’installer plusieurs versions de PHP côte à côte, souvent plus récentes que celles figées dans la version stable de la distribution.
Mi-octobre 2026, une publication de correctifs sur PHP — dont des failles d’exécution de code à distance très sévères, parfois surnommées « PHP2Shell » dans la presse — a rappelé ce mécanisme : pour une large partie des administrateurs concernés, la mise à jour est arrivée via les paquets publiés par Ondřej Surý, mainteneur bénévole, ingénieur DNS à l’Internet Systems Consortium à côté de ce travail d’empaquetage.
Ce que fait — et ne fait pas — le mainteneur
Surý n’écrit pas le correctif à la source : il transforme les releases du projet PHP en paquets installables, gère les dépendances et peut rétroporter des correctifs vers des branches que PHP ne maintient plus officiellement, lorsque des backports sources existent. Silicon.fr décrit ainsi des mises à jour pour des branches allant de PHP 5.6 à 8.1, là où une simple `apt upgrade` sur le dépôt par défaut ne suffirait pas. Le changelog du paquet php8.4 mentionne explicitement les correctifs de sécurité de la release 8.4.27 du 22 octobre 2026.
La même logique a des trous : certaines combinaisons très anciennes — Silicon.fr cite PHP 7.2 sur Ubuntu 20.04 dans le PPA — restent sans mise à jour par ce canal. Autrement dit : « on a un dépôt tiers » n’équivaut pas à « toutes nos versions sont couvertes ».
Ce qu’un dirigeant peut exiger de son infogéreur
- Inventaire : version exacte de PHP, provenance du paquet (distribution officielle, Sury, autre), OS et fin de support.
- Chaîne de patch : qui publie le correctif (projet PHP), qui le transforme en paquet, sous quel délai observé lors du dernier incident.
- Plan B : si la branche n’est plus corrigée, migration ou contournement documenté — pas une promesse vague « on verra ».
- Preuve : date de la dernière mise à jour appliquée sur les serveurs qui portent des données clients ou des accès exposés sur Internet.
Si vous hébergez encore une application PHP et que vous n’avez jamais clarifié qui livre vos mises à jour, on peut en parler calmement.
Sources
Cette note a été rédigée avec l’aide d’outils d’intelligence artificielle à partir des sources citées, puis relue et publiée sous la responsabilité de Jordan FOUASSIER, directeur de la publication. Nous résumons les faits et proposons notre lecture ; les textes et visuels des sources ne sont pas reproduits. Une erreur ? Écrivez à contact@aigyrosgroup.com.