La faille PHP du 21 octobre : ce que nous avons fait et pourquoi

Ce qui se passait

Mercredi matin, le projet PHP a annoncé deux vulnérabilités critiques, vite surnommées “PHP2Shell”, toutes deux notées 9,2 sur 10. Ces failles permettaient à quelqu'un de l'extérieur d'exécuter son propre code sur un serveur où tourne PHP, sans se connecter. On accède ainsi aux comptes, aux mots de passe et aux parties protégées d'un site web, et dans le pire des cas au serveur lui-même.

Ce qui rendait la situation particulièrement tendue : les informations sur les failles avaient déjà fuité la veille et circulaient sur les réseaux sociaux. Le correctif était prévu pour plus tard dans la semaine et a été avancé au mercredi 16.00. Jusque-là, tout serveur avec PHP accessible depuis Internet était probablement vulnérable, et les personnes malveillantes le savaient aussi.

De nombreuses grandes organisations ont donc fait le même choix que nous et ont mis leurs sites web hors ligne par précaution, dont la Seconde Chambre, le NCSC, DigiD et MijnOverheid. Le liveblog de NU.nl donne une bonne idée de cet après-midi-là.

Ce que nous avons fait

Nous n'avons pas attendu que quelque chose tourne mal. Voici comment la journée s'est déroulée sur nos serveurs :

• 13.30PHP désactivé sur tous nos serveurs. Les sites web qui tournent sur PHP affichaient une courte explication aux visiteurs.
• Entre-tempsLes e-mails sur votre domaine ont été envoyés et reçus normalement. Votre site web et vos données sont restés intacts : rien n'a été supprimé ni modifié.
• 16.00Les versions de PHP mises à jour tournaient et les sites web étaient de nouveau accessibles.
• EnsuiteVérification des serveurs à la recherche de traces d'abus. Aucun signe d'intrusion n'a été trouvé dans nos journaux.

Si les versions mises à jour tournaient déjà à 16.00, c'est parce que nous avons surveillé la mise à jour en continu dès l'après-midi et l'avons installée immédiatement à sa sortie.

Nos excuses pour la gêne occasionnée

Un site web inaccessible pendant deux heures et demie, c'est désagréable, surtout si vos clients vous cherchaient justement cet après-midi-là. Certains d'entre vous ont vu leur site hors ligne avant de recevoir notre message. Vu la gravité de la faille, nous avons choisi de sécuriser d'abord les serveurs et de n'envoyer l'e-mail qu'ensuite. Toutes nos excuses pour la gêne occasionnée.

En même temps, cette démarche correspond à la façon dont nous gérons votre hébergement : nous surveillons nous-mêmes activement les serveurs, et quand c'est nécessaire, nous intervenons rapidement. Mieux vaut une page d'explication pendant un après-midi qu'un site dont on découvre plus tard qu'il est passé sous le contrôle d'un tiers.

Pourquoi cela va se produire plus souvent

Le code vulnérable se trouvait dans PHP depuis plus de dix ans et a cette fois été découvert à l'aide de l'IA. Cet outil est aussi à la disposition des personnes malveillantes. Nous nous attendons donc à ce que les failles se succèdent à un rythme de plus en plus rapide. Les sites web avec un CMS comme WordPress ou Joomla demandent une attention particulière : ils reposent à la fois sur PHP et sur des plug-ins et extensions de dizaines d'éditeurs différents, et chacun de ces éléments peut contenir la prochaine faille.

C'est pourquoi nous convertissons de plus en plus souvent des sites web existants en sites web statiques, sans PHP, WordPress ni Joomla. Cela élimine de nombreuses vulnérabilités possibles, et lors d'une prochaine faille PHP, un tel site reste tout simplement en ligne. Seul un formulaire de contact utilise alors encore un petit script PHP, sauf si une autre solution est disponible. Vous découvrirez comment cela fonctionne sur la page faire créer un site web sans PHP.

Vous voulez savoir si c'est une solution adaptée à votre site web, ou vous avez des questions sur mercredi ? Écrivez à info@innodigi.nl ou contactez-nous.