Vendredi soir, la plupart des gens rangent leur bureau. Nous, on a passé la soirée et une partie de la nuit à mettre à jour l’intégralité des sites de nos clients. Trois nuits plus tard, on remettait ça sur la couche serveur, cette fois vers trois heures du matin.

Deux failles critiques en quatre jours. Aucun de nos clients n’a eu à lever le petit doigt. La plupart l’ont appris en lisant notre rapport d’intervention le lundi matin.

Ce qui s’est passé vendredi

Une faille a été rendue publique dans le cœur de WordPress. Pas dans un plugin obscur téléchargé il y a six ans : dans WordPress lui-même, sur une installation par défaut.

Baptisée wp2shell, elle permet à un inconnu, sans compte et sans mot de passe, d’exécuter du code sur votre serveur en envoyant quelques requêtes. À partir de là, il lit votre base de données, récupère vos contacts, installe une porte dérobée et attend tranquillement.

WordPress fait tourner environ 500 millions de sites dans le monde. Ce type de faille critique dans le noyau, sans aucune condition préalable, on en voit une tous les cinq ou six ans.

WordPress a bien tenté de forcer la mise à jour automatique sur tous les sites. Le problème, et c’est le paradoxe de l’histoire, c’est que cette mise à jour forcée échoue silencieusement sur les installations professionnelles bien construites : celles qui sont versionnées, celles dont les permissions de fichiers sont verrouillées, celles dont les mises à jour automatiques ont été désactivées volontairement pour éviter qu’un correctif ne casse un site en production un dimanche.

Autrement dit : plus votre site est sérieusement fait, moins le filet de sécurité automatique vous protège. Il faut quelqu’un derrière.

Ce qui s’est passé cette nuit

Rebelote, mais un étage plus bas. Cette fois la faille touche NGINX, le serveur web qui délivre les pages de la grande majorité de nos hébergements. Score de criticité : 9,2 sur 10.

Dans le meilleur des cas, le site tombe. Dans le pire, un attaquant prend la main sur le serveur. Et les versions concernées remontent à 2011, ce qui veut dire qu’à peu près tout le monde était exposé.

Le chercheur qui l’a découverte publiera son code d’attaque dans trois semaines. C’est la course qui commence : entre le moment où un correctif sort et le moment où les attaques automatisées démarrent, on compte aujourd’hui quelques jours. Parfois quelques heures.

Nos serveurs sont passés en version corrigée cette nuit. Pas au prochain créneau de maintenance. Cette nuit.

C’est un service que nous proposons à tous nos clients.

Pourquoi ça ne va pas s’arranger

Trois failles critiques du même type ont été trouvées dans NGINX en deux mois. Une faille majeure dans le noyau WordPress, ce qui n’était plus arrivé depuis des années. Ce rythme n’est pas une coïncidence.

L’intelligence artificielle est devenue redoutable à un exercice précis : lire des millions de lignes de code et y repérer ce qui cloche. Un audit qui prenait trois semaines à un expert se fait aujourd’hui en une nuit. C’est une excellente nouvelle pour les chercheurs en sécurité. C’est exactement la même excellente nouvelle pour les attaquants, qui utilisent les mêmes outils.

Deux conséquences, très concrètes, pour les mois qui viennent. Le nombre de failles critiques va augmenter, y compris sur des logiciels qu’on croyait solides depuis quinze ans. Et le délai avant exploitation de masse va continuer à se réduire.

Une maintenance mensuelle n’a plus de sens dans ce contexte. Hebdomadaire non plus. Ce qui protège un site aujourd’hui, c’est une équipe qui surveille les publications de sécurité en continu, qui sait en trente secondes quels serveurs sont concernés, et qui a le droit et les compétences pour intervenir sur une production à trois heures du matin.

Ce que vous risquez vraiment

L’argument revient souvent : « mon site est une vitrine, il n’y a rien à voler ». C’est une erreur d’appréciation.

Un site compromis ne sert presque jamais à attaquer votre entreprise directement. Il sert à héberger des pages d’arnaque sous votre nom de domaine, à envoyer du spam depuis votre adresse, à rediriger vos visiteurs vers autre chose. Résultat : votre domaine est signalé comme dangereux par Google, vos mails commerciaux arrivent en spam chez vos propres clients, et il faut ensuite des semaines pour redresser la situation.

Et il y a la fuite de données. Votre base contient vos abonnés, vos formulaires de contact, parfois des CV ou des devis. Avec le RGPD, vous avez 72 heures pour notifier l’Autorité de protection des données. Mais ce n’est pas l’amende qui fait le plus mal. C’est le mail que vous devez écrire à vos clients pour leur annoncer que leurs coordonnées sont dans la nature.

Une réputation se construit en vingt ans et se casse en un week-end.

C’est ça, le vrai métier d’un hébergeur

On ne vend pas de l’espace disque. N’importe qui en vend à quatre euros par mois, et à ce prix-là, personne ne se lève la nuit pour vous.

Ce que nous vendons, c’est une équipe qui lit les alertes de sécurité le vendredi soir. Qui connaît l’inventaire exact de ce qui tourne sur chaque serveur, sans devoir aller vérifier. Qui teste un correctif avant de le pousser en production, parce qu’un patch appliqué à l’aveugle peut casser un site aussi sûrement qu’une attaque. Et qui accepte de perdre une nuit quand la situation l’exige.

Vingt-cinq ans à héberger des sites de presse et de médias nous ont appris une chose simple : la sécurité n’est pas un produit qu’on achète une fois. C’est du temps humain, payé en continu, par des gens qui savent ce qu’ils regardent. À mesure que l’IA accélère la découverte de failles, ce temps humain devient la partie la plus déterminante d’un hébergement. Et la seule qu’on ne peut pas automatiser.

Si vous ne savez pas qui a mis à jour vos sites ce week-end, il y a de fortes chances que personne ne l’ait fait.

On regarde ça avec vous

Nous proposons un audit gratuit de votre installation actuelle : versions réellement en place, niveau d’exposition, traces éventuelles de compromission, et ce qu’il faudrait faire en priorité. Sans engagement, et même si vous restez chez votre prestataire actuel.

Écrivez-nous à [email protected] ou appelez le +32 475 29 31 46.

Questions fréquentes

Comment savoir si mon site est concerné ? Vérifiez votre version de WordPress dans Tableau de bord, Mises à jour. Si elle est inférieure à 7.0.2 ou 6.9.5, vous êtes exposé. Ne partez pas du principe que la mise à jour automatique est passée : elle échoue en silence dans de nombreux cas.

J’ai un pare-feu, ça suffit ? Non. Un pare-feu réduit le risque le temps que vous corrigiez, il ne répare pas le code vulnérable. C’est un pansement de quelques heures, pas une solution.

Mon site tournait en version vulnérable tout le week-end. Que faire ? Mettre à jour, puis vérifier. Un site déjà compromis reste compromis après le correctif : il faut contrôler les comptes administrateurs, les fichiers du cœur de WordPress et les tâches planifiées. Cette vérification n’est pas optionnelle.

Je ne suis pas client ArtWhere, vous pouvez quand même m’aider ? Oui. On commence toujours par un audit de l’existant, et on vous dit franchement si une reprise se justifie ou non.