Aller au contenu
Antoine Le LouëtDéveloppeur senior indépendant (Accueil)
Parlons de votre besoin ↗Contact
← Revenir au Journal

Actualités5 min de lecture

Failles PHP du 21 octobre 2026 : mon site est-il concerné et comment le protéger ?

Deux failles critiques touchent PHP. Vérifiez votre site, isolez les services vulnérables si nécessaire et appliquez les correctifs du 21 octobre 2026.

Antoine Le LouëtDéveloppeur senior indépendant

Une barrière coupe l’accès public au service PHP vulnérable ; après correction et vérification, l’accès peut être rétabli.
Si le correctif ne peut pas être appliqué immédiatement, isoler le service exposé permet d’attendre sa mise à jour. Schéma de principe.

Que se passe-t-il avec PHP aujourd’hui ?

Le 21 octobre 2026, des correctifs ont été publiés pour deux vulnérabilités critiques de PHP, identifiées CVE-2026-109618 et CVE-2026-109619, également désignées PHP2Shell. Dans certaines conditions, une personne sans compte peut faire exécuter du code sur le serveur. Le CERT-FR confirme le risque d’exécution de code à distance dans son alerte du jour.

PHP est le logiciel qui exécute le code de nombreux sites sur leur serveur. Le navigateur du visiteur reçoit ensuite la page produite. Une faille à ce niveau peut donc concerner un site dont le propriétaire n’a rien changé récemment. Pour une entreprise, l’enjeu est de protéger l’application et les données auxquelles le serveur accède.

Ce point d’actualité est arrêté au 21 octobre 2026. Les correctifs sont disponibles : il faut maintenant les déployer, plutôt qu’attendre une prochaine publication.

WordPress, boutique en ligne : comment savoir si mon site est concerné ?

Si votre site utilise WordPress, commencez par vérifier sa version de PHP dans Outils > Santé du site > Informations > Serveur, ou dans le panneau de votre hébergeur. WordPress précise que ces failles touchent PHP et qu’aucune mise à jour de WordPress n’est prévue pour les corriger. Mettre à jour seulement le CMS ou ses extensions ne remplace donc pas le correctif serveur.

Pour un autre site ou une application métier, demandez au responsable technique si PHP intervient dans le traitement des requêtes web. Pensez aussi aux sous-domaines, aux anciennes applications et aux environnements de test accessibles depuis Internet. Je conseille de noter pour chaque service son hébergeur et la personne chargée d’appliquer la correction.

Un site qui n’utilise pas PHP n’est pas directement exposé à ces deux failles. Son apparence ne permet pas de le savoir : l’inventaire de l’hébergement apporte la réponse.

Faut-il désactiver les serveurs PHP en attendant ?

Si un service PHP vulnérable est accessible depuis Internet et que vous ne pouvez pas le corriger immédiatement, faites désactiver temporairement son accès public. Le CERT-EU recommande d’envisager cette isolation jusqu’à l’application et à la vérification du correctif. Avec un hébergement géré, demandez cette intervention au prestataire.

Je recommande de faire bloquer le trafic vers l’application au niveau du serveur web ou du proxy, ou d’arrêter le service PHP concerné si c’est la méthode adaptée à l’hébergement. Une page de maintenance doit être servie sans exécuter le PHP vulnérable. Un simple écran de maintenance généré par le CMS peut laisser les requêtes atteindre le moteur PHP.

L’accès Internet est fermé devant PHP pendant la correction. Il est rouvert après vérification du service corrigé.
L’isolation doit agir avant l’exécution de PHP. Un message de maintenance affiché par l’application ne prouve pas cette isolation.

Faites vérifier les autres chemins d’accès, notamment l’adresse directe du serveur derrière un proxy. L’arrêt implique une interruption de service : préparez un message pour les utilisateurs et un moyen de contact. La remise en ligne doit suivre la vérification du correctif.

Quelles versions de PHP installer ?

PHP publie les versions corrigées 8.2.35, 8.3.36, 8.4.27 et 8.5.12 pour les branches correspondantes. Demandez à l’hébergeur la version effectivement mise en service et sa confirmation de correction des deux CVE. Pour une ancienne branche, faites vérifier l’existence d’un correctif fourni par son mainteneur et préparez une migration vers une version prise en charge.

Une distribution Linux peut intégrer la correction dans son propre paquet sans afficher le numéro de version publié par PHP. Le bulletin Ubuntu du 21 octobre donne, par exemple, des paquets corrigés avec une numérotation spécifique. Le contrôle doit donc porter sur l’avis de sécurité du fournisseur et la version complète du paquet.

  1. Identifier tous les services concernés et conserver les informations nécessaires à l’intervention.
  2. Installer le paquet ou l’image corrigée, puis redémarrer ou remplacer les processus qui exécutent PHP.
  3. Vérifier la version réellement utilisée par le site, puis tester les parcours essentiels, comme la connexion ou une commande.
  4. Rétablir l’accès public après ces contrôles et surveiller les erreurs ainsi que les événements de sécurité.

La mise à jour suffit-elle si le site a déjà été attaqué ?

Cloudflare rapporte le 21 octobre avoir observé du trafic d’attaque visant ces failles. Cela justifie une intervention rapide ; cela ne prouve pas que votre propre site a été compromis. Une protection par pare-feu applicatif peut aider pendant l’intervention, mais ne dispense pas de mettre à jour PHP.

Je conseille de conserver les journaux avant leur rotation. Si vous découvrez des fichiers inconnus, des comptes ajoutés ou une activité inhabituelle, demandez une analyse de l’incident. Le correctif ferme une vulnérabilité ; il ne retire pas automatiquement un accès qu’un attaquant aurait déjà installé.

À transmettre à votre hébergeur : « Merci de confirmer si notre site est exposé à CVE-2026-109618 et CVE-2026-109619, de l’isoler si la correction immédiate est impossible, puis de nous communiquer le paquet corrigé déployé et le résultat des vérifications. »

Sources et liens utiles

Partager sur LinkedIn (nouvel onglet)

Poursuivre la lecture
Tous les articles de la catégorie →