Faille PHP d'octobre 2026 : comment savoir si votre site est concerné

Le 21 octobre 2026, le projet PHP a publié des versions correctives pour deux failles critiques, référencées CVE-2026-109618 et CVE-2026-109619. PHP les note toutes deux 9,2 sur 10 et indique qu’elles peuvent permettre l’exécution de code à distance, sans authentification, à partir d’une requête HTTP forgée.

Elles concernent PHP lui-même, donc tout site qui l’utilise, WordPress ou non. Cet article explique comment vérifier la situation de votre site en quelques minutes, quoi faire selon le résultat, et comment rechercher d’éventuels signes de compromission.

Ce qui est concerné

Les failles sont dans PHP lui-même, pas dans WordPress. Tout site ou applicatif qui tourne sur une version de PHP non corrigée est concerné : WordPress, mais aussi Prestashop, Magento, Drupal, un framework comme Laravel ou Symfony, ou un site sans framework.

Une conséquence directe : mettre à jour WordPress, votre thème ou vos extensions est une bonne pratique, mais ne corrige pas cette faille. PHP est installé côté serveur, donc la mise à jour se fait chez votre hébergeur, ou sur votre serveur si vous l’administrez vous-même.

Les versions qui contiennent le correctif :

Les notes de version de PHP précisent qu’il n’existe pas de contournement complet : mettre à jour est la seule solution sûre.

Selon le Centre canadien pour la cybersécurité, toutes les installations PHP qui servent des requêtes web sont exposées, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, le risque étant le plus élevé avec mod_php, où l’attaque peut aboutir avant l’exécution du code de l’application.

Au 22 octobre, les sources divergent sur le niveau d’activité.

Des tentatives d’exploitation sont signalées depuis le 21 octobre : selon Webhosting Today, watchTowr dit avoir observé une exploitation avec ses pièges (honeypots) et Patchstack des attaques de sondage, tandis que Rapid7 cite de multiples tentatives sans avoir observé d’exploitation lui-même, et que le Centre canadien pour la cybersécurité n’en identifie pas d’active.

Des preuves de concept circulent, et les détails des failles avaient fuité le 20 octobre, avant la publication. Ces sources ne font pas état de compromissions confirmées de sites, mais ce n’est pas une raison d’attendre : les sites non mis à jour sont exposés.

Vérifier la version de PHP

Pour un site sous WordPress :

1. Connectez-vous à l’administration.
2. Allez dans Outils > Santé du site, onglet Info.
3. Ouvrez la section Serveur et lisez la ligne Version de PHP.

Comparez ensuite avec le tableau ci-dessus. Un numéro comme 8.3.30 appartient à la bonne branche, mais il est plus ancien que 8.3.36 : il n’est donc pas corrigé, sauf si votre hébergeur a appliqué lui-même le correctif (voir plus bas).

Si votre site n’est pas sous WordPress, le panneau de votre hébergeur affiche généralement la version de PHP choisie pour chaque site.

Si vous avez un accès en ligne de commande, php -v donne la version utilisée en console, qui peut différer de celle qui sert les pages web. Le plus fiable est de vérifier celle du site lui-même.

Pour les personnes à l’aise avec le transfert de fichiers, un fichier phpinfo() temporaire donne la version servie, mais préférez d’abord le panneau de votre hébergeur : ce fichier expose des informations sensibles, alors donnez-lui un nom que personne ne peut deviner et supprimez-le dans la minute qui suit la lecture.

Un cas est à connaître : un correctif ne change pas toujours le numéro affiché. Pour les branches en fin de vie, les numéros restent en général 8.1.34, 8.0.30 et 7.4.33 que le site soit corrigé ou non, d’après Techdows, alors que certains panneaux publient leurs propres numéros.

Certains hébergeurs et éditeurs de distributions peuvent aussi corriger une branche sans changer son numéro, en appliquant le correctif sur leurs propres paquets plutôt qu’en passant à la version publiée par PHP.

Selon CyberPanel, c’est le cas de paquets proposés pour PHP 8.1 sur Ubuntu 22.04, PHP 7.4 et 7.2 sous Ubuntu Pro, ou plusieurs branches sur AlmaLinux 8. Selon Linux Compatible, le dépôt d’Ondřej Surý pour Debian et Ubuntu a republié des paquets corrigés pour les branches anciennes, jusqu’à PHP 5.6. aaPanel indique de son côté proposer des versions corrigées pour les branches 8.5, 8.4, 8.3, 8.2, 8.1, 8.0 et 7.4, selon le catalogue de chaque installation.

Un numéro ancien ne signifie donc pas forcément un site exposé, et un numéro inchangé ne prouve pas qu’il est protégé. Seule une confirmation écrite de l’hébergeur, qui indique ce qui a été fait sur votre site, ou l’avis de sécurité de la distribution, permet de trancher.

Que faire selon le résultat

La version est corrigée (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récente dans la même branche). Vous n’avez rien à mettre à jour côté PHP. La vérification de compromission, plus bas, reste utile, surtout si votre hébergeur n’a changé de version qu’après le 21 octobre : le site a pu rester exposé quelques heures ou quelques jours.

La branche est suivie, mais le numéro est plus ancien. Contactez votre hébergeur et demandez-lui par écrit si le correctif est posé sur votre offre. La plupart des hébergeurs proposent un sélecteur de version de PHP dans leur panneau : si une version corrigée y apparaît, vous pouvez la choisir directement. Sinon, certains hébergeurs sont encore en train de déployer : consultez aussi leurs annonces ou leur page d’état. Conservez la réponse écrite, elle vous servira de justificatif. Faites une sauvegarde avant de changer de version.

La version est PHP 8.1 ou plus ancienne. Le projet PHP ne publie pas de version officielle pour ces branches, qui sont en fin de vie. Pour 8.1, 8.0 et 7.4, son équipe de sécurité a toutefois fourni des correctifs sous forme de code source, que les hébergeurs et les éditeurs de distributions peuvent intégrer. Deux situations se présentent. Soit votre hébergeur ou l’éditeur de la distribution fournit un correctif : demandez-lui de le confirmer par écrit, avec la référence du paquet ou de l’avis de sécurité, sachant que le numéro de version affiché ne change pas. Soit aucun correctif n’existe pour votre configuration, et il faut passer à une branche corrigée, par exemple 8.3 ou 8.4, après une sauvegarde complète et un test. Sur un site ancien, certains thèmes ou extensions peuvent ne pas fonctionner avec la nouvelle version : faites l’essai d’abord sur une copie, avec un accompagnement si le site est important pour votre activité.

Vous administrez vous-même votre serveur (VPS ou serveur dédié). Voir la section « Pour les administrateurs de serveur », plus bas.

Votre hébergeur ne répond pas, ou répond sans rien préciser. Relancez-le par écrit en demandant une date et la version de PHP qui sera en place. Une absence de réponse prolongée sur une faille de cette gravité mérite d’être prise en compte dans votre décision de rester ou non chez lui. Migrer vers un hébergement qui publie ses correctifs rapidement est une option, pas une obligation : si votre hébergeur déploie et répond clairement, rien ne vous impose de changer. En attendant un correctif confirmé, le Centre canadien pour la cybersécurité recommande, lorsque la mise à jour est impossible, d’envisager d’isoler les applications exposées des réseaux publics : pour un site peu critique, cela peut aller jusqu’à suspendre temporairement son accès public.

Pour les administrateurs de serveur

Cette section s’adresse à celles et ceux qui administrent eux-mêmes leur serveur (VPS ou serveur dédié). La maintenance de votre outil vous incombe, personne ne la fera à votre place :

• Mettez à jour PHP avec le gestionnaire de paquets de votre distribution ou le dépôt que vous utilisez, puis redémarrez le service qui exécute PHP (par exemple PHP-FPM). La mise à jour d’un paquet ne suffit pas tant que l’ancien processus tourne. Sur une distribution, le correctif peut arriver sans changement de branche : l’avis de sécurité de la distribution (pour Ubuntu, les notices USN) indique quel paquet le contient.
• Si vous avez compilé PHP vous-même sur une branche en fin de vie, appliquez le correctif source de l’équipe de sécurité de PHP à votre version exacte, recompilez avec les mêmes options de configuration, installez, puis redémarrez tous les processus PHP.
• Vérifiez ensuite la version servie par le site lui-même, pas seulement celle de la console.
• Si votre site tourne dans un conteneur, reconstruisez l’image en récupérant la dernière version de l’image de base (option --pull), puis redéployez.

En attendant la mise à jour, les avis consultés citent trois réglages transitoires.

• Les deux premiers, repris par aaPanel et CyberPanel, ne couvrent que des chemins d’attaque précis de la faille CVE-2026-109619 : session.upload_progress.enabled = 0 et, pour PHP 8.5, fatal_error_backtraces = 0. Ils se placent dans le fichier php.ini (et non par ini_set() ni dans un fichier .user.ini), pour s’appliquer avant le traitement des requêtes, puis les processus PHP doivent être redémarrés.
• Le troisième, memory_limit = -1, à éviter sauf avis contraire de votre hébergeur, cité par Rapid7 et Sevalla, vise l’épuisement de mémoire de la première faille (CVE-2026-109618) : il n’empêche pas toujours l’échec d’allocation d’atteindre le code vulnérable, et CyberPanel déconseille de l’appliquer sans discernement, car il supprime la limite de mémoire par requête, donc un seul processus peut consommer toute la mémoire du serveur.

Aucun de ces réglages ne remplace la mise à jour, qui reste la seule remédiation complète.

De plus, il est à noter qu’un serveur LiteSpeed ou OpenLiteSpeed utilise ses propres binaires PHP (lsphp), distincts des paquets PHP du système, quel que soit le panneau de contrôle qui le pilote, ou même en l’absence de panneau. Deux versions de PHP peuvent donc coexister : celle qui sert le site et celle du système, utilisée en ligne de commande, qui ne sont pas forcément mises à jour en même temps. Les paquets lsphp* se mettent à jour avec le gestionnaire de paquets du système : l’avis d’aaPanel le recommande, son script d’installation ne gérant pas les mises à jour de LSPHP. Certains panneaux, comme CyberPanel, embarquent en plus leur propre binaire PHP pour leur interface : l’avis de CyberPanel détaille comment le contrôler et le remplacer, au cas par cas selon la distribution, et recommande de vérifier la version réellement servie par une requête HTTP.

Concernant le mode ligne de commande (CLI), les avis consultés visent les installations qui servent des requêtes web et ne se prononcent pas sur le mode CLI : le risque documenté y est moindre, mais mieux vaut ne pas l’exclure, et la mise à jour de PHP couvre de toute façon ce mode.

Rechercher des signes de compromission

Une exécution de code à distance laisse parfois des traces que vous pouvez rechercher. Ces vérifications cherchent des indices : l’absence d’anomalie visible ne prouve pas l’absence de compromission, et ces symptômes peuvent avoir d’autres causes que ces deux failles :

• Des fichiers .php suspects à examiner (que personne n’a ajoutés volontairement), notamment dans le dossier wp-content/uploads de WordPress, où l’on ne devrait trouver que des images, des documents et des médias.
• Des comptes administrateurs inconnus dans la liste des utilisateurs de WordPress.
• Des redirections inattendues, des pages de spam que vous n’avez pas créées, ou un site soudainement lent.
• Des courriels sortants anormaux : votre hébergeur ou votre service de messagerie peut signaler un volume inhabituel.

En l’absence de trace, il reste prudent de changer les mots de passe administrateur, ainsi que ceux de la base de données si vous avez un doute sur la période d’exposition. Si vous trouvez une trace, mettre PHP à jour ne suffit pas, et l’ordre des opérations compte :

1. Isolez le site en suspendant son accès public ou en le restreignant au niveau du serveur web, du pare-feu ou du proxy (le mode maintenance de WordPress exécute encore PHP, il ne suffit pas). Conservez les journaux et les fichiers suspects avant tout nettoyage.
2. Cherchez l’étendue de la compromission et le point d’entrée, puis corrigez-le.
3. Restaurez à partir d’une sauvegarde vérifiée et antérieure à l’incident, puis renouvelez tous les accès (administration, base de données, FTP, clés d’API) depuis un environnement sain, avant la remise en ligne.

Dans ce cas, un accompagnement est justifié.

Et la CNIL ?

Si l’incident touche des données personnelles, il peut s’agir d’une violation de données au sens du RGPD. Une simple liste d’adresses de courriel constitue déjà un ensemble de données personnelles. Une violation peut concerner la confidentialité, l’intégrité ou la disponibilité des données, même sans preuve de vol. Elle doit toujours être documentée en interne ; elle doit être notifiée à la CNIL dans les 72 heures après que vous en avez eu connaissance, sauf si elle n’est pas susceptible d’engendrer un risque pour les personnes concernées, et les personnes doivent être informées si le risque est élevé (articles 33 et 34 du RGPD). La notification peut être complétée au fil de l’enquête : il n’est pas nécessaire d’attendre ses conclusions. En l’absence d’incident, une faille seule n’est pas une violation. Je fais de l’audit technique, pas du conseil juridique : en cas de doute, rapprochez-vous de la CNIL ou d’un juriste.

Sources

Sources consultées les 22 et 23 octobre 2026.

• Notes de version PHP 8.5.12 – projet PHP
• Notes de version PHP 8.4.27 – projet PHP
• Branche du correctif pour PHP 8.1 – projet PHP
• Avis de sécurité GHSA-w8hw-w9fx-j79w (CVE-2026-109618) – projet PHP (en anglais)
• Avis de sécurité CVE-2026-109618 et CVE-2026-109619 – Sevalla (en anglais)
• Réponse de CyberPanel à la faille PHP d’octobre 2026 – CyberPanel (en anglais)
• Mise à jour de sécurité PHP critique – aaPanel (en anglais)
• Two critical PHP flaws leaked ahead of the October 21 security release – Webhosting Today (en anglais)
• PHP 8.1, 8.0 and 7.4 security fix for CVE-2026-109618: options for end-of-life versions – Techdows (en anglais)
• PHP2Shell patch: Sury.org ships Debian and Ubuntu updates for every PHP version – Linux Compatible (en anglais)
• Alerte AL26-026 : vulnérabilités critiques de PHP – Centre canadien pour la cybersécurité (en anglais)
• CVE-2026-109618 et CVE-2026-109619 : exécution de code à distance non authentifiée dans PHP – Rapid7 (en anglais)
• Notifier une violation de données personnelles – CNIL