Le 21 octobre 2026, le CERT-EU a publié l’avis 2026-018 sur deux failles critiques de PHP. Nous avons corrigé les services de nos clients par nos pipelines de déploiement, arrêté les applications que nous ne pouvions pas corriger, puis envoyé un rapport à chaque client. Cet article explique comment, et pourquoi cette méthode fait partie de notre offre.
Ce que dit l’avis du CERT-EU
L’avis CERT-EU 2026-018 décrit deux vulnérabilités :
| Faille | Score CVSS | Effet |
|---|---|---|
| CVE-2026-109618 | 9,2 | Exécution de code à distance par corruption de mémoire, quand PHP gère un dépassement de memory_limit (par exemple pendant la lecture d’un fichier envoyé). |
| CVE-2026-109619 | 9,2 | Exécution de code à distance par un état interne qui reste en mémoire après une erreur fatale et qui est réutilisé par la requête suivante. |
Trois points rendent ces failles graves :
- Aucune authentification n’est nécessaire. Une seule requête peut déclencher la faille, avant même l’exécution du code de l’application.
- Tous les modes d’exécution sont touchés : PHP-FPM, Apache avec
mod_php,php-cgi, FrankenPHP et LiteSpeed. - Des preuves de concept circulent déjà. Le CERT-EU considère comme probable que des attaquants exploitent déjà ces failles.
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les versions plus anciennes ne sont plus maintenues et ne recevront pas de correctif.
Le CERT-EU recommande de mettre à jour au plus vite. Quand ce n’est pas possible, il recommande de retirer d’Internet les services exposés jusqu’à ce que le correctif soit appliqué et vérifié.
Les services concernés chez nos clients
PHP fait tourner une grande partie des services que nous opérons :
- les sites et plateformes WordPress ;
- les webmails ;
- des applications métier écrites en PHP, dont certaines sont fournies par des éditeurs tiers.
Chacun de ces services est exposé sur Internet. Chacun était donc concerné.
Notre réponse en cinq étapes
1. Détecter
Nous suivons les avis du CERT-EU et des éditeurs. Notre inventaire indique, pour chaque service, la version de PHP qu’il utilise. Nous avons donc obtenu en peu de temps la liste des services à corriger.
2. Qualifier
Pour chaque service, nous avons répondu à une question : existe-t-il une version corrigée de PHP compatible avec ce service ?
- Oui : le service passe par le pipeline de correction.
- Non : le service tourne sur PHP 8.1 ou plus ancien, ou dépend d’un éditeur qui n’a pas encore publié de version compatible. Il passe à l’étape d’isolation.
3. Corriger par le pipeline
Nos déploiements sont automatisés dans GitLab CI/CD. Une mise à jour de sécurité suit le même chemin qu’une mise à jour courante :
- Le pipeline construit une image avec la version corrigée de PHP.
- Il déploie cette image sur un environnement de test et lance les contrôles automatiques.
- Il déploie en production.
- Il vérifie la version de PHP réellement en service.
- Il conserve la trace de chaque étape : qui a lancé le déploiement, quand, et avec quel résultat.
Parce que ce chemin sert tous les jours, il était prêt le jour de l’alerte. Nous n’avons pas eu à corriger les serveurs un par un à la main.
4. Isoler ce qui ne peut pas être corrigé
Une application que nous ne pouvons pas corriger reste vulnérable. Nous l’avons arrêtée ou retirée d’Internet, comme le recommande le CERT-EU. Elle restera hors ligne jusqu’à ce qu’une version corrigée soit disponible et vérifiée.
Arrêter un service a un coût pour le client. Laisser en ligne un service exploitable sans authentification a un coût plus élevé. Nous avons appliqué cette règle à tous les clients.
5. Informer chaque client
Chaque client a reçu un rapport qui indique :
- les services concernés ;
- les services corrigés, avec la version de PHP en service ;
- les services arrêtés ou isolés, et la raison ;
- les actions qui restent à faire, et qui doit les faire.
Pourquoi cette méthode fait partie de l’offre
Pour nous, le cloud n’est pas une technologie ni un outil. C’est un ensemble : des technologies maîtrisées, des processus d’exploitation, et la sécurité intégrée à ces processus.
Cet incident montre ce que cela change en pratique :
- BUILD : les services sont construits pour être redéployés par un pipeline. C’est ce qui permet de changer la version de PHP partout de la même façon.
- RUN : l’inventaire, la supervision et les pipelines sont utilisés tous les jours. Le jour d’une alerte, ils fonctionnent déjà.
- SECURE : la veille, la qualification et la décision d’isoler suivent une procédure écrite. Le rapport au client fait partie de la procédure.
C’est ce que nous appelons opérer son informatique comme un cloud. La Cloud & AI Factory installe ce fonctionnement chez nos clients, sur leur propre infrastructure.
Ce que vous pouvez vérifier chez vous dès aujourd’hui
- Listez tous vos services qui exécutent PHP, y compris dans des logiciels d’éditeurs.
- Pour chacun, relevez la version de PHP en service.
- Passez en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre branche.
- Pour les services en PHP 8.1 ou plus ancien, retirez-les d’Internet en attendant une migration.
- Vérifiez la version réellement en service après le déploiement, pas seulement celle du paquet installé.
Si vous ne pouvez pas répondre aux deux premières questions en moins d’une heure, c’est le point à traiter en premier.
Vous voulez savoir comment appliquer cette méthode à votre infrastructure ? Contactez-nous.
Source : CERT-EU, avis de sécurité 2026-018 « Critical Vulnerabilities in PHP », publié le 21 octobre 2026.