// CLUBIC — CYBERSECURITY
Failles PHP : les correctifs sont disponibles, mais votre hébergeur protège-t-il vraiment votre site ?
Les correctifs des deux failles critiques de PHP sont disponibles depuis ce mercredi après-midi, alors que des tentatives d'exploitation sont déjà observées. Mais sont-ils réellement installés chez les hébergeurs ? Nos vérifications chez o2switch montrent que des protections provisoires ont été appliquées, sans que les nouvelles versions du langage soient encore déployées.
Les deux vulnérabilités critiques de PHP, référencées CVE-2026-109618 et CVE-2026-109619, ont fait l'objet de correctifs d'urgence ce 21 octobre. Elles peuvent permettre l'exécution de code à distance sans authentification, dans certaines configurations de serveur.L'urgence n'a rien de théorique : la société de cybersécurité watchTowr affirme avoir observé des tentatives d'exploitation sur son réseau mondial de leurres, tandis que Cloudflare confirme avoir détecté du trafic d'attaque. Ces observations ne démontrent toutefois pas, à elles seules, que des sites ont été compromis avec succès.
Derrière ces vulnérabilités se cache d'ailleurs une histoire étonnante : certaines faiblesses de PHP existaient depuis des années, avant que des chercheurs épaulés par l'intelligence artificielle ne parviennent à en démontrer l'exploitation. À lire sur Clubic 👇
Pour comprendre ce qui se passe concrètement chez les hébergeurs, nous avons effectué nos propres vérifications sur deux comptes o2switch que nous administrons, hébergés sur un même serveur mutualisé. À 16 h 40, les binaires PHP installés dataient toujours du 6 octobre : notamment PHP 8.3.35 et 8.4.26, alors que les versions corrigées 8.3.36 et 8.4.27 venaient d'être publiées.L'hébergeur avait néanmoins anticipé l'alerte. L'horodatage des fichiers de configuration php.ini indique une intervention dès 8 h 07 pour désactiver la fonctionnalité session.upload_progress. Les processus PHP avaient également été redémarrés après cette modification.
Interrogé par l'intermédiaire de son support technique, o2switch nous a répondu à 17 h 30 :
Dès que les correctifs adaptés à notre infrastructure seront disponibles et validés, nous procéderons à leur déploiement dans les meilleurs délais.
L'hébergeur s'appuie notamment sur CloudLinux, qui annonçait en fin d'après-midi préparer ses paquets corrigés, avec une publication prévue dans la soirée. Le fournisseur travaille également sur des correctifs rétroportés pour les anciennes branches PHP, jusqu'à la version 5.2.
D'autres acteurs ont pris les devants. OVHcloud confirme avoir déployé des règles WAF sur ses clusters et engagé une campagne de maintenance. SiteGround affirme avoir appliqué des protections sur l'ensemble de ses serveurs avant la sortie des correctifs. De son côté, Cloudflare indique protéger par défaut ses clients utilisant son pare-feu applicatif, y compris dans sa formule gratuite.Ces mesures ne sont toutefois pas équivalentes à une correction complète. Comme le rappelle le CERT-FR, la désactivation de session.upload_progress ne réduit la surface d'attaque que pour l'une des deux vulnérabilités.
Nos vérifications ont également révélé une difficulté moins visible. Sur l’un de nos comptes, un site WordPress était resté sous PHP 8.1, une branche dont le support officiel a pris fin. Une situation loin d’être isolée : selon Mallory, près de 59 % des serveurs exposés qui affichent leur version utilisent encore PHP 8.1 ou une version antérieure. Des correctifs sous forme de code source existent néanmoins pour cette branche, et des fournisseurs comme CloudLinux préparent leurs propres adaptations.
Pourquoi tant de sites restent-ils sur d’anciennes versions ? Souvent parce qu’une migration qui paraît simple ne l’est pas toujours. Depuis l’interface d’un hébergeur, passer à PHP 8.3 se fait en quelques clics. En préparant la migration de ce site vers PHP 8.3, nous avons constaté que 34 modules étaient activés pour cette version, contre 66 pour PHP 8.1. Plusieurs composants nécessaires au site et à ses extensions, comme mbstring, gd ou intl, devaient être réactivés av