Deux failles PHP critiques menacent des millions de sites :
correctifs publiés le 21 octobre 2026
Sites vitrines, boutiques en ligne, blogs, applications métier : PHP est partout, souvent sans que les propriétaires de sites le sachent. Quand deux failles critiques touchent le moteur lui-même, ce n’est plus l’affaire d’une extension ou d’un thème, mais de tout le serveur. Ce qui a été annoncé, quelles versions sont concernées, et ce qu’une entreprise doit vérifier dès cette semaine avec son hébergeur ou son prestataire.
Que permettent ces deux failles PHP ?
Une exécution de code à distance, sans authentification, sur les serveurs vulnérables.
Le projet PHP a annoncé le 20 octobre 2026 deux vulnérabilités critiques, puis publié les correctifs le lendemain. Elles ont reçu les identifiants CVE-2026-109618 et CVE-2026-109619, et chacune est notée 9,2 sur 10. Elles sont parfois désignées sous le nom de « PHP2Shell ».
Leur particularité : elles se situent dans le cœur de PHP, et non dans une application. Peu importe donc que le site tourne sous WordPress, PrestaShop, Drupal ou un développement sur mesure : si le moteur PHP qui traite les requêtes web est vulnérable, le site l’est aussi.
Dans les configurations concernées, un attaquant pourrait exécuter du code sur le serveur sans disposer de compte. Les conséquences possibles sont lourdes : prise de contrôle du site, accès aux données stockées, installation de programmes malveillants.
Selon 01net, l’une de ces failles serait présente dans le code de PHP depuis plus de dix ans.
Quelles versions de PHP sont concernées et lesquelles sont corrigées ?
Toutes les versions antérieures aux correctifs du 21 octobre.
Le CERT-FR, centre gouvernemental de veille et d’alerte, a publié une alerte dédiée. Sont affectées :
PHP 8.5 avant la version 8.5.12.
PHP 8.4 avant la version 8.4.27.
PHP 8.3 avant la version 8.3.36.
PHP 8.2 avant la version 8.2.35.
Toutes les versions 5.x, 6.x, 7.x, 8.0 et 8.1, qui ne sont plus supportées.
La mesure principale est simple : passer à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la branche utilisée. Le CERT-FR recommande aussi d’isoler les équipements affectés tant que la mise à jour n’est pas faite.
Des mesures de contournement provisoires ont été évoquées, mais le CERT-FR précise qu’elles ne sont pas qualifiées et ne couvrent qu’une partie du problème. Elles ne remplacent pas la mise à jour, et relèvent de l’hébergeur ou de l’administrateur du serveur.
Que faire si le site tourne encore sur une ancienne version de PHP ?
Migrer, car aucun correctif officiel n’est prévu.
Les versions 8.1 et antérieures ne sont plus maintenues par le projet PHP. Elles ne recevront pas de correctif officiel pour ces failles. Un site qui fonctionne encore en PHP 7 ou en PHP 8.0 reste donc exposé, sauf si l’éditeur de sa distribution Linux ou son hébergeur fournit un correctif spécifique.
Beaucoup de sites anciens, jamais remis à jour, sont dans ce cas. La migration vers une version récente peut demander des ajustements, notamment si le thème ou certaines extensions ne sont plus compatibles. C’est un chantier à confier à un prestataire, mais il ne peut plus être repoussé.
À noter : PHP 8.2 arrive lui-même en fin de vie le 31 décembre 2026. Pour un site qui doit migrer, mieux vaut viser directement une branche plus récente.
JFrog, qui a publié une analyse détaillée, recommande aussi de vérifier auprès de l’hébergeur ou de la distribution si des correctifs ont été intégrés sans changement visible du numéro de version.
Des attaques sont-elles déjà en cours ?
Les signaux divergent, mais le risque monte vite après la publication des correctifs.
Au moment de la publication de son analyse, JFrog indiquait qu’aucune exploitation généralisée n’était établie publiquement, tout en soulignant que la situation pouvait évoluer rapidement. Selon Frandroid, cité par Selectra, Cloudflare disait voir des attaques émerger, tandis que Sophos n’en avait pas détecté.
Une chose est sûre : la publication d’un correctif permet aussi aux attaquants d’étudier ce qui a été modifié. Plus un site reste sur une version vulnérable, plus le risque augmente.
Par précaution, plusieurs sites sont passés en maintenance le temps de se mettre à jour. Une mise hors ligne préventive n’est pas la preuve d’un piratage.
Que doit vérifier une entreprise pour son site ?
Si le site utilise PHP, quelle version, et qui doit la mettre à jour.
La présence de PHP. Tous les sites WordPress utilisent PHP, comme la plupart des boutiques PrestaShop et beaucoup d’applications sur mesure. En cas de doute, demandez à votre hébergeur ou à votre développeur.
La version exacte. Elle apparaît souvent dans l’espace client de l’hébergeur ou dans l’outil de santé du site, côté administration WordPress. Comparez-la aux versions corrigées.
L’hébergeur. Sur un hébergement mutualisé, c’est en général l’hébergeur qui gère PHP. Vérifiez qu’il a appliqué les correctifs, ou qu’il propose une version corrigée à activer.
Tous les sites. Un même hébergement peut faire tourner plusieurs sites, parfois oubliés : ancien site, site de test, mini-site de campagne. Chacun doit être vérifié.
Après la mise à jour. Contrôlez que la version active est bien la version corrigée, que le site fonctionne normalement, et demandez une surveillance des journaux pour repérer toute activité inhabituelle.
Est-ce la même chose que l’alerte sur les Freebox ?
Non. L’alerte Freebox était une erreur, les failles PHP sont réelles.
Le même jour, un recensement de l’entreprise Infrawatch avait fait croire que des millions de Freebox étaient exposées, parce que l’interface Freebox OS utilise des fichiers portant l’extension .php. Il s’agissait d’une erreur : les Freebox n’embarquent pas de serveur PHP, et Infrawatch a corrigé son rapport.
Cette fausse alerte ne doit pas faire oublier le vrai sujet. Les failles CVE-2026-109618 et CVE-2026-109619 sont confirmées par le projet PHP et le CERT-FR, avec des correctifs officiels.
Pour les particuliers, il n’y a rien à installer sur un téléphone, un ordinateur ou une box. C’est côté serveurs, donc côté propriétaires de sites, que l’action est nécessaire. Et tout message invitant à installer une « mise à jour PHP » sur son appareil est à ignorer.
Questions fréquentes
Mon site est-il concerné ?
S’il fonctionne avec une version de PHP antérieure aux correctifs du 21 octobre 2026, oui. Demandez la version exacte à votre hébergeur ou à votre développeur.
Quelles versions faut-il installer ?
PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la branche utilisée, ou une version plus récente.
Les anciennes versions sont-elles corrigées ?
Non. Les versions 8.1 et antérieures ne reçoivent pas de correctif officiel. Il faut migrer vers une branche maintenue.
Mettre à jour WordPress suffit-il ?
Non. La faille est dans le moteur PHP du serveur, qui doit être mis à jour par l’hébergeur ou l’administrateur.
Faut-il mettre son site hors ligne ?
Si la mise à jour ne peut pas être faite rapidement, le CERT-FR recommande d’isoler les équipements affectés en attendant.
Est-ce lié à l’alerte sur les Freebox ?
Non. L’alerte Freebox était une erreur de recensement. Les failles PHP, elles, sont confirmées et corrigées.
- CERT-FR — Alerte CERTFR-2026-ALE-014, multiples vulnérabilités dans PHP, 21 octobre 2026.
- JFrog Security Research — PHP2Shell : all you need to know about CVE-2026-109618 and CVE-2026-109619, 21 octobre 2026.
- Selectra — Failles PHP : ce que doivent faire les internautes, 21 octobre 2026.
- 01net — Une faille PHP critique vieille de dix ans touche des millions de sites, 22 octobre 2026.
WY-Créations accompagne depuis 2018 les artisans, les TPE, les PME et les professions libérales dans leur référencement sur Google, leur présence dans les réponses des IA et leur e-réputation.
Votre site tourne-t-il sur une version de PHP corrigée ?
Sites WordPress, hébergement, mises à jour, référencement : WY-Créations aide les entreprises à garder un site sûr, à jour et visible.