Alerte sécurité · Sites web et applications des entreprises
Failles PHP critiques : les versions corrigées et les actions pour votre PME
Les failles PHP CVE-2026-109618 et CVE-2026-109619, aussi appelées PHP2Shell, peuvent permettre une exécution de code sans authentification sur un serveur vulnérable. Les correctifs sont disponibles depuis le 21 octobre 2026. Pour votre entreprise, la priorité est de vérifier le PHP réellement utilisé par vos sites et de faire confirmer sa correction.
Analyse du 23 octobre 2026. Les identifiants techniques officiels conservent leur graphie. Versions et recommandations vérifiées à cette date.
Demandez à votre hébergeur ou administrateur la version PHP exécutée par chaque site, la référence du correctif et la date de son application. Un WordPress à jour ne suffit pas à répondre à cette question.
Failles PHP2Shell : quel risque pour un site d’entreprise ?
PHP exécute une partie du code de nombreux sites et applications sur le serveur. Ces vulnérabilités concernent son moteur, pas seulement un thème ou une extension. Une exploitation réussie peut permettre à un attaquant d’exécuter du code avec les droits du processus PHP. Google Cloud décrit les deux vulnérabilités et leur gravité critique, notée 9,2 sur 10 selon CVSS.
Le risque concret dépend de l’installation et de son exposition. Un site toujours accessible peut rester vulnérable. À l’inverse, une version concernée ne prouve pas, à elle seule, qu’une intrusion a réussi. Faites distinguer ces deux questions dans le compte rendu de votre prestataire.
Quelles versions PHP corrigent les deux failles ?
Le bulletin officiel PHP du 21 octobre 2026 annonce les versions suivantes. Le tableau indique les correctifs publiés pour ces deux vulnérabilités, pas une garantie générale de sécurité.
| Branche PHP | Version corrective annoncée | Décision à faire confirmer |
|---|---|---|
| 8.5 | 8.5.12 | Installer ce correctif ou une version ultérieure adaptée |
| 8.4 | 8.4.27 | Installer ce correctif ou une version ultérieure adaptée |
| 8.3 | 8.3.36 | Installer ce correctif ou une version ultérieure adaptée |
| 8.2 | 8.2.35 | Installer ce correctif ou une version ultérieure adaptée |
Pour une branche ancienne, demandez une preuve de prise en charge au fournisseur. PHP précise que certaines distributions proposent des correctifs adaptés à leurs paquets. Le bulletin mentionne aussi des adaptations minimales du code pour 7.4, 8.0 et 8.1. Cela ne rétablit pas leur maintenance générale par le projet PHP.
Ne décidez donc pas uniquement à partir d’un numéro affiché : faites relever aussi la référence du paquet et l’avis de sécurité du fournisseur.
WordPress à jour : pourquoi vérifier aussi PHP ?
WordPress et PHP sont deux composants différents. La mise à jour de votre CMS, de ses extensions ou de son thème ne constitue pas une preuve que le moteur du serveur a reçu ce correctif.
La documentation WordPress situe les informations techniques dans Outils, Santé du site, Informations. La rubrique Serveur aide à identifier l’environnement utilisé. Sur un hébergement géré, faites ensuite confirmer la correction par l’hébergeur. Consulter la documentation Santé du site.
Évitez de publier une page de diagnostic technique accessible à tous pour obtenir cette information. Un échange privé avec le responsable de l’hébergement permet de conserver une trace sans exposer inutilement la configuration du site.
Un plan de correction en cinq étapes pour votre PME
1. Identifier les sites et leur responsable
Rassemblez les sites publics, boutiques, applications internes et environnements de test dont votre entreprise est responsable. Pour chacun, notez l’hébergeur et le contact qui peut intervenir. Le NCSC recommande de prioriser les systèmes exposés à Internet.
2. Préparer la reprise et les vérifications
Avant l’intervention, faites confirmer les sauvegardes disponibles et la procédure de restauration. Choisissez les fonctions à tester après correction : formulaire de contact, connexion, réservation ou commande selon votre activité. Une liste courte de contrôles concrets vaut mieux qu’une validation vague.
Si la reprise n’est pas documentée, revoyez votre organisation de sauvegarde informatique avec le responsable technique.
3. Faire appliquer le correctif au bon endroit
L’administrateur doit traiter l’environnement qui exécute réellement l’application. Demandez une confirmation pour chaque service concerné, pas seulement pour le serveur principal. Sur une offre gérée, clarifiez ce que l’hébergeur applique automatiquement et ce qui reste à votre charge.
4. Traiter explicitement les installations non corrigées
Si une application bloque la mise à jour, demandez une décision formalisée : responsable, mesures temporaires et prochaine échéance. Le NCSC envisage une mise hors ligne lorsque la correction ou les mesures temporaires ne peuvent pas être appliquées assez vite. Cette décision doit être organisée avec les personnes responsables du service.
5. Conserver les preuves et examiner les alertes
Enregistrez la version ou le paquet obtenu, la date, l’intervenant et les résultats des tests. Si des événements suspects apparaissent, préservez les journaux et faites examiner le périmètre. Le NCSC recommande de rechercher des signes de compromission lorsque le système ne peut pas être corrigé ou désactivé immédiatement.
Pour éviter de redécouvrir ces responsabilités à chaque alerte, vérifiez le périmètre de votre contrat de maintenance informatique.
Questions fréquentes sur les failles PHP d’octobre 2026
Un pare feu applicatif remplace la mise à jour PHP ?
Non. Google Cloud précise que ses protections applicatives réduisent l’exposition mais ne remplacent pas la correction de PHP et le redéploiement des services concernés. Une protection intermédiaire ne doit pas devenir une clôture prématurée du ticket.
Un site WordPress est forcément piraté si PHP est vulnérable ?
Non. Une vulnérabilité et une compromission sont deux constats différents. Faites vérifier le correctif et, si le contexte le justifie, les traces disponibles. Le fonctionnement normal du site ne démontre pas à lui seul l’absence d’incident.
Qui doit intervenir sur un hébergement mutualisé ?
Commencez par le support de l’hébergeur pour identifier la version exécutée et le correctif appliqué. Le gestionnaire du site doit aussi contrôler les fonctions applicatives après intervention. La répartition exacte dépend de votre contrat.
Quelle demande transmettre à mon prestataire ?
Demandez quels services utilisent PHP, si les deux vulnérabilités sont corrigées, quelle preuve le confirme et quels tests ont été réalisés. Pour chaque exception, obtenez un responsable et une échéance. Ne joignez aucun mot de passe à cette demande générale.
Vous manquez de visibilité sur votre maintenance informatique ?
Cyber LID accompagne les entreprises sur leur informatique et leur sécurité. Échangeons sur vos sauvegardes, les responsabilités de maintenance et les points à clarifier avec vos prestataires.
Faire le point sur mon informatiqueSources et date de vérification
Informations vérifiées le 23 octobre 2026 à partir du bulletin PHP, de l’alerte NCSC, de l’analyse Google Cloud et de la documentation WordPress. Les étapes d’organisation sont des recommandations générales. L’intervention technique dépend de votre installation.