Failles PHP d’octobre 2026 : quels sites sont concernés et comment réagir ?

PHP exécute du code sur le serveur qui héberge un site, avant d’envoyer le résultat au navigateur. Il peut notamment traiter un formulaire ou produire une page à partir d’une base de données. Une entreprise peut donc en dépendre sans jamais voir son nom dans son outil de gestion. WordPress utilise PHP ; la version de ce moteur est gérée au niveau de l’hébergement.

Le 21 octobre 2026, le CERT-FR a publié une alerte sur deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619. Sa mise à jour signale des tentatives d’exploitation visant des déploiements spécifiques. Ce constat justifie une vérification rapide, mais ne démontre pas qu’un site donné a été compromis.

Pour une PME, la première difficulté est souvent de savoir qui s’occupe de quoi. L’agence qui modifie les pages, l’éditeur du logiciel et l’hébergeur peuvent être trois interlocuteurs différents. Il faut identifier celui qui peut vérifier et mettre à jour le moteur PHP, puis lui confier explicitement le suivi de cette alerte.

L’exécution de code à distance signifie qu’un attaquant peut faire exécuter ses instructions par le serveur. Dans les scénarios concernés ici, il n’a pas nécessairement besoin d’un compte sur le site. L’exposition dépend toutefois de la manière dont PHP reçoit les requêtes et du comportement de l’application.

CVE-2026-109618 concerne le traitement d’un manque de mémoire. PHP peut interrompre une opération alors que ses données internes sont incomplètement préparées, puis les réutiliser lors du nettoyage de la requête. Cette corruption mémoire peut permettre une exécution de code. Avec Apache et mod_php, le problème peut survenir avant même le code de l’application ; cela limite ce qu’une protection placée uniquement dans celle-ci peut faire.

CVE-2026-109619 concerne des informations internes conservées après la libération de leur mémoire. Un processus PHP réutilisé pour une autre requête peut encore s’appuyer sur ces informations périmées. Les conditions varient selon la configuration et les opérations déclenchées. Un plantage isolé ne suffit donc pas à diagnostiquer cette faille.

Le CERT-EU cite notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Il souligne le risque particulièrement élevé de mod_php. Utiliser PHP-FPM ne dispense donc pas de vérifier les correctifs. Ces différences servent à prioriser l’intervention, pas à déclarer une installation protégée sur le seul nom de son serveur.

Le tableau donne les premières versions correctives des deux vulnérabilités initiales dans les branches PHP maintenues citées par le CERT-EU. Il faut sélectionner le paquet adapté à son environnement, avec les mises à jour de sécurité disponibles au moment de l’intervention.

Pour les anciennes branches, certains fournisseurs proposent des correctifs rétroportés. Exigez la référence de leur avis de sécurité : le numéro de version seul peut être insuffisant.

Une réponse « nous sommes en PHP 8 » est trop imprécise : PHP 8.2.34 et PHP 8.2.35 n’ont pas le même statut pour ces deux failles. Demandez le numéro complet et, le cas échéant, la révision du paquet du fournisseur. Ce tableau n’est pas une garantie générale de sécurité et ne clôt pas le point distinct présenté juste après.

L’annonce PHP du 23 octobre ajoute CVE-2026-115560 : elle nécessite un gestionnaire de sessions configuré sur php_binary ou php_serialize, puis changé en php pendant l’exécution, avec le suivi des téléversements activé. PHP juge cette combinaison peu probable et annonce un correctif dans le cycle normal. L’éditeur propose de désactiver temporairement session.upload_progress.enabled dans les cas concernés.

La conséquence pratique : il faut demander au mainteneur s’il a évalué ce point supplémentaire, même après installation du correctif des deux premières failles. Cette vérification de configuration doit être réalisée par la personne qui connaît l’application. Une consigne copiée sans examen du contexte peut modifier un comportement attendu du site.

Cybermalveillance.gouv.fr décrit des risques d’interruption de service, de vol ou de destruction de données et, selon les connexions de l’équipement, d’accès à d’autres systèmes. Ce sont des conséquences possibles d’une exploitation réussie, pas des dommages établis pour tous les sites PHP.

Pour traduire l’alerte en priorités, posez une question métier : que peut atteindre cette application ? Un site de prise de commandes, un portail contenant des documents clients et une page vitrine n’ont pas les mêmes enjeux. Repérez les données traitées, les comptes techniques utilisés et les services reliés. Cette cartographie aide à décider de l’urgence et d’une éventuelle restriction temporaire, sans attendre un chiffrage hypothétique des pertes.

Commencez par les applications accessibles depuis Internet et poursuivez l’inventaire des autres services PHP. La liste doit associer chaque domaine ou application à son hébergeur, son responsable technique, sa version et la preuve de vérification. Incluez les anciens sites encore ouverts : vérifier uniquement le site principal laisse une réponse incomplète.

Dans WordPress, l’écran Outils → Santé du site → Informations regroupe des renseignements techniques, notamment sur le serveur. Il constitue un point de départ pour l’échange avec le prestataire. Le tableau de bord de l’hébergeur peut aussi aider ; demandez ensuite confirmation pour chaque environnement effectivement utilisé.

PHP peut charger des configurations différentes selon son mode d’exécution. Il faut donc rattacher le contrôle au processus qui sert le site : une commande lancée dans un terminal ou un contrôle effectué sur une préproduction ne prouve pas, à lui seul, l’état de la production. Notre recommandation : conserver une preuve datée associant le domaine, l’environnement, le paquet actif et le responsable du contrôle.

• Hébergement géré : demander au fournisseur le statut du site précis, la référence du correctif et la date de son application.
• Serveur administré par l’entreprise : faire contrôler par l’administrateur chaque service ou conteneur PHP utilisé.
• Logiciel fourni comme service : demander à l’éditeur sa confirmation de traitement ; le client n’a pas forcément accès au moteur sous-jacent.

La mise à jour doit être conduite par le responsable de l’hébergement ou de l’application. Pour organiser son intervention, nous proposons les étapes suivantes. Elles permettent de distinguer un correctif disponible, un correctif installé et un service réellement vérifié.

Si la mise à jour immédiate est impossible, le CERT-EU recommande d’envisager l’isolement des applications exposées jusqu’à application et vérification du correctif. La décision doit tenir compte du service à maintenir et être attribuée à un responsable. Les contournements provisoires ne constituent pas une clôture du dossier.

• Préparer : identifier les composants compatibles et disposer d’une sauvegarde exploitable avant de modifier l’environnement. Tester la migration sur une copie lorsque c’est possible.
• Appliquer : installer le correctif du fournisseur, ou migrer vers une branche maintenue si nécessaire. Mettre à jour le CMS et ses extensions reste une opération distincte.
• Recharger : suivre la procédure du fournisseur pour que les processus actifs utilisent les nouveaux fichiers et réglages ; changer un fichier de configuration ne prouve pas sa prise en compte.
• Tester : vérifier les parcours qui comptent pour l’entreprise, par exemple connexion, formulaire, téléversement et commande de test. Une page d’accueil disponible ne couvre pas ces usages.
• Documenter : noter la version active, l’heure d’intervention, les tests réalisés et les exceptions restantes. Désigner une date de suivi pour chaque point non résolu.

Corriger une vulnérabilité et traiter une compromission sont deux travaux distincts. Une mise à jour ne démontre pas qu’aucun accès non autorisé n’a eu lieu auparavant. Si des anomalies sont constatées, demandez au prestataire d’examiner les éléments disponibles et de préciser la période réellement couverte par ses journaux.

La démarche de réponse à incident décrite par le NCSC associe analyse, limitation des effets, élimination de la menace et retour au fonctionnement normal. Il faut conserver la trace des constats et des décisions. L’absence d’alerte dans des journaux incomplets ne permet pas de conclure à l’absence d’intrusion ; un simple redémarrage ne constitue pas non plus une investigation.

Les sources consultées établissent l’existence de vulnérabilités et de tentatives d’exploitation. Elles ne permettent pas de désigner votre entreprise comme victime ni de lui attribuer une fuite de données. Le statut final doit refléter les vérifications réellement effectuées : traité, non concerné avec justification, ou encore en cours avec responsable et échéance.

Pour terminer l’échange, demandez un compte rendu court et vérifiable. Il doit permettre à une autre personne de reprendre le dossier sans reconstruire toute la conversation. Voici les informations que nous recommandons de conserver :

• Périmètre : quels sites, applications et environnements ont été contrôlés ? Quels éléments restent à examiner ?
• Correction : quelle version ou quel paquet est actif, et quelle preuve couvre les deux CVE initiales ?
• Point complémentaire : la configuration liée à CVE-2026-115560 a-t-elle été évaluée ?
• Validation : quels parcours ont été testés, quels journaux ont été examinés et quelles limites subsistent ?
• Suivi : qui traite les exceptions et à quelle date le statut sera-t-il revérifié ?