<p>Le CERT-FR a publié le 4 août 2026 un avis sur plusieurs vulnérabilités de LibreNMS, un outil de supervision réseau que beaucoup de PME utilisent...
Dans beaucoup de petites structures, un serveur discret tourne en permanence dans un coin du réseau pour surveiller l'état des équipements et prévenir quand quelque chose tombe. Il n'appartient à personne en particulier, il n'a pas d'utilisateur attitré, et il finit par échapper aux inventaires. C'est exactement le profil de machine qui pose problème quand une vulnérabilité est publiée.
LibreNMS entre dans cette catégorie. Cet outil libre de supervision réseau est fréquemment déployé par un prestataire informatique, parfois plusieurs années avant qu'on s'y intéresse à nouveau. Le 4 août 2026, le CERT-FR a signalé plusieurs failles le concernant. Selon l'avis CERTFR-2026-AVI-0966 du CERT-FR, publié le 4 août 2026, toutes les versions de LibreNMS antérieures à la 26.5.0 sont vulnérables. Les défauts identifiés permettraient, d'après cet avis, l'exécution de code arbitraire à distance, une falsification de requêtes côté serveur (SSRF) et une injection de code indirecte de type XSS. La référence CVE-2026-45694 est associée à cet ensemble.
L'avis s'appuie sur sept bulletins de sécurité publiés le même jour par le projet LibreNMS lui-même, ce qui constitue une confirmation par une deuxième source indépendante de l'agence française. À la date de rédaction de cet article, aucune exploitation en conditions réelles n'est mentionnée, ni par le CERT-FR ni par l'éditeur. Ce statut peut changer: il est à revérifier sur la page de l'avis, qui reste la référence tenue à jour. Un outil de supervision occupe une place particulière dans un réseau. Pour interroger l'état des machines, il doit connaître leurs identifiants — comptes SNMP, parfois accès SSH — et savoir dialoguer avec presque tout: commutateurs, points d'accès Wi-Fi, pare-feux, serveurs, onduleurs. Sa fonction même exige cette position centrale.
La conséquence est mécanique. Qui contrôle le serveur de supervision obtient d'un seul coup deux choses: une cartographie détaillée de l'infrastructure, indiquant quels équipements existent et comment ils sont reliés, et un ensemble d'accès techniques permettant de rebondir vers ces équipements. Cette machine réputée secondaire vaut donc, du point de vue d'un attaquant, bien davantage qu'un poste de travail ordinaire.
Le risque augmente sensiblement si l'interface web de l'outil est joignable depuis l'extérieur. C'est un choix courant, motivé par le confort: le prestataire consulte les alertes à distance, sans passer par un tunnel VPN. Cette commodité transforme une faille interne en surface d'attaque publique.
Ce qu'il faut faire
Commencer par savoir si l'outil est chez vous. LibreNMS est typiquement installé par l'infogéreur, sans que l'entreprise en garde la trace. La question à lui poser est simple: utilisons-nous LibreNMS, et sur quelle machine?
Relever la version installée. Elle apparaît dans le menu Overview puis About de l'interface. En ligne de commande, git describe --tags dans le répertoire d'installation renvoie la même information. Ces chemins sont donnés à titre indicatif et méritent d'être confirmés sur votre propre installation.
Passer en 26.5.0 ou plus récent. La procédure officielle du projet s'appuie sur le script ./daily.sh pour une installation standard. Sauvegardez la base de données et le répertoire de configuration avant l'opération, et validez la mise à jour hors production si vous disposez d'un environnement de test.
Vérifier tout de suite l'exposition de l'interface. Si elle répond depuis Internet, restreignez-la au réseau interne ou à un accès VPN. C'est la mesure au meilleur rapport effort/bénéfice, et elle protège aussi contre les failles qui n'ont pas encore été publiées.
Passer les journaux d'accès en revue. Cherchez les connexions inhabituelles, notamment depuis des adresses IP sans lien avec votre activité ou en dehors des horaires de travail habituels. Ce contrôle est utile même sans exploitation connue.
Faire trancher la priorité par votre prestataire. Si l'outil est administré par un tiers, la mise à jour et le cloisonnement relèvent de son périmètre. Demandez un retour écrit indiquant la version en place et la date d'application du correctif. Un outil de supervision est un point de passage privilégié vers l'ensemble du réseau, et non un utilitaire accessoire. Deux réflexes suffisent ici: appliquer la version 26.5.0, et s'assurer que son interface n'est pas ouverte sur Internet. En cas de doute sur l'ampleur de l'exposition ou sur la conduite à tenir, appuyez-vous sur l'avis du CERT-FR et sur votre prestataire informatique plutôt que sur une intervention improvisée en production.
- CERT-FR, « Multiples vulnérabilités dans LibreNMS », avis CERTFR-2026-AVI-0966, 4 août 2026 — cert.ssi.gouv.fr
- Projet LibreNMS, bulletins de sécurité (GHSA-7cj5-v4pp-v632, GHSA-7gww-x7fh-jf9j, GHSA-7hmq-j399-mqwf, GHSA-g993-wffj-m3gv, GHSA-jf24-8g2h-2wg7, GHSA-jmqm-f8q4-v7wx, GHSA-v5jp-f342-234h), 4 août 2026 — github.com/librenms/librenms
Synthèse rédactionnelle originale de TICLIC, établie à partir de la veille du 5 août 2026. Les éléments techniques (numéros de version, chemins de menu, commandes) proviennent de l'avis du CERT-FR et de la documentation du projet et n'ont pas été retestés sur une installation par nos soins; l'absence d'exploitation en conditions réelles reflète l'état des publications à cette date et n'a pas fait l'objet d'une vérification indépendante ultérieure. À valider sur votre infrastructure avant toute application en production.