Faille PHP du 21 octobre : on a suivi le sujet de près, voici comment on s’en occupe en direct !

Hier (mardi 20 octobre), l’équipe de sécurité de PHP a annoncé la publication pour le lendemain (aujourd’hui), d’un correctif pour une double faille PHP critique. Le CERT-FR a relayé l’information dans une alerte (CERTFR-2026-ALE-014). Les versions corrigées sont sorties aujourd’hui, mercredi 21 octobre à 16h05. Chez ACSEO, on a vu passer le sujet dès l’annonce, et on s’en occupe en ce moment même.

Si vous avez un site ou une application sous PHP (Symfony, Sylius, WordPress, PrestaShop, Laravel, développement sur mesure…), cet article vous explique ce qu’il se passe, ce qu’on fait de notre côté et ce qui nous attend.

Ce qu’on sait de la faille PHP

Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. Elles sont classées critiques par l’équipe de sécurité de PHP, avec un score CVSS de 9.2 selon les premières analyses. Il s’agit de failles permettant d’exécuter du code à distance sur un serveur : autrement dit, quelqu’un qui les exploite pourrait prendre la main sur la machine qui héberge l’application.

Quelques points à retenir :

• Beaucoup de versions sont concernées. Le CERT-FR indique que toutes les versions de PHP 5.x à 8.x sont touchées. Les correctifs sont disponibles pour les versions maintenues : 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les versions qui ne sont plus maintenues (PHP 8.1 et antérieures) ne recevront pas de correctif officiel.
• Les détails techniques n’ont pas été publiés avant le correctif. Les deux CVE ont été décrites comme « non spécifiées » au départ. Des codes d’exploitation circulent déjà sur internet, mais ils ne sont pas vérifiés, et ils peuvent eux-mêmes contenir des logiciels malveillants.
• Des tentatives d’attaque ont été signalées par des acteurs du secteur. C’est pour ça qu’on ne traîne pas.
• La mise à jour reste la vraie réponse. En attendant les correctifs, le CERT-FR recommandait de désactiver la fonctionnalité upload-progress de PHP ou de filtrer les requêtes de type multipart avec un WAF. C’était un palliatif, pas une solution.

Ce qu’on fait chez ACSEO

On ne gère pas ce genre de sujet seuls. Une grande partie des applications qu’on développe et qu’on maintient sont hébergées et infogérées chez nos partenaires. Dès l’annonce, on a travaillé avec eux sur trois points :

1. Identifier ce qui est concerné. On recense les applications clientes qui tournent sous PHP, avec la version utilisée et l’environnement (production, préproduction…).
2. Appliquer les correctifs recommandés. On a d’abord vérifié que les applications n’utilisaient pas la fonctionnalité upload-progress, puis on a demandé à nos partenaires hébergeurs et infogérants de la désactiver en attendant les correctifs. Les versions corrigées étant sorties, on fait installer les mises à jour, en commençant par les applications les plus exposées.
3. Contacter les clients concernés, individuellement. Pas de mail générique envoyé à tout le monde. Quand une application demande une action particulière (une montée de version PHP, un test de non-régression, une fenêtre de maintenance à caler), on prend contact directement avec les équipes concernées pour en parler et décider ensemble.

« Dès l’alerte du CERT-FR reçue, j’ai prévenu par mail mes clients qui ont une application PHP afin de les informer que les failles révélées pouvaient les impacter et que l’on allait prendre les mesures nécessaires avec l’hébergeur. Les équipes ont ensuite validé que les applications n’utilisaient pas la fonctionnalité upload-progress, ce qui nous a permis de faire des tickets auprès des hébergeurs concernés jusqu’en début d’après-midi pour les derniers. Nos échanges avec les hébergeurs nous ont permis de voir que la plupart d’entre eux étaient déjà sur le sujet, afin de mettre en place les éléments de manière globale sur leurs infrastructures. Heureusement, toutes les applications que je gère sont au minimum en version 8.2 : on n’a pas de mise à jour majeure à prévoir en urgence. On attend à l’heure actuelle l’installation des versions corrigées. »

Romain tech-lead chez ACSEO

La TMA, ça sert à ça !

Ce type d’alerte, c’est exactement pour ça qu’on propose de la TMA (tierce maintenance applicative). Une application ne s’arrête pas de vivre une fois en production : les versions de PHP, de Symfony, de WordPress ou des bibliothèques évoluent, et de temps en temps une faille tombe en pleine semaine.

Avec un contrat de TMA, quelqu’un suit les alertes de sécurité, sait quelle application tourne sur quelle version, et peut agir vite avec les bons interlocuteurs côté hébergement. C’est ce qui nous permet d’être prêts quand ça arrive, et d’aller vers nos clients avant qu’ils se posent la question.

Le suivi des versions ne se fait pas seulement les jours d’alerte. Chez ACSEO, nos TMA incluent un temps de maintenance préventive, qui permet de faire régulièrement le point sur les versions à maintenir à jour pour continuer de recevoir les correctifs de sécurité. Une version qui n’est plus maintenue n’en reçoit plus, et sur un sujet comme celui-ci, ça change tout.

Et si vous n’avez pas encore été contacté ?

Si vous êtes client ACSEO et que votre application est concernée, vous allez être contacté par votre interlocuteur habituel. Si vous avez une question, ou si vous voulez simplement qu’on vérifie la version de PHP de votre site, vous pouvez écrire directement à votre chef de projet, ou passer par notre formulaire de contact ou envoyer un email à contact@acseo.fr.

Si vous n’êtes pas encore client mais que ce sujet vous inquiète, on peut aussi vous aider : audit de code Symfony, audit de la version PHP, plan de montée de version, mise en place d’une TMA.

On continue de suivre l’évolution de la faille et on mettra cet article à jour si nécessaire.