Faille critique PHP d’octobre 2026 : votre site est-il exposé ?
Le 21 octobre 2026, PHP a corrigé deux failles notées 9,2 sur 10. Elles touchent la quasi-totalité des sites WordPress, PrestaShop et PHP. Voici comment savoir si le vôtre est protégé.
Le 21 octobre 2026, l’équipe de PHP a publié des correctifs pour deux failles critiques, référencées CVE-2026-109618 et CVE-2026-109619. Leur note de gravité : 9,2 sur 10.
PHP est le langage qui fait tourner WordPress, PrestaShop et une grande partie des sites web. Si votre site en fait partie, il est concerné. La bonne nouvelle : la correction existe déjà. Encore faut-il qu’elle soit installée.
Que s’est-il passé le 21 octobre ?
L’équipe de PHP avait prévenu la veille qu’une mise à jour de sécurité majeure allait sortir. Le lendemain, quatre nouvelles versions étaient publiées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Les éditeurs de logiciels d’hébergement ont suivi dans la journée. Plesk, utilisé par de nombreux hébergeurs, a diffusé ses versions corrigées le jour même et a confirmé que toutes les versions de PHP qu’il fournit étaient touchées.
Pourquoi ces failles sont-elles si graves ?
Parce qu’elles permettent une exécution de code à distance. Concrètement, un attaquant peut faire exécuter ses propres instructions sur le serveur qui héberge votre site.
Trois éléments aggravent la situation :
- Aucun identifiant n’est nécessaire. L’attaquant n’a pas besoin de compte sur votre site.
- Votre site n’a pas besoin d’être mal codé. Dans certaines configurations, l’attaque se déclenche avant même que WordPress ou PrestaShop ne démarre.
- Il n’existe pas de parade complète. L’équipe de PHP le dit clairement : seule la mise à jour protège réellement. Les réglages de contournement réduisent le risque, sans l’éliminer.
Une fois les correctifs publiés, les pirates les étudient pour comprendre la faille. Les premières tentatives de piratage suivent en général de près. Les semaines qui viennent sont donc les plus exposées.
Votre site est-il concerné ?
Oui, s’il fonctionne avec PHP et que son serveur n’a pas encore reçu la mise à jour. C’est le cas de tous les sites WordPress, WooCommerce et PrestaShop, ainsi que de la plupart des sites développés sur mesure.
Quelles versions de PHP sont protégées ?
| Branche PHP | Version vulnérable | Version corrigée |
|---|---|---|
| PHP 8.5 | 8.5.11 et antérieures | 8.5.12 |
| PHP 8.4 | 8.4.26 et antérieures | 8.4.27 |
| PHP 8.3 | 8.3.35 et antérieures | 8.3.36 |
| PHP 8.2 | 8.2.34 et antérieures | 8.2.35 |
Et si votre site tourne encore en PHP 7.4, 8.0 ou 8.1 ?
Ces versions ne sont plus maintenues par l’équipe de PHP. Vu la gravité des failles, des correctifs exceptionnels ont été mis à disposition, et certains hébergeurs les ont intégrés. Mais attention : le numéro de version ne change pas. Seule la date de compilation indique si la correction est présente.
Surtout, ce geste reste exceptionnel. À la prochaine faille, rien ne garantit qu’il se reproduira. Et PHP 8.2 arrive à son tour en fin de vie le 31 décembre 2026. Si votre site utilise l’une de ces versions, c’est le bon moment pour planifier la mise à jour de PHP.
Comment vérifier la version PHP de votre site ?
Sur WordPress, c’est rapide :
- Connectez-vous à l’administration de votre site.
- Ouvrez Outils > Santé du site, puis l’onglet Informations.
- Dépliez la section Serveur : la version de PHP s’affiche.
Sur les autres sites, l’information se trouve généralement dans l’espace client de votre hébergeur. En cas de doute, posez-lui directement la question : il doit pouvoir vous répondre en une phrase.
Mettre à jour PHP suffit-il ?
C’est l’essentiel, mais quelques points méritent votre attention.
- La mise à jour doit être réellement appliquée. Les services PHP doivent être redémarrés pour que la correction prenne effet.
- Le panneau d’administration de l’hébergement compte aussi. Certains outils de gestion de serveur utilisent leur propre version de PHP, qui se met à jour séparément.
- Votre site doit rester compatible. Passer d’une ancienne version de PHP à une version récente se prépare : extensions, thème et code sur mesure doivent suivre. On commence toujours par une sauvegarde complète du site.
- Le reste doit être à jour. Un PHP corrigé ne protège pas d’une extension WordPress vulnérable. Depuis la fin de l’été, la grande majorité des piratages que nous traitons passent par des composants qui n’avaient pas été mis à jour. Pensez à mettre à jour WordPress et ses extensions en même temps.
Que fait AntheDesign pour ses clients ?
Nous appliquons les versions corrigées de PHP sur tous les serveurs que nous gérons.
Pour les sites de nos clients, nous allons plus loin. Nous prenons contact avec chacun d’entre vous pour proposer, si nécessaire, une mise à jour du site et des préconisations pour renforcer sa sécurité.
Votre site est hébergé ailleurs, ou vous ne savez pas s’il est protégé ? Nous vous proposons un contrôle gratuit : version de PHP, état des mises à jour, premiers signes de compromission. Écrivez-nous à contact@anthedesign.fr, nous revenons vers vous rapidement.
Sources : avis de sécurité officiel de PHP (21 octobre 2026) ; bulletin Plesk.
FAQ : vos questions sur la faille PHP d’octobre 2026
Que signifient les références CVE-2026-109618 et CVE-2026-109619 ?
Une CVE est un identifiant public attribué à chaque faille de sécurité connue. Il permet à tous les acteurs (éditeurs, hébergeurs, agences) de parler du même problème. La note de 9,2 sur 10 mesure sa gravité : au-delà de 9, la faille est classée critique.
Mettre à jour WordPress suffit-il à me protéger ?
Non. PHP est installé sur le serveur, pas dans WordPress. Une mise à jour de WordPress ou de vos extensions ne touche pas à PHP. Les deux doivent être à jour, et c’est la version de PHP du serveur qui corrige cette faille.
Qui doit faire la mise à jour de PHP ?
Sur un hébergement mutualisé, c’est votre hébergeur. Sur un serveur dédié ou un VPS, c’est la personne qui administre le serveur : vous, ou votre prestataire. Si vous ne savez pas qui s’en occupe, c’est le premier point à clarifier.
La mise à jour de PHP peut-elle casser mon site ?
Tout dépend du type de mise à jour. Passer de PHP 8.3.35 à 8.3.36 est un simple correctif : le risque est très faible. Passer de PHP 7.4 à PHP 8.3 change de version majeure : là, extensions et thème doivent être testés avant la bascule.
Mon site a-t-il pu être piraté avant la mise à jour ?
Lors de la publication des correctifs, l’équipe de PHP n’a pas signalé d’attaques en cours. Mais un serveur resté plusieurs jours sans mise à jour est exposé. Quelques signes doivent alerter : redirections vers des sites inconnus, fichiers ou comptes administrateurs que vous n’avez pas créés, alerte de Google sur votre site.
Existe-t-il une solution provisoire si la mise à jour tarde ?
Certains réglages du serveur réduisent le risque. L’équipe de PHP est claire : ils ne protègent pas complètement. Ils servent à gagner quelques heures, pas à remplacer la mise à jour.