Le 21 octobre 2026, l’équipe PHP a rendu publiques deux vulnérabilités critiques pouvant permettre l’exécution de code à distance sans authentification. Référencées CVE-2026-109618 et CVE-2026-109619, elles concernent le moteur PHP utilisé pour servir des sites et des applications web. Les correctifs ont été publiés le même jour dans les branches maintenues.
Chez Gaprod, nous avons pris en charge cette alerte de façon proactive. Les correctifs disponibles ont été déployés sur nos hébergements web et sur les machines infogérées sous notre responsabilité. Les VPS non infogérés restent hors de ce périmètre : leur administration logicielle appartient à leur administrateur.
Que s’est-il passé le 21 octobre ?
L’avis officiel de PHP décrit deux failles distinctes, et non une vulnérabilité propre à WordPress ou à un plugin. La première, CVE-2026-109618, concerne une gestion incorrecte des situations de mémoire insuffisante. PHP peut alors traiter des données internes de requête qui ne sont pas dans un état valide.
La seconde, CVE-2026-109619, concerne des états internes conservés entre plusieurs requêtes traitées par un même processus. Certaines références peuvent pointer vers une mémoire déjà libérée. Les deux avis sont classés critiques, avec un score CVSS v4.0 de 9,2 sur 10. Ce score décrit la gravité technique, pas la probabilité qu’un site précis ait été attaqué.
PHP inclut notamment Apache avec mod_php, PHP-FPM, php-cgi, FrankenPHP et LiteSpeed dans les environnements concernés. Le risque est présenté comme particulièrement élevé avec mod_php. Les conditions d’exploitation diffèrent selon le mode d’exécution, les réglages et l’application : utiliser PHP-FPM ne dispense donc pas de corriger son installation.
Quelles versions de PHP contiennent les correctifs ?
Pour les branches maintenues par le projet PHP, les premières versions corrigées annoncées le 21 octobre sont :
- PHP 8.2.35 pour la branche 8.2 ;
- PHP 8.3.36 pour la branche 8.3 ;
- PHP 8.4.27 pour la branche 8.4 ;
- PHP 8.5.12 pour la branche 8.5.
Les distributions Linux peuvent fournir leurs propres paquets corrigés, avec un numéro différent. Par exemple, l’avis Ubuntu USN-8948-1 indique la révision 8.3.6-0ubuntu0.24.04.13 pour Ubuntu 24.04 LTS. Elle intègre les corrections sans reprendre le numéro de version amont 8.3.36. C’est le principe du rétroportage d’un correctif de sécurité.
Il faut donc consulter l’avis du fournisseur et la révision complète du paquet. Le seul numéro affiché par php -v ne suffit pas toujours à conclure. Pour PHP 8.1 et les branches plus anciennes, la couverture dépend notamment du distributeur ou d’un support prolongé ; elle ne doit pas être présumée.
Comment Gaprod a pris en charge cette alerte
Notre équipe s’est mobilisée dès l’annonce, puis a appliqué les correctifs au fur et à mesure de leur disponibilité pour les environnements concernés. La publication d’une version par PHP et sa mise à disposition dans les dépôts d’un fournisseur ne sont pas nécessairement simultanées. Le suivi publié par CloudLinux illustre cette distinction entre les différentes familles de paquets.
Notre intervention proactive couvre l’ensemble de nos hébergements web et les machines infogérées sous notre responsabilité. Les clients de ces services n’avaient pas à ouvrir un ticket pour déclencher la prise en charge de cette alerte PHP. Cette responsabilité d’exploitation fait partie du périmètre administré par notre équipe, contrairement à un serveur livré sans infogérance.
La vérification ne se limite pas au téléchargement d’un paquet. Il faut également s’assurer que les processus qui servent les requêtes utilisent le logiciel corrigé. Nos contrôles sur les environnements vérifiés ont porté sur les paquets installés et sur les processus en service. Cette démarche évite de confondre une mise à jour présente sur disque avec sa prise en compte réelle par l’application.
Hébergements gérés et VPS non infogérés : deux périmètres distincts
Les correctifs PHP ont été pris en charge pour nos hébergements web et les machines dont nous assurons l’infogérance. Un VPS non infogéré n’est pas inclus dans cette intervention : son administrateur doit vérifier et mettre à jour sa propre pile logicielle.
Vous utilisez un VPS non infogéré : que vérifier ?
Sur un VPS non infogéré, ne considérez pas que le correctif est installé parce que le serveur est hébergé chez nous. Commencez par identifier l’origine de PHP : paquets de la distribution, dépôt tiers, panneau d’administration, conteneur ou compilation manuelle. Consultez ensuite le bulletin correspondant aux versions réellement utilisées par vos sites, pas seulement au PHP de la ligne de commande.
Notre recommandation est de procéder dans cet ordre :
- Vérifier le paquet corrigé recommandé par votre fournisseur pour votre système.
- Appliquer la mise à jour à chaque environnement PHP concerné.
- Renouveler les processus nécessaires conformément aux instructions du fournisseur.
- Contrôler le fonctionnement des sites et applications après l’intervention.
Évitez de remplacer cette opération par une montée de version majeure improvisée. En cas de doute sur le périmètre de votre contrat, contactez le support avant d’entreprendre une modification. Un échange permet de clarifier qui administre le serveur et les interventions à prévoir, sans supposer qu’une prestation d’infogérance est déjà incluse.
Un pare-feu ou une mise à jour WordPress suffisent-ils ?
Non. PHP précise que les mesures de réduction d’exposition ne remplacent pas la mise à jour complète. Une règle de pare-feu applicatif peut filtrer certains scénarios connus sans supprimer le défaut du moteur. De même, mettre à jour WordPress, son thème ou ses extensions ne remplace pas l’application des correctifs PHP au niveau du serveur.
Ces opérations sont complémentaires. Sur un hébergement dont nous administrons PHP, continuez à maintenir votre application et vos accès. Sur un VPS non infogéré, ajoutez à cette maintenance celle de la pile serveur. Une organisation claire des responsabilités évite qu’un correctif soit considéré, à tort, comme le travail de l’autre partie.
Enfin, la publication d’une vulnérabilité ne prouve pas qu’un site a été compromis. À l’inverse, installer son correctif ne démontre pas l’absence d’une intrusion antérieure. Des fichiers inconnus, des connexions suspectes ou des changements inattendus appellent une investigation séparée. Cette communication porte sur la correction de ces deux failles, pas sur une garantie de sécurité absolue.
Pour les entreprises qui souhaitent déléguer cette maintenance, nos hébergements web permettent de distinguer le service administré par Gaprod des responsabilités applicatives du client. L’objectif reste concret : identifier l’alerte, appliquer le bon correctif et vérifier qu’il est réellement utilisé.
Sources officielles
Informations techniques vérifiées le 22 octobre 2026 :
- PHP : avis de sécurité du 21 octobre et versions corrigées.
- Équipe PHP : avis CVE-2026-109618.
- Équipe PHP : avis CVE-2026-109619.
- Ubuntu : bulletin USN-8948-1.
- CloudLinux : suivi des paquets et distinction entre atténuation et correction.
Illustration de couverture conceptuelle : protection et maintenance d’une infrastructure serveur. Il ne s’agit pas d’une photographie de nos installations ni d’un constat d’intrusion.