Deux failles critiques PHP : que faire pour protéger votre site ?

Les avis de sécurité PHP identifient CVE-2026-109618, liée au traitement d’un manque de mémoire, et CVE-2026-109619, liée à un état interne conservé entre des requêtes. Toutes deux sont classées critiques, avec un score CVSS v4 de 9,2 sur 10. Une exploitation réussie peut permettre l’exécution de code sur un serveur vulnérable sans authentification.

Le risque concerne les installations PHP qui traitent des requêtes Web, notamment PHP-FPM, Apache avec mod_php, CGI, FrankenPHP et LiteSpeed. Les conditions d’exploitation varient selon l’environnement. Le CERT-FR signalait le 22 octobre des preuves de concept pour certains déploiements ; cela ne permet pas de compter les sites effectivement compromis.

Au 23 octobre 2026, W3Techs estime que PHP est utilisé par 69,3 % des sites dont le langage côté serveur est connu. Ce périmètre compte : il ne s’agit ni de tous les sites du Web, ni d’un inventaire des installations encore vulnérables.

Pour votre entreprise, la question utile est donc celle de votre propre installation. Un logo WordPress, une page qui répond normalement ou une version affichée dans un outil public ne suffisent pas à confirmer que les deux correctifs sont appliqués.

Le projet PHP a publié les versions suivantes le 21 octobre 2026. Pour une installation distribuée directement par PHP, vérifiez la branche utilisée et adoptez une version corrigée de cette branche, ou une version ultérieure adaptée à votre application.

Les distributions Linux peuvent rétroporter un correctif sans reprendre ce numéro de version. Ubuntu a par exemple corrigé les deux CVE dans le paquet 8.3.6-0ubuntu0.24.04.13 pour Ubuntu 24.04. Demandez le numéro complet du paquet et le bulletin fournisseur correspondant avant de conclure à partir du seul numéro PHP.

PHP 8.1 et les branches antérieures ne bénéficient plus du support général du projet PHP. Des rétroportages ciblés existent, mais ils ne rétablissent pas ce support : vérifiez la couverture de votre fournisseur et préparez une migration compatible. PHP 8.2 atteint sa fin de support le 31 décembre 2026.

Commencez par identifier la personne qui peut modifier l’environnement PHP. Sur un hébergement mutualisé, cette intervention relève généralement de l’hébergeur. Sur un serveur administré par votre entreprise, elle doit être organisée avec votre responsable technique ou votre infogérant. Le prestataire qui modifie vos pages n’a pas nécessairement la main sur le serveur.

WordPress, ses extensions, son thème et PHP sont des composants distincts. Un tableau de bord WordPress à jour ne confirme pas que l’environnement PHP a reçu son correctif. Les deux niveaux doivent être suivis, avec une vérification de compatibilité avant un changement de branche PHP.

PHP indique qu’aucune mesure d’atténuation ne constitue une protection complète à la place de la mise à jour. Le CERT-FR décrit des contournements provisoires non qualifiés : certains ne réduisent qu’une partie de la surface d’attaque et peuvent perturber des fonctions du site. Un pare-feu applicatif peut contribuer à une protection temporaire, sans remplacer le correctif.

Si la correction immédiate est impossible, faites décider avec le responsable de l’hébergement des restrictions ou de l’isolement temporaire nécessaires. En cas de signe d’intrusion, une mise à jour seule ne prouve pas que le serveur est sain : préservez les journaux disponibles et faites examiner l’incident.

Une maintenance utile laisse des traces compréhensibles : les composants suivis, leur responsable, les opérations réalisées et les vérifications effectuées. Elle prévoit aussi le remplacement des versions en fin de support. Sans ce cadre, une alerte peut révéler un site dont personne ne sait encore mettre à jour l’hébergement.

Demandez un périmètre écrit : PHP et système, CMS et extensions, code spécifique, sauvegardes, tests de restauration et supervision. Précisez qui reçoit les alertes et qui autorise une intervention urgente. Le résultat attendu est une procédure utilisable et documentée ; aucune prestation ne peut promettre l’absence de toute vulnérabilité.

Vous ne savez pas quelle version tourne sur votre site, qui gère PHP ou quelles mises à jour prioriser ? L’audit technique Oryon permet de dresser un état des lieux sur le périmètre convenu, de classer les risques et de proposer des actions. L’audit et la réalisation des corrections sont des prestations à cadrer séparément.

Pour le suivi de serveurs Linux, notre infogérance associe inventaire, mises à jour, supervision et sauvegardes avec restauration testée. Pour un site WordPress, notre accompagnement couvre notamment la reprise, la sécurisation et la maintenance, avec préparation des interventions et vérifications selon le devis. Nous déterminons avec vous ce qui relève de l’hébergeur, du site et du code spécifique.

Pour préparer l’échange, indiquez l’adresse du site, votre hébergeur, le CMS utilisé si vous le connaissez et le retour déjà reçu sur ces deux CVE. Ne transmettez aucun mot de passe dans le formulaire de contact. Nous pourrons cadrer les vérifications et l’intervention adaptées à votre contexte.