Faille PHP critique : ce qu’il faut demander à votre hébergeur aujourd’hui
Situation au 22 octobre 2026. Les informations de cet article viennent des annonces officielles du projet PHP et de la presse spécialisée ; je le mettrai à jour si elles évoluent.
Le 21 octobre 2026, le projet PHP a publié des correctifs d’urgence pour deux failles qualifiées de critiques, surnommées « PHP2Shell ». PHP est le langage sur lequel tourne une grande partie des sites web : WordPress, Joomla, PrestaShop, Dolibarr et beaucoup de sites faits sur mesure l’utilisent. Si votre site en fait partie, la question n’est pas de savoir si cela vous concerne, mais si votre hébergeur a déjà appliqué la mise à jour.
Ce qui s’est passé
Deux failles, identifiées CVE-2026-109618 et CVE-2026-109619 (un numéro de catalogue public pour chaque faille de sécurité), permettent à un attaquant d’exécuter du code sur le serveur à distance, sans avoir besoin d’un identifiant ni d’un mot de passe. En clair : quelqu’un qui envoie une requête soigneusement construite à un site vulnérable peut y faire tourner ses propres commandes, par exemple pour y installer un programme malveillant ou lire des données.
Le projet PHP donne à chaque faille la note de 9,2 sur 10 (échelle CVSS v4.0, qui mesure la gravité). Le détail du score indique une attaque d’une complexité élevée, mais le projet précise qu’un exploit a été démontré, sur la configuration la plus courante avec Apache (le module « mod_php »), où la requête agit avant même que le code de votre site ne s’exécute. D’après BleepingComputer, Cloudflare a observé des attaques précoces. Je n’ai en revanche pas trouvé de confirmation d’une exploitation massive à ce stade.
Quelles versions de PHP sont concernées
Les versions corrigées sont :
Branche de PHP
Version corrigée
8.5
8.5.12
8.4
8.4.27
8.3
8.3.36
8.2
8.2.35
Toute version antérieure de ces branches est vulnérable. Deux points importants :
PHP 8.1 et les versions plus anciennes ne sont plus maintenues par le projet PHP. Certains hébergeurs et distributions proposent des correctifs de leur côté, d’autres non. Si votre site tourne encore sur une version ancienne, la bonne réponse est de migrer vers une version maintenue.
PHP 8.2 arrive en fin de vie le 31 décembre 2026. Même mise à jour, il faudra prévoir la suite avant la fin de l’année.
Le projet PHP est clair sur un point : seule la mise à jour règle le problème. Il existe des mesures provisoires (limiter la taille des requêtes acceptées, désactiver certaines options), mais elles réduisent l’exposition sans rendre le serveur sûr.
Qui doit faire la mise à jour
Cela dépend de la façon dont votre site est hébergé.
Hébergement mutualisé (votre site partage un serveur avec d’autres, cas fréquent en TPE) : c’est l’hébergeur qui met à jour PHP sur le serveur. Vous ne pouvez pas le faire vous-même, mais vous pouvez vérifier que c’est fait. Dans votre espace client, vous choisissez souvent une branche de PHP (8.3, par exemple), pas le numéro de correctif exact : c’est donc à l’hébergeur de confirmer que le correctif est installé.
Serveur dédié ou serveur privé virtuel (VPS) : la mise à jour revient à la personne qui administre le serveur, vous-même ou votre prestataire. Les distributions Linux ont reçu les correctifs à l’avance : il faut installer les mises à jour de paquets du système, puis redémarrer le service web.
Plateforme clés en main (vous ne louez pas de serveur, l’éditeur gère tout) : la correction revient à l’éditeur. Rien à installer de votre côté, mais vous pouvez lui demander s’il est concerné.
NAS qui héberge un site : certains NAS savent servir un site web (Web Station sur Synology, par exemple) et embarquent alors PHP. Si c’est votre cas, la question vaut aussi pour l’éditeur du NAS. Je n’ai pas vérifié, ce matin, si Synology ou QNAP ont publié un avis sur ce sujet.
Les quatre questions à poser à votre hébergeur
Un message court suffit. Voici ce que je demanderais :
Quelle version de PHP fait tourner mon site ? Si vous ne savez pas répondre vous-même, c’est la première chose à obtenir.
Le correctif des failles CVE-2026-109618 et CVE-2026-109619 est-il installé ? C’est-à-dire PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le correctif équivalent chez votre hébergeur.
À quelle date l’a-t-il été ? Cela permet de savoir si une période de risque s’est écoulée avant la correction.
Si ma version est ancienne (8.1 ou avant), que prévoyez-vous ? Correctif fourni par vous, ou migration vers une version maintenue ?
Gardez la réponse écrite : elle servira de preuve si un problème apparaît plus tard.
Et si votre hébergeur ne répond pas ?
Dans ce cas, ne laissez pas le site en l’état en attendant. Trois pistes :
Relancez le support en précisant que la faille est critique et que vous attendez une réponse datée.
Vérifiez si vous pouvez choisir une version de PHP plus récente depuis votre espace client, après avoir testé que votre site fonctionne avec. Un passage de version peut casser un plugin ou un thème ancien : faites une sauvegarde avant et testez après.
Si le site n’est pas indispensable à votre activité, la mise hors ligne temporaire est une option. Le centre britannique de cybersécurité l’a lui-même évoquée pour les systèmes qu’on ne peut pas corriger.
Après la mise à jour
La mise à jour ferme la porte, elle ne chasse pas quelqu’un déjà entré. Comme des attaques ont été observées dès le début, quelques vérifications ne coûtent pas cher :
Des fichiers que vous ne reconnaissez pas dans le dossier du site, ou des pages qui n’ont rien à voir avec votre activité.
Un site soudainement lent, des redirections vers d’autres sites, des mails de votre domaine envoyés à votre insu.
Des comptes administrateurs que vous n’avez pas créés (sur WordPress, dans Utilisateurs).
En cas de doute, la solution la plus sûre est de restaurer une sauvegarde saine puis d’appliquer la mise à jour. C’est une raison de plus pour avoir une sauvegarde du site séparée de l’hébergeur, testée.
À retenir
Deux failles critiques de PHP, exploitables sans mot de passe, corrigées le 21 octobre 2026.
Les versions à viser : PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. PHP 8.1 et avant ne sont plus maintenues.
En hébergement mutualisé, c’est à l’hébergeur d’agir : posez-lui les quatre questions et gardez la réponse.
Les mesures provisoires ne suffisent pas. Seule la mise à jour règle le problème.
Une fois à jour, jetez un œil à d’éventuels fichiers ou comptes inconnus.
Un doute sur votre site ?
Si vous ne savez pas où votre site est hébergé ni quelle version de PHP il utilise, contactez-moi via makantet.fr/contact : je commence par un état des lieux de votre hébergement et de votre site, et je vous dis ce qu’il faut demander, à qui.
Ce site utilise des cookies techniques nécessaires à son fonctionnement. Avec votre accord, il affiche aussi la carte interactive Google Maps de la page Contact, qui dépose ses propres cookies. Vous pouvez modifier votre choix à tout moment via le lien « Gérer les cookies » en bas de page.
En savoir plus
