Le 21 octobre 2026, l’Agence nationale tchèque pour la cybersécurité et la sécurité de l’information (NÚKIB) a signalé deux failles critiques dans PHP, le langage de programmation sur lequel fonctionne la majorité des sites web dans le monde. Les spécialistes les appellent php2shell (CVE-2026-109618 et CVE-2026-109619). Elles permettent à un attaquant d’exécuter son propre programme sur le serveur, et ce sans aucun mot de passe. Les détails ont fuité avant même la publication des correctifs et une méthode d’exploitation est accessible publiquement.

Il existe une solution, et une seule : mettre à jour PHP. Nous expliquons ci-dessous comment savoir si vous êtes concerné et que faire selon l’endroit où fonctionne votre site.

Suis-je concerné ?

Probablement oui, si votre site ou votre application fonctionne sur :

  • WordPress, Joomla, Drupal ou un autre système de gestion de contenu auquel vous vous connectez via /wp-admin ou /administrator,
  • une boutique en ligne sur votre propre hébergement (PrestaShop, WooCommerce, Magento),
  • un système de commande ou de réservation, un intranet, un système de pointage ou une autre application web sur mesure, si elle est écrite en PHP.

Vous n’êtes pas concerné si votre site ou votre boutique fonctionne sur un service clés en main où vous ne gérez pas le serveur (Shoptet, Webnode, Wix et similaires). Dans ce cas, c’est l’exploitant du service qui s’occupe de la mise à jour.

Point important : la force de votre mot de passe d’administration n’y change rien. La faille se trouve dans PHP lui-même et l’attaquant l’exploite avant même que le site ne vérifie la connexion.

Que faire selon l’endroit où fonctionne votre site

Site sur un hébergement mutualisé (Wedos, Websupport, Active24 et autres)

La plupart des grands hébergeurs mettent PHP à jour eux-mêmes et rapidement. Vérifiez-le quand même :

  1. Connectez-vous à l’administration de votre hébergement et trouvez les paramètres PHP de votre site.
  2. Les versions corrigées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12 et ultérieures. Si vous avez choisi une branche plus ancienne (7.4, 8.0, 8.1), passez à une branche plus récente. Avant de changer, sauvegardez votre site et, juste après, parcourez-le pour vérifier qu’il fonctionne.
  3. Si vous n’êtes pas sûr, posez la question à votre hébergeur. Il devrait avoir la réponse « corrigé » toute prête.

Votre propre serveur ou serveur virtuel

Ici, la mise à jour dépend de vous ou de votre administrateur :

  • Mettez à jour uniquement les paquets PHP, pas tout le système d’un coup. Si quelque chose ne va pas, vous savez tout de suite ce qui l’a provoqué.
  • Avant la mise à jour, faites une sauvegarde ou un snapshot du serveur. Si le site ne fonctionne plus après la mise à jour, vous le restaurez en une minute.
  • Après la mise à jour, redémarrez le serveur web (Apache, PHP-FPM). Tant que les anciens processus tournent, le correctif n’est pas appliqué.
  • Profitez-en pour installer aussi les autres correctifs de sécurité du système. Vous découvrirez souvent que personne n’a touché au serveur depuis des mois.
Un technicien met à jour un serveur la nuit et, le matin, vérifie le site sur une tablette avec la dirigeante de l’entreprise
Sauvegarde, mise à jour de PHP, redémarrage et vérification du site. Pour chaque serveur séparément.

Un ancien site qui ne fonctionnera pas avec le nouveau PHP

C’est le cas le plus difficile. Une application écrite il y a des années pour PHP 7 ou une version antérieure ne tourne souvent pas sur la nouvelle version, et les développeurs de PHP n’ont pas publié de correctif pour les anciennes branches. Vous avez alors trois possibilités :

  1. Adapter l’application à la nouvelle version de PHP. C’est la solution durable, mais elle prend de quelques jours à quelques semaines selon la taille de l’application.
  2. En attendant, restreindre l’accès. Si l’application n’est utilisée que par quelques agences ou salariés, configurez le serveur pour que seules leurs adresses IP y aient accès. Les autres reçoivent « accès refusé » avant que la requête n’atteigne PHP. Cela fonctionne aussi sous forme de mot de passe au niveau du serveur, saisi avant la page elle-même.
  3. Transformer un site simple en site statique. Un site vitrine dont on ne modifie que de temps en temps le texte ou le menu du restaurant n’a pas du tout besoin de PHP. Une copie statique fonctionne sans système de gestion de contenu et n’est pas concernée par cette faille.

Attention : PHP 8.2 ne recevra plus de correctifs après le 31 décembre 2026. Si vous mettez à jour maintenant au sein de la branche 8.2, prévoyez pour l’année prochaine le passage à 8.3 ou plus récent.

Comment savoir si quelqu’un est déjà entré

La faille était exploitée avant même la publication du correctif. La mise à jour ferme la porte, mais ne met pas dehors celui qui est déjà à l’intérieur. Après la mise à jour, vérifiez donc :

  • les processus inconnus lancés sous l’utilisateur du serveur web, typiquement des programmes qui sollicitent le processeur (minage de cryptomonnaies),
  • les fichiers .php nouveaux ou modifiés dans les dossiers du site, surtout dans les répertoires où sont téléversées les images,
  • une charge inhabituellement élevée du serveur ou un trafic sortant sans raison apparente,
  • de nouveaux utilisateurs dans l’administration du site.

Si vous trouvez l’un de ces signes, il ne suffit pas de supprimer le fichier. Il faut examiner tout le serveur, changer tous les mots de passe (base de données, FTP, administration) et, dans le pire des cas, le restaurer à partir d’une sauvegarde antérieure à l’attaque.

Comment nous l’avons traité chez nous

Le NÚKIB a envoyé l’avertissement le soir du 21 octobre et, le soir même, nous avons passé en revue tous les sites et serveurs que nous gérons :

  • La plupart de nos sites n’utilisent pas du tout PHP, la faille ne les concernait donc pas.
  • Les serveurs web avec PHP, nous les avons mis à jour la nuit même, l’un après l’autre et toujours avec une sauvegarde préalable. Nous y avons installé dans la foulée les autres correctifs de sécurité en attente. Les systèmes internes, comme la messagerie, suivent dans des fenêtres de maintenance séparées.
  • Une application plus ancienne, qui ne fonctionnera pas avec le nouveau PHP, a été restreinte aux seules adresses IP des agences qui l’utilisent, en attendant sa migration.
  • Un site vitrine simple sur un système de gestion de contenu est en cours de conversion en site statique, pour que PHP et ses mises à jour ne soient plus nécessaires.

Pendant la mise à jour, les sites en production n’ont été indisponibles que quelques secondes, le temps du redémarrage du serveur web. Une chose nous a toutefois surpris : sur le serveur de test, la base de données n’a pas démarré après les correctifs de sécurité, à cause d’un changement dans la nouvelle version. C’est pourquoi nous mettons toujours à jour d’abord l’environnement de test, et seulement ensuite la production.

En résumé

  • Votre site fonctionne sur WordPress, Joomla ou une application PHP sur mesure ? Vérifiez la version de PHP dès aujourd’hui et mettez à jour vers 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récent.
  • Sur un hébergement mutualisé, il suffit de vérifier les paramètres. Sur votre propre serveur : sauvegardez, mettez à jour, redémarrez et vérifiez le site.
  • Une ancienne application qu’on ne peut pas mettre à jour, cachez-la derrière une restriction par adresse IP jusqu’à sa migration.
  • Si vous êtes une organisation réglementée au sens de la loi tchèque sur la cybersécurité, une telle intervention doit aussi figurer dans votre registre. Plus d’informations dans l’article NIS2 vous concerne-t-elle ?

Vous ne savez pas sur quoi fonctionne votre site, ou personne ne peut faire la mise à jour ? Nous le vérifions pour vous et, en un jour, nous vous disons si la faille vous concerne et quoi faire. Commandez une vérification gratuite.