Hier, nous écrivions que les sites que nous hébergeons sont restés en ligne alors que DigiD, MijnOverheid et la Chambre des représentants néerlandaise passaient hors ligne. Aujourd’hui, on en sait plus sur les deux failles PHP : si elles sont exploitées, ce qu’elles font exactement et pour qui il n’y aura pas de solution. Voici l’état des lieux, en langage clair.

Dernière mise à jour : vendredi 23 octobre 2026, 00h30. Nous mettons cet article à jour tant que l’actualité évolue.

La faille a désormais un nom : PHP2Shell

Les deux vulnérabilités (CVE-2026-109618 et CVE-2026-109619) sont connues ensemble sous le nom de PHP2Shell. Elles se trouvent dans PHP lui-même, pas dans WordPress ni dans une extension, et concernent en principe tout site qui tourne sur PHP. La divulgation était prévue le 22 octobre, mais les détails ont fuité le 20 octobre sur les réseaux sociaux. L’équipe PHP a donc publié le correctif un jour plus tôt que prévu et de nombreuses organisations ont mis leurs sites hors ligne par précaution.

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Si votre site tourne sur l’une de ces versions, cette faille est colmatée pour vous.

La faille est-elle exploitée ?

Les avis ont évolué aujourd’hui, dans deux directions :

  • Le NCSC (Centre national néerlandais de cybersécurité) indiquait le 21 octobre n’avoir encore aucun indice d’exploitation. Le 22 octobre, il a fait savoir qu’il enquêtait sur les premiers signes d’exploitation réussie.
  • Des chercheurs en sécurité ont vu arriver des tentatives d’attaque via des serveurs leurres. En même temps, Sansec (Utrecht) estime qu’une exploitation massive est moins probable que redouté le premier jour : le code d’attaque partagé publiquement ne fonctionne pas contre une installation PHP standard, et une attaque exige une connaissance précise du serveur visé.
  • Le gouvernement américain (CISA) insiste sur une mise à jour immédiate, mais n’a pas (encore) inscrit les failles sur sa liste de vulnérabilités activement exploitées.

Notre lecture : un serveur corrigé est sûr, et un serveur non corrigé n’est pas un « petit risque » mais une porte ouverte à laquelle on frappe déjà. Attendre n’est plus une option.

Pas seulement de l’exécution de code : aussi une fuite de mémoire

Un détail encore peu évoqué hier : l’une des deux failles peut aussi faire fuiter la mémoire du serveur. Via un cookie de session, un attaquant peut récupérer des fragments de mémoire du serveur web, qui peuvent contenir des mots de passe, des jetons de session ou des clés API d’autres visiteurs. Cela fonctionne même sur des sites qui n’utilisent aucune session.

Concrètement : si votre site se trouvait entre le 20 et le 22 octobre sur un serveur non corrigé, envisagez de renouveler les mots de passe et clés API utilisés sur ce serveur. Non parce qu’il s’est certainement passé quelque chose, mais parce que vous ne pouvez pas l’exclure.

Pas de correctif pour PHP 8.1 et antérieur

C’est peut-être le point le plus important pour beaucoup d’entrepreneurs. PHP 8.1, 8.0 et toutes les versions 7.x ne sont plus prises en charge et ne reçoivent aucune mise à jour de sécurité. Un site sur une telle version reste vulnérable tant que le serveur n’est pas passé à PHP 8.2 ou plus récent. Ce n’est pas un simple bouton à activer : d’anciennes extensions et d’anciens thèmes ne fonctionnent parfois pas sur une nouvelle version de PHP, il faut donc tester.

Pour le vérifier vous-même dans WordPress : allez dans Outils → Santé du site → Informations → Serveur. La version de PHP y figure. Commence-t-elle par 8.2, 8.3, 8.4 ou 8.5 et le numéro de version est-il égal ou supérieur à ceux mentionnés ci-dessus ? Alors vous êtes corrigé. Si vous voyez 8.1 ou moins, contactez votre hébergeur dès aujourd’hui.

Ce que nous avons fait et continuons de faire

  • Tous les serveurs sur lesquels nous hébergeons ont été mis à jour vers une version PHP corrigée le 21 octobre, le jour même de la publication.
  • Verploy, notre plateforme de maintenance, a vérifié après la mise à jour que chaque site client fonctionnait encore correctement. C’était le cas partout : aucun site n’a été hors ligne.
  • Nous n’avons constaté aucune exploitation dans nos journaux, et nous continuons les prochains jours à surveiller de très près tout trafic anormal.
  • Aucun de nos sites clients ne tourne sur PHP 8.1 ou antérieur. Ce n’est pas un hasard : les mises à niveau PHP en temps utile font partie de notre maintenance.

Trois choses à faire aujourd’hui

  1. Vérifiez votre version de PHP (voir ci-dessus) ou demandez à votre hébergeur. Un bon hébergeur peut vous dire immédiatement quand le correctif a été appliqué.
  2. Renouvelez mots de passe et clés API si votre site a été sur un serveur non corrigé.
  3. Faites en sorte que ce soit la dernière fois que vous devez le vérifier vous-même. Un site web doit être surveillé, pas regardé une fois par an.

Vous ne savez pas où en est votre site ?

Laissez ci-dessous l’adresse de votre site. Vous recevrez par e-mail un rapport court et personnalisé : votre site tourne-t-il sur une version PHP sûre, qu’en est-il de la vitesse et de la visibilité, et quelles sont les trois améliorations à plus fort impact. Gratuit et sans engagement.

Réserver un entretien-conseil gratuit   

Vous préférez appeler ? +31 (0)166 700204, lun–ven 9h00–17h30.

Sources : Sansec, analyse PHP2Shell (mise à jour du 22 octobre) · watchTowr, FAQ PHP2Shell · Help Net Security · Scientias · avis de sécurité php.net du 21 octobre 2026.