19mn de lecture
Mise à jour du 22 octobre :
Le correctif est installé sur l’ensemble de nos hébergements mutualisés, pour toutes les versions de PHP que nous proposons, ainsi que sur notre infrastructure. Toutes les protections temporaires sont levées.
Hébergements cPanel : le correctif a été intégré directement dans les versions installées, sans modifier leur numéro. Votre PHP est bien protégé. Par précaution, le suivi de progression des envois (session.upload_progress) y est désormais désactivé de façon permanente, et un script qui dépasse sa limite de mémoire est maintenant arrêté immédiatement, sans exécuter ses fonctions de fermeture.
Anciennes versions de PHP : sur certains de nos serveurs mutualisés, les sites qui utilisaient encore une version antérieure à PHP 5.6 ont été migrés vers PHP 5.6, et les clients concernés ont été prévenus par e-mail. Ces versions ne sont plus proposées. Si votre site affiche des erreurs depuis cette migration, contactez notre support.
VPS infogérés : le correctif est installé sur la grande majorité des serveurs. Ceux qui ne pouvaient pas être mis à jour conservent les protections temporaires et sont suivis au cas par cas. VPS non infogérés : si ce n’est pas encore fait, mettez PHP à jour en suivant les étapes ci-dessous.
Contexte
Deux failles PHP critiques ont été corrigées ce mercredi 21 octobre 2026 : l’équipe de PHP a publié à 16h (heure de Paris) une mise à jour de sécurité d’urgence. Ces failles se trouvent dans PHP lui-même : tous les serveurs qui l’utilisent sont concernés, quel que soit leur hébergeur.
Chez LWS, nos équipes ont appliqué des mesures préventives dès le matin, puis déployé le correctif sur nos serveurs dès sa publication. Voici le point sur la situation et ce que vous devez vérifier de votre côté.
Ce que l’on sait sur ces failles PHP
Ces deux failles PHP sont classées critiques, avec un score de 9,2 sur 10 selon le barème CVSS v4.0. Leurs détails techniques ont été publiés avec le correctif.
Ce que PHP avait annoncé. Le 20 octobre, l’équipe de PHP a annoncé cette mise à jour exceptionnelle dans une annonce officielle et invité tous les utilisateurs à se préparer. Les versions touchées et les versions corrigées devaient être publiées avec le correctif.
Ce que rapportaient les chercheurs. Des informations ont fuité le 20 octobre, avant l’annonce officielle. La société de sécurité watchTowr disait avoir confirmé l’existence des failles, référencées CVE-2026-109618 et CVE-2026-109619, et les décrivait comme des failles d’exécution de code à distance : un attaquant pourrait faire exécuter ses propres commandes par un serveur.
Aucune attaque n’avait été observée au 20 octobre. En revanche, les chercheurs s’attendaient à voir circuler un code d’exploitation peu après la sortie du correctif, d’où l’urgence de l’appliquer.
Ce que PHP a publié le 21 octobre. Les deux failles permettent d’exécuter du code à distance sans authentification, avant même que votre site ne se charge. La première (CVE-2026-109618) passe par une corruption de la mémoire après une saturation, la seconde (CVE-2026-109619) par des données laissées en mémoire après la fin d’une requête. Toutes les installations de PHP qui répondent à des requêtes web sont exposées, quel que soit leur mode de fonctionnement (PHP-FPM, Apache avec mod_php, CGI, LiteSpeed…). Selon PHP, le risque est le plus élevé avec mod_php.
PHP ne publie de versions corrigées que pour les branches 8.2 à 8.5. Vu la gravité des failles, son équipe de sécurité a tout de même fourni des correctifs minimaux pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes. Pour les autres versions anciennes, certains éditeurs et distributions Linux proposent leurs propres correctifs. Le détail est disponible dans l’avis de sécurité de PHP.
Failles PHP : les 5 mesures mises en place par LWS
Nous n’avons pas attendu le correctif : plusieurs protections ont été activées dès le matin du 21 octobre, avant même sa publication.
Désactivation du suivi de progression des envois. Le paramètre PHP session.upload_progress.enabled a été désactivé dès le matin sur nos serveurs cPanel, puis sur nos autres plateformes, dont l’ensemble des VPS infogérés, avec une vérification de chaque service avant et après la modification. Ce paramètre contrôle l’une des fonctions mises en cause, qui sert uniquement à afficher certaines barres de progression pendant un envoi de fichier. La plupart des sites ne l’utilisent pas.
Cloisonnement des comptes. Sur nos hébergements cPanel, chaque compte fonctionne dans un environnement isolé des autres. La portée d’une éventuelle attaque reste ainsi limitée au seul compte visé. Des limites sur les envois de fichiers volumineux sont aussi en place depuis plusieurs années.
Blocage temporaire des envois de fichiers. En attendant le correctif, nous avons bloqué les envois de fichiers via les formulaires de vos sites (images, pièces jointes, imports de données). Ce blocage a été levé une fois PHP mis à jour sur votre serveur.
Surveillance renforcée. Nos équipes surveillent les tentatives d’exploitation sur nos serveurs pour pouvoir réagir immédiatement.
Déploiement du correctif. Dès sa publication à 16h, nous avons commencé à installer les versions corrigées de PHP sur l’ensemble des serveurs que nous gérons. L’opération s’est poursuivie dans la nuit. Les serveurs qui ne pouvaient pas être mis à jour immédiatement ont conservé les protections temporaires.
Quel impact sur vos services ?
Vos visiteurs ont toujours pu consulter vos sites, mais certaines actions ont été temporairement impossibles pendant le déploiement du correctif. Ces restrictions sont levées depuis le 22 octobre au matin.
Ce qui a continué de fonctionner :
- la consultation de vos sites ;
- les formulaires sans fichier joint : connexion, création de compte, mot de passe, contact.
Ce qui a pu être bloqué ou perturbé :
- l’envoi de fichiers depuis vos sites : images, pièces jointes, imports CSV ou XML ;
- certains formulaires envoyés en JavaScript, même sans fichier joint ;
- pendant le déploiement du correctif, l’accès à certains services : sites, webmail, LWS Panel, API.
Si un envoi ou un enregistrement échoue encore avec une erreur 403 (accès refusé), contactez notre support.
Comment protéger votre site contre ces failles PHP
Hébergement mutualisé, cPanel et WordPress
Vous n’avez rien à faire pour le correctif : nous l’avons installé nous-mêmes sur nos serveurs. Profitez-en tout de même pour vérifier deux points.
- Votre version de PHP. Si votre site tourne encore sous PHP 7.x, 8.0 ou 8.1, passez à une version maintenue depuis votre LWS Panel ou votre cPanel. Ces versions ne sont plus maintenues par PHP et ne recevront pas les prochains correctifs de sécurité. Testez votre site après le changement et privilégiez PHP 8.3 ou plus récent, car PHP 8.2 ne sera plus maintenu après le 31 décembre 2026.
- Vos extensions et thèmes. Gardez WordPress, vos thèmes et vos extensions à jour, surtout ceux qui gèrent des envois de fichiers.
VPS et serveurs dédiés
VPS infogérés. Nous avons installé le correctif sur la grande majorité de ces serveurs, et les derniers sont traités au cas par cas. Si vous avez personnalisé le paramètre session.upload_progress.enabled dans votre configuration PHP, notre mesure temporaire ne s’applique pas sur votre serveur : passez-le à Off tant que votre VPS n’est pas à jour.
VPS non infogérés et serveurs dédiés. Si vous administrez vous-même votre serveur, c’est à vous d’appliquer la mise à jour, en suivant les étapes ci-dessous.
Installez les versions corrigées dès maintenant. Votre serveur doit tourner au minimum sous PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Passez par votre gestionnaire de paquets ou votre panneau d’administration (cPanel/WHM, Plesk, ISPConfig…). Sous Debian, le dépôt packages.sury.org propose les paquets corrigés. Si vous utilisez le PPA Ubuntu ondrej/php, vérifiez la version réellement installée : il a été mis à jour plus tard.
En attendant la mise à jour, appliquez la mesure temporaire. Désactivez le suivi de progression des envois dans le php.ini utilisé par votre serveur web (PHP-FPM ou Apache, pas celui de la ligne de commande), puis redémarrez le service :
session.upload_progress.enabled = OffSous Debian ou Ubuntu, le plus simple est de placer cette ligne dans un petit fichier dédié du dossier conf.d de PHP-FPM, par exemple /etc/php/8.4/fpm/conf.d/. Il restera en place lors des mises à jour.
Si aucune mise à jour n’est disponible pour votre système. C’est le cas des distributions qui ne sont plus maintenues, comme Debian 10 ou antérieure. Gardez la mesure temporaire active, appliquez les autres mesures de réduction du risque listées dans l’avis de sécurité de PHP, et planifiez au plus vite la migration vers un système et une version de PHP maintenus. Ces mesures limitent le risque mais ne remplacent pas une mise à jour.
Vérifiez votre code. Si vous avez développé des scripts qui acceptent des envois de fichiers, relisez-les et limitez leur accès si possible.
Et ensuite ?
Le correctif est installé sur l’ensemble de nos hébergements mutualisés et sur la grande majorité de nos VPS infogérés. Nos équipes continuent de suivre les derniers serveurs et les nouvelles informations publiées par PHP.
Pour toute question, notre support reste à votre disposition.
Merci pour votre patience et votre compréhension.
Sources : avis de sécurité de PHP · annonce officielle de PHP · article d’IT-Connect
