Analyse de la faille de sécurité critique découverte dans PHP en octobre 2026

Une faille critique touche PHP, le langage qui fait tourner une bonne partie des sites du web. Les chiffres qui circulent font peur, et ça n’aide pas à y voir clair.

Ton site ou ton hébergement est-il touché, et que faut-il faire ? Dans cet article, on démêle l’essentiel : quoi vérifier, sans te noyer dans les chiffres.

Quelles versions de PHP sont concernées ?

La faille CVE-2026-109618 affiche un score de 9,2 sur 10 sur l’échelle CVSS v4.0. Sur une échelle qui monte à 10, c’est du lourd, elle est classée critique.

L’attaque passe par le réseau et ne demande aucun compte, mais elle est complexe à monter. Ton PHP est-il accessible depuis Internet ? C’est la première chose à vérifier.

Regarde les deux premiers chiffres de ta version de PHP, puis compare-la au correctif de sa colonne.

La faille est dans PHP lui-même, pas seulement dans WordPress. Un site à jour côté appli reste donc exposé.

Sous Windows, les paquets corrigés s’appellent 8.5.12-1, 8.4.27-1, 8.3.36-1 et 8.2.35-1.

Un numéro plus petit veut dire que tu es touché. Et ne remets pas ça à demain : c’est le genre de tâche qu’on repousse toujours.

Pourquoi c’est plus important qu’il n’y paraît

Quand PHP manque de mémoire pendant qu’il traite une requête, il peut abîmer sa propre mémoire. Le nettoyage de la requête lit alors des données internes incomplètes.

La seconde faille laisse des données de requête accessibles après la libération de leur mémoire. Les réutiliser peut permettre d’exécuter du code à distance. Encore deux failles, pas une : c’est agaçant.

Si ton site tourne avec mod_php d’Apache, tu es dans le cas le plus exposé. PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont concernés aussi, mais le risque est nettement plus élevé avec mod_php.

Ce qu’un attaquant peut faire dépend du compte qui lance PHP, et des fichiers que ce compte peut lire ou modifier.

Le chiffre de 22,6 millions d’instances fait peur, mais il mesure une exposition possible, pas des serveurs déjà piratés.

Franchement, commence par regarder quel compte fait tourner PHP, avant de paniquer.

Comment l’affaire a éclaté, de la fuite à l’exploitation

Le 20 octobre, un message sur Hacker News donne les identifiants des deux failles et annonce une publication à venir.

Il est vite supprimé, mais des captures ont déjà circulé, avec un outil d’exploitation nommé PHP2Shell. Les correctifs ne sortent que le lendemain, le 21 octobre à 16 h à Paris.

Une journée entière, c’est long quand les attaquants savent déjà quoi chercher. Supprimer un message ne rattrape rien : les copies sont déjà ailleurs. Ne compte pas sur la discrétion de la fuite, regarde ta version de PHP tout de suite.

Pour trier les chiffres, voici ce qui est établi à ce jour :

• Le 21 octobre, le CERT-FR, le centre de veille de l’État français sur les failles informatiques, a publié l’alerte CERTFR-2026-ALE-014. Elle a été mise à jour le 27 octobre, avec des tentatives d’exploitation puis des preuves de concept.
• Le 26 octobre, les deux failles ont été ajoutées au catalogue KEV de la CISA, la liste américaine des failles déjà exploitées.
• Une campagne a combiné PHP2Shell avec une faille Linux pour prendre les droits root sur 25 équipements PAN-OS. Ce chiffre ne concerne que ces pare-feu, pas les sites PHP en général.
• Au 28 octobre, plus de 77 000 requêtes d’exploitation ont visé des sites WordPress, venant de plus de 2 000 adresses IP. Aucune compromission de WordPress par PHP2Shell n’était connue à cette date.

Ce que ça change pour toi, en France

Le chiffre qui fait sursauter, ce sont les 6 millions d’applications françaises sur PHP. Sauf que ça ne dit pas combien sont touchées : ça mesure juste la présence du langage, rien de plus.

Même chose pour les plus de 660 000 adresses IP françaises qui utilisent PHP. Être sur PHP ne veut pas dire être piraté : la vraie question, c’est la version qui tourne chez toi.

Le 28 octobre, l’ANSSI l’a rappelé : le problème n’est pas définitivement réglé. Mettre PHP à jour ne suffit donc pas, et ça, personne n’a envie de l’entendre.

Les routeurs, pare-feu, NAS ou caméras connectées qui intègrent PHP sont à vérifier. Isole-les d’abord, puis passe-les sur une version maintenue et corrigée. Franchement, la liste de tout ce qui tourne en ligne chez toi, c’est le point de départ.

Comment vérifier la version de PHP de ton site ?

Commence par Plesk : ouvre « Sites Web & Domaines », puis « Paramètres PHP ». La version se règle domaine par domaine, sous-domaines compris. Donc vérifie chacun de tes sites, pas seulement le principal.

Mais le réglage ne dit pas tout. Sur le serveur, php -v affiche la version en ligne de commande, qui peut différer de celle du serveur web.

Un chiffre rassurant dans Plesk ne protège de rien si le serveur web tourne sur une autre version. C’est celle qui répond aux visiteurs qui compte, donc vérifie-la avant de te féliciter.

Une fois ta version relevée, compare-la au correctif de sa branche. La branche, c’est le numéro 8.2, 8.3, 8.4 ou 8.5, et les correctifs à viser sont 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 :

• Ta version est plus petite que le correctif de ta branche ? Elle est touchée, et tu dois la mettre à jour.
• Elle est égale ou plus récente ? Elle est corrigée pour cette faille.
• Un fichier phpinfo() est accessible depuis le web ? Supprime-le tout de suite. Il affiche ta version, tes extensions et des détails de configuration à n’importe quel visiteur.

Que faire si tu es concerné ?

Si ta version est corrigée, tu n’as rien à faire. Si elle est touchée, mets PHP à jour vers la version corrigée de ta branche, ou installe le paquet corrigé de ton hébergeur, de ta distribution ou du fabricant.

Et si tu ne peux pas corriger tout de suite ? Isole l’équipement du réseau public jusqu’à sa mise à jour. Coupé d’Internet, il n’est plus joignable de l’extérieur. Les gros chiffres qui circulent n’y changent rien.

Si ton PHP est en 8.1 ou plus ancien, migre vers une version maintenue et corrigée. Ces anciennes branches ne reçoivent plus de correctifs du projet PHP, donc il faut changer de branche, pas seulement appliquer un patch.

Ensuite, contrôle le site : ouvre les pages principales et teste un formulaire. Toutes les extensions ne sont pas compatibles avec la version choisie, alors vérifie-les aussi.

Ne repousse pas ça : c’est là que les sites tombent, un vendredi soir.

Retiens une chose : c’est ta version de PHP qui compte, pas les gros chiffres qui circulent. Une fois relevée, compare-la au correctif de sa branche, et agis selon le résultat.

Ton prochain pas, c’est de vérifier ta version tout de suite. Une fois la version à jour, ou le serveur coupé du réseau public, tu peux souffler. Pas avant, crois-moi.