Ni WordPress ni votre navigateur : pourquoi ces failles PHP se corrigent dans les coulisses de votre site
Ces deux vulnérabilités touchent PHP, le logiciel qui fait fonctionner de nombreux sites sur leur serveur, et non votre navigateur. Comprendre cette différence explique pourquoi une mise à jour de WordPress ne suffit pas et ce que doit corriger l’hébergeur.
L'essentiel
- Les deux failles permettent potentiellement de faire exécuter du code au serveur sans connexion à un compte.
- PHP est une couche commune à de nombreux sites, notamment ceux utilisant WordPress.
- Corriger l’application ne remplace pas la correction du moteur PHP qui la fait fonctionner.
- Une protection provisoire peut limiter l’exposition sans remplacer le correctif.
PHP, une même couche technique derrière des sites très différents
Deux sites peuvent n’avoir ni le même aspect ni le même usage, tout en dépendant du même logiciel. PHP travaille côté serveur, dans les coulisses du site que vous consultez. Il fait notamment fonctionner des applications comme WordPress, Drupal, Magento ou Joomla. On le retrouve aussi dans des outils de gestion d’hébergement. Le point commun vulnérable n’est donc pas forcément visible à l’écran.
Cette présence explique l’ampleur potentielle du problème. Le relevé de W3Techs cité par Numerama attribue à PHP une part de 69,3 % parmi les sites dont la technologie serveur est identifiée. Attention au périmètre : ce chiffre mesure son utilisation, pas la proportion de sites effectivement attaqués ou vulnérables. Il montre surtout pourquoi un défaut dans cette couche commune peut concerner des services très éloignés les uns des autres.
Une exécution à distance, sans avoir besoin d’un compte
Les références CVE-2026-109618 et CVE-2026-109619 désignent les deux vulnérabilités. Leur gravité atteint 9,2 sur l’échelle CVSS v4.0, graduée jusqu’à 10. Toutes deux peuvent ouvrir la voie à une exécution de code à distance sans authentification. Cela veut dire qu’un attaquant peut potentiellement faire exécuter des instructions par un serveur vulnérable via Internet, sans devoir d’abord se connecter avec un identifiant et un mot de passe.
Le risque dépasse donc une page qui s’affiche mal ou un service momentanément indisponible. GoDaddy évoque des données dérobées, le contenu d’un site modifié ou une compromission complète. Le serveur devient la cible, pas seulement la partie du site accessible aux visiteurs. L’absence d’authentification nécessaire explique aussi pourquoi réserver des comptes aux seules personnes autorisées ne supprime pas, à elle seule, cette voie d’attaque.
WordPress et PHP ne se mettent pas à jour au même niveau
Imaginez votre site WordPress et le moteur qui le fait tourner : ils travaillent ensemble, mais restent deux logiciels distincts. Une mise à jour de WordPress porte sur l’application. Or ces vulnérabilités concernent PHP, en dessous. Une application à jour peut donc encore fonctionner avec un moteur vulnérable. Le même raisonnement vaut pour les autres applications reposant sur PHP : leur propre entretien ne remplace pas celui de cette dépendance.
Une correction côté hébergeur désigne l’intervention sur le PHP utilisé par l’infrastructure d’hébergement. Une correction côté serveur vise cette même couche technique, sous la responsabilité de l’équipe qui administre la machine. La différence porte sur qui intervient, pas sur l’objectif. Pour un site hébergé chez un prestataire, cliquer sur la mise à jour de l’application ne prouve donc pas que le moteur installé chez ce prestataire a lui aussi été corrigé.
Une protection temporaire n’est pas un moteur corrigé
Les versions corrigées citées sont PHP 8.5.12 et 8.4.27, ainsi que 8.3.36 et 8.2.35. Le numéro complet compte : appartenir à une branche récente ne suffit pas à établir que le correctif est présent. Pour les installations plus anciennes, la situation diffère encore : PHP 8.1 et les branches antérieures ne bénéficient plus des mises à jour régulières du projet. Des correctifs minimaux en code source existent néanmoins pour les branches 8.1, 8.0 et 7.4.
Un hébergeur peut aussi interposer des protections avant de remplacer le logiciel vulnérable. Cloudflare a notamment adapté ses règles de pare-feu face au trafic d’attaque observé. Ces filtres cherchent à réduire l’exposition ; ils ne corrigent pas PHP lui-même. Voilà la distinction essentielle pour comprendre l’état d’un site : être protégé provisoirement et utiliser une version corrigée ne décrivent pas la même situation technique.
