Correctif publié en juillet, serveurs piratés en août : la leçon de la faille Zimbra

Fin août, la fondation Shadowserver a publié un décompte qui devrait faire réfléchir bien au-delà des grandes entreprises. Le 20 août, elle recensait 155 serveurs de messagerie Zimbra compromis dans le monde. Deux jours plus tard, ils étaient 274. Zimbra est une suite collaborative — courrier électronique, agenda, contacts — utilisée par des administrations, des écoles et un certain nombre de PME qui préfèrent héberger leur messagerie elles-mêmes plutôt que de la confier à un géant du cloud.

La faille exploitée, référencée CVE-2026-73570, permet à un attaquant d'exécuter ses propres commandes directement sur le serveur, c'est-à-dire d'en prendre le contrôle. Mais le plus instructif dans cette affaire n'est pas la faille elle-même : c'est le calendrier.

Un mois entre le correctif et l'attaque en série

L'éditeur avait proposé une solution de contournement dès le 26 juin, puis un correctif définitif le 20 juillet avec la version 10.1.20 de sa suite. Le 17 août, le CERT polonais signalait une exploitation active. Le 19 août, le CERT-FR publiait à son tour un avis à destination des administrateurs francophones, et le 21 août l'agence américaine CISA inscrivait la faille à son catalogue des vulnérabilités activement exploitées, en laissant trois jours aux administrations fédérales pour réagir.

Un mois s'est donc écoulé entre la mise à disposition du correctif et le début des compromissions massives. Un mois, sur le papier, cela semble confortable. Dans les faits, c'est le temps qu'il a fallu aux attaquants pour disséquer le correctif, comprendre ce qu'il réparait et automatiser l'attaque. Et d'après Shadowserver toujours, environ 8 000 serveurs Zimbra restaient encore exposés sans correctif à la fin du mois d'août.

Le conseil pratique : faites l'inventaire de ce qui est exposé

Un détail technique de cette affaire porte un enseignement qui dépasse largement Zimbra. Pour être vulnérable, un serveur devait disposer d'un composant optionnel, le paquet de supervision zimbra-snmp, avec les notifications activées. Ce n'est pas la configuration par défaut. Les victimes sont donc des serveurs sur lesquels quelqu'un avait, un jour, activé une fonction de surveillance — sans doute utile à l'époque, sans doute oubliée depuis.

C'est précisément le premier conseil que nous donnons à nos clients : tout ce qui est installé mais plus utilisé devient une porte que personne ne surveille. Prenez une heure, cette semaine, pour dresser la liste de ce qui, chez vous, est réellement accessible depuis Internet. Un serveur de messagerie, un NAS où dorment les sauvegardes, un accès à distance ouvert pendant le confinement, une caméra de surveillance, l'interface d'administration du routeur, un site vitrine sous WordPress. Pour chaque élément, deux questions suffisent. Quelqu'un vérifie-t-il que les mises à jour s'installent vraiment ? Et cette fonction sert-elle encore à quelque chose aujourd'hui ? Ce qui ne sert plus se désactive : c'est la mesure de sécurité la moins coûteuse qui existe.

Le contexte réglementaire pousse dans la même direction. Le 24 août, le Centre pour la Cybersécurité Belgique a adressé une nouvelle communication aux entités essentielles au sens de la directive NIS2. Même si votre entreprise n'entre pas directement dans ce périmètre, les effets vous concernent : les donneurs d'ordre soumis à NIS2 doivent évaluer la sécurité de leurs fournisseurs et sous-traitants. Beaucoup de PME de la région découvriront cette exigence en recevant un questionnaire de leur plus gros client.

À Bastogne comme à Wiltz, nous constatons rarement des attaques d'une grande sophistication. Nous voyons surtout des machines et des services laissés sans surveillance parce que personne n'avait le temps de s'en occuper. Si vous ne pouvez pas dire, aujourd'hui, quand votre serveur ou votre pare-feu a reçu sa dernière mise à jour, vous avez déjà la réponse — et c'est le bon moment pour en parler avec nous.