Mon site est-il vulnérable à la faille PHP ? Comment vérifier

C'est la première question. Quelques règles simples :

• WordPress, WooCommerce, Joomla, Drupal, PrestaShop, Magento : toujours PHP.
• Shopify, Wix, Squarespace, Webflow : pas de PHP sous votre responsabilité ; la plateforme gère les serveurs.
• Sur mesure : demandez à la personne qui l'a construit.

Si vous ne savez pas quel système votre site utilise, la vérification PHP le montre généralement tout de suite, parce que les sites laissent souvent des traces, comme une page wp-login.php.

Un site sûr tourne sur l'une de ces versions ou une version plus récente dans la même série : 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Ce sont les versions qui contiennent le correctif, voir les versions officielles de PHP.

Vous trouvez la version de trois manières :

1. dans le panneau de contrôle de votre hébergeur (cPanel, Plesk, DirectAdmin), généralement sous « Version PHP » ;
2. dans WordPress via Outils > Santé du site > Infos > Serveur ;
3. en la demandant à votre hébergeur ou à votre webdesigner.

Attention : « PHP 8.3 » sans le dernier chiffre ne dit rien. 8.3.35 est vulnérable, 8.3.36 ne l'est pas.

La vérification PHP gratuite de Marketing Scan envoie une seule requête ordinaire à votre page d'accueil, comme le fait un navigateur, et lit ce que le serveur indique à ce sujet. Cela donne l'un de ces quatre résultats :

• Obsolète : le serveur affiche une version de PHP qui ne reçoit pas de correctif. Urgent.
• Pas à jour : une version dans une série encore prise en charge, mais sans le correctif. À mettre à jour aujourd'hui.
• Masquée : votre site utilise PHP, mais n'affiche pas la version. C'est bien en soi, mais vous devez encore vous renseigner.
• Pas de PHP trouvé : aucune trace de PHP. Probablement pas concerné.

La vérification ne teste jamais la faille. Elle ne peut donc rien casser, et elle ne donne aucune garantie : seul votre hébergeur peut confirmer la version sur le serveur.

Envoyez ce message à votre hébergeur ou à votre webdesigner :

« Suite aux failles CVE-2026-109618 et CVE-2026-109619 : notre site tourne-t-il sur PHP, et si oui, sur quelle version exacte ? A-t-elle été mise à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 ? »

Si vous n'obtenez pas de réponse claire dans un jour ouvrable, téléphonez. Pour une faille avec un score CVSS de 9,2, comme le rapporte Tenable, attendre un jour, c'est déjà long.

Certaines choses donnent une fausse impression de sécurité :

• « Mon site a un cadenas (https). » Cela sécurise la connexion, pas le serveur.
• « WordPress est à jour. » WordPress et PHP sont deux choses distinctes. Un WordPress à jour sur une ancienne version de PHP reste vulnérable.
• « J'ai une extension de sécurité. » Elle tourne elle-même sur PHP et ne peut pas colmater la faille dans PHP.
• « Il ne s'est encore rien passé. » Selon VRT NWS, Cloudflare observe déjà les premières tentatives d'attaque.

Parmi les signaux : des administrateurs inconnus dans votre CMS, de nouveaux fichiers aux noms étranges, des redirections vers d'autres sites, ou un avertissement de Google dans la Search Console. Si vous remarquez quelque chose de ce genre, demandez à votre webdesigner, en plus de la mise à jour, de rechercher des fichiers laissés par un intrus. Une mise à jour ferme la porte, mais ne fait pas sortir un intrus qui est déjà entré.

Alors la balle est dans votre camp, car c'est vous qui êtes responsable des données qui arrivent via votre site. Trois options, de la plus rapide à la plus approfondie :

1. Activez vous-même une série PHP plus récente dans le panneau de contrôle de votre hébergeur, si c'est possible. Faites d'abord une sauvegarde.
2. Placez un pare-feu devant votre site, par exemple via Cloudflare. Selon VRT NWS, Cloudflare a déjà déployé des règles contre cette faille. Cela fait gagner du temps, mais ne règle pas le problème.
3. Mettez votre site en mode maintenance si vous traitez des données sensibles et que personne ne peut faire la mise à jour à court terme.

Un webdesigner qui ne donne pas de nouvelles pendant des jours après une faille de cette ampleur, c'est aussi un signal pour le long terme. Lors de votre prochain contrat, fixez le délai dans lequel les mises à jour de sécurité critiques doivent être faites.