Failles critiques PHP: quels risques pour votre site et comment réagir ?

Le 21 octobre 2026, PHP a publié des correctifs pour deux vulnérabilités critiques susceptibles de permettre l’exécution de code à distance sans authentification. Pour une entreprise, la question est immédiate: son site est-il concerné et qui doit intervenir ? Voici les faits établis et les vérifications à demander à votre prestataire.

Que s’est-il passé ?

L’alerte porte sur deux failles distinctes, identifiées CVE-2026-109618 et CVE-2026-109619, toutes deux évaluées à 9,2 sur 10 selon le système CVSS v4.0. Ce score mesure leur gravité technique. Il ne signifie pas que 92 % des sites seront piratés.

La première concerne la façon dont PHP gère certains manques de mémoire: une requête interrompue peut laisser des données internes dans un état invalide, ensuite réutilisé. La seconde concerne un état interne qui reste accessible après la libération de sa mémoire et peut être repris lors d’une autre requête. Les deux problèmes touchent le moteur PHP lui-même. Les mécanismes sont décrits dans les deux bulletins techniques de PHP et dans l’avis consacré à l’état interne.

Quels sites sont concernés ?

L’équipe PHP appelle à mettre à jour les installations qui traitent des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Elle considère le risque le plus élevé avec mod_php: une exploitation a été démontrée avant même l’exécution du code de l’application.

WordPress confirme que le problème dépasse son propre logiciel: tout serveur hébergeant une application PHP doit être vérifié. Pour connaître la version utilisée par un site WordPress, rendez-vous dans Outils, Santé du site, Informations, puis Serveur. Votre panneau d’hébergement peut également l’afficher. Cette indication doit ensuite être rapprochée des correctifs fournis par l’hébergeur.

Attention aussi aux composants moins visibles. L’ENISA rappelle que des produits peuvent intégrer PHP sans que leur utilisation apparaisse clairement. Vérifiez donc avec votre prestataire les applications et services associés au site, pas seulement la page d’accueil.

Quels sont les risques pour une entreprise ?

Une exécution de code à distance permet à un attaquant de faire exécuter ses instructions sur le serveur. Les démonstrations décrites par PHP obtiennent les droits du processus web, ce qui ne signifie pas automatiquement un accès administrateur à toute la machine.

Selon les permissions de ce processus et les ressources auxquelles il accède, les conséquences possibles comprennent la consultation de fichiers sensibles, la modification du site ou une interruption de service. L’étendue réelle dépend de l’hébergement et de sa configuration. La présence d’une version vulnérable ne prouve toutefois pas qu’une intrusion a eu lieu. Inversement, un site qui s’affiche normalement ne permet pas de conclure qu’il est protégé.

Quelles versions corrigent les failles ?

Les versions correctives publiées par le projet PHP le 21 octobre 2026 sont les suivantes, pour chacune des branches concernées:

• PHP 8.2: version 8.2.35.

• PHP 8.3: version 8.3.36.

• PHP 8.4: version 8.4.27.

• PHP 8.5: version 8.5.12.

Consultez l’avis officiel PHP pour les mises à jour et les instructions associées. PHP 8.1 et les versions antérieures ne sont plus maintenus par le projet PHP: demandez à votre fournisseur s’il assure un correctif spécifique, ou organisez une migration vers une branche prise en charge.

Le numéro affiché ne suffit pas toujours. Une distribution Linux peut intégrer le correctif dans son propre paquet sans reprendre le numéro de la nouvelle version PHP. Par exemple, Ubuntu répertorie un correctif pour PHP 8.3 dans le paquet 8.3.6-0ubuntu0.24.04.13. Il faut vérifier la référence exacte du paquet et le bulletin de son fournisseur, plutôt que conclure à partir des seuls premiers chiffres.

Les démarches à effectuer maintenant

Si votre site est géré par un hébergeur ou une agence, demandez une confirmation précise. Un message général indiquant que la sécurité est surveillée ne renseigne pas sur l’application de ces deux correctifs.

1. Identifier les services concernés. Faites confirmer où PHP est utilisé et quelles applications sont exposées sur Internet.

2. Demander le correctif des deux CVE. Obtenez la version corrigée ou la référence du paquet de sécurité déployé sur votre hébergement.

3. Vérifier sa prise en compte. Faites confirmer que les processus PHP en service utilisent bien le correctif, avec les redémarrages prévus par le fournisseur.

4. Contrôler les fonctions importantes. Après intervention, vérifiez les formulaires, la connexion, les commandes et les autres fonctions utiles de votre site.

5. Conserver une trace de l’intervention. Notez la date, le périmètre traité et les éventuelles vérifications complémentaires.

Lorsque le correctif ne peut pas être appliqué immédiatement, l’ENISA recommande d’envisager l’isolement des applications exposées du réseau public. Cette décision doit être prise avec la personne responsable de l’hébergement, en tenant compte du risque et de la continuité de votre activité.

Ce qui ne remplace pas la mise à jour de PHP

Mettre à jour WordPress ou ses extensions ne corrige pas, à lui seul, le moteur PHP du serveur. WordPress précise qu’aucune mise à jour de WordPress n’est prévue pour résoudre ces failles: l’intervention doit porter sur PHP.

Un pare-feu applicatif ou des changements de configuration peuvent réduire certaines possibilités d’attaque. L’équipe PHP avertit néanmoins que ces mesures ne constituent pas une protection complète. Faites-les appliquer par l’administrateur selon les instructions officielles, sans les considérer comme une raison de différer le correctif.

Et si vous suspectez déjà un piratage ?

Appliquer le correctif ne suffit pas à effacer une intrusion antérieure. En cas de fichiers modifiés sans explication, de comptes inconnus ou d’activité suspecte, prévenez votre hébergeur et faites analyser la situation.

Le CERT-FR recommande de préserver les traces et les journaux, de protéger les sauvegardes et de mobiliser les intervenants compétents. Évitez une réinstallation précipitée qui détruirait les éléments utiles à l’analyse.

Cybermalveillance.gouv.fr recommande également d’identifier et de corriger les failles, puis de changer les mots de passe avant la remise en ligne d’un site compromis. Une restauration doit s’appuyer sur un état fiable et s’accompagner de la correction de la cause de l’intrusion.

Le message à envoyer à votre hébergeur

Bonjour, pouvez-vous me confirmer si mon hébergement utilise PHP et si les correctifs CVE-2026-109618 et CVE-2026-109619 ont été appliqués ? Merci de préciser la version ou la référence du paquet corrigé, la date de déploiement et si les processus PHP actifs ont bien été mis à jour. Si l’intervention reste à faire, quelles mesures temporaires prévoyez-vous et sous quel délai ?