Tenable Nessus : des failles SQLi à corriger sans attendre

L’avis du CERT-FR publié le 26 juin 2026 signale de multiples vulnérabilités dans Tenable Nessus, dont des failles d’injection SQL affectant la plateforme de gestion de vulnérabilités. Le sujet mérite une attention immédiate pour une raison simple : lorsqu’un outil de sécurité devient lui-même une surface d’attaque, le risque ne se limite pas à une indisponibilité locale. Il touche aussi l’intégrité des résultats de scan, la confidentialité des données collectées par l’outil, et potentiellement la confiance accordée aux décisions de remédiation prises à partir de ses rapports.

Le paradoxe est bien connu des équipes sécurité et exploitation : un scanner de vulnérabilités concentre souvent des informations très sensibles. Inventaire d’actifs, résultats de détection, identifiants techniques selon les usages, topologie réseau implicite, historiques de scans, parfois tickets ou exports transmis à d’autres outils : une compromission d’une console Nessus peut donc offrir à un attaquant une vue privilégiée sur le système d’information. Dans le cas présent, le CERT-FR mentionne des vulnérabilités de type injection SQL dans Tenable Nessus. L’impact théorique et opérationnel inclut la compromission de données, l’altération des résultats et un possible pivot sur l’outil de sécurité.

À ce stade, le point central pour les administrateurs, équipes DevOps, exploitants de plateformes de scan et RSSI est de vérifier l’exposition de la console Nessus, d’identifier précisément la version déployée, puis d’appliquer la version corrigée publiée par l’éditeur selon les indications officielles de Tenable. Le CERT-FR constitue ici la source d’alerte de référence côté francophone, et l’advisory éditeur reste la source à suivre pour les numéros de version exacts, les modalités de mise à jour et les éventuelles notes complémentaires sur les conditions d’exploitation.

Le CERT-FR ne doit pas être lu comme une simple alerte de routine. Pour un RSSI, la question n’est pas seulement “le serveur Nessus est-il vulnérable ?”, mais aussi “pouvons-nous encore nous fier aux données qu’il produit si nous tardons à corriger ?”. Pour un administrateur, la priorité pratique est double : réduire l’exposition réseau de la console et mettre à jour rapidement. Pour un responsable d’exploitation chez un hébergeur ou dans un environnement mutualisé, notamment chez des acteurs comme OVH, Scaleway ou o2switch lorsque des consoles d’administration sont exposées sur des réseaux d’administration partagés ou insuffisamment segmentés, il faut également vérifier que l’interface n’est pas accessible au-delà du périmètre strictement nécessaire.

Le score CVSS, les CVE exactes et la liste détaillée des versions touchées doivent être repris depuis l’avis officiel de l’éditeur et du CERT-FR. Lorsque ces éléments sont publiés, ils doivent guider la priorisation de patching au même titre que l’exposition réelle de l’instance. En l’absence de précision supplémentaire dans le bref éditorial fourni ici, il faut rester strictement aligné sur la documentation officielle : multiples vulnérabilités, dont des SQLi, affectent Tenable Nessus, et des correctifs éditeur sont disponibles.

Source de référence : l’avis CERT-FR “Multiples vulnérabilités dans Tenable Nessus” daté du 26 juin 2026, ainsi que l’advisory officiel Tenable associé cité par le CERT-FR.

Versions affectées

Le CERT-FR indique que des produits Tenable Nessus sont affectés par de multiples vulnérabilités. La liste précise des versions vulnérables et la ou les versions corrigées doivent être vérifiées dans l’advisory officiel de Tenable référencé par le CERT-FR, car c’est la source normative pour les périmètres exacts.

• Produit concerné : Tenable Nessus
• Nature des failles signalées : multiples vulnérabilités, dont injections SQL
• Source francophone : CERT-FR, avis du 26 juin 2026
• Versions vulnérables : se reporter à la liste publiée par l’éditeur dans l’advisory associé
• Version corrigée : appliquer la version corrigée publiée par l’éditeur
• CVE : se reporter aux identifiants CVE indiqués dans l’avis officiel Tenable et repris par le CERT-FR
• CVSS : utiliser le ou les scores CVSS publiés officiellement pour prioriser la remédiation

Cette prudence n’est pas cosmétique. En sécurité applicative, une erreur sur un numéro de version ou un identifiant CVE peut conduire à un faux sentiment de sécurité, à un patching incomplet ou à des contrôles de conformité erronés. La bonne pratique consiste donc à :

• identifier la version exacte de Nessus installée ;
• la comparer à la matrice de versions de l’éditeur ;
• documenter le périmètre exposé : console locale, accès via reverse proxy, accès VPN, accès Internet ;
• planifier la mise à jour vers la version corrigée publiée par Tenable ;
• conserver une trace de validation après mise à jour.

Sur le terrain, plusieurs déploiements Nessus existent : instance isolée pour un usage interne, scanner rattaché à une équipe SOC, déploiement dans une DMZ d’administration, ou encore usage ponctuel sur des environnements de recette et de préproduction. Dans tous les cas, la version doit être contrôlée sur chaque nœud concerné, et pas uniquement sur la console la plus visible.

Pour les organisations qui gèrent plusieurs scanners ou plusieurs environnements, il est utile de produire un tableau d’inventaire simple :

• nom d’instance ;
• version logicielle ;
• OS hôte ;
• mode d’exposition réseau ;
• propriétaire technique ;
• date de dernière mise à jour ;
• présence d’un reverse proxy ou d’un filtrage d’accès ;
• présence éventuelle d’authentification fédérée ou locale.

Ce travail est particulièrement important si l’outil est hébergé sur une infrastructure virtualisée ou chez un prestataire. Dans un contexte d’hébergement externalisé, l’équipe cliente reste en général responsable de l’application des correctifs applicatifs sur son instance Nessus, même si l’infrastructure sous-jacente est administrée par un tiers.

Vecteur d’attaque

Le vecteur mis en avant par le CERT-FR est une injection SQL sur la plateforme de gestion de vulnérabilités. Sans reprendre de détail non confirmé par l’advisory éditeur, on peut rappeler le fonctionnement général d’une telle classe de faille pour mesurer les risques concrets.

Une injection SQL apparaît lorsqu’une application construit une requête vers une base de données à partir d’une entrée utilisateur insuffisamment contrôlée ou non paramétrée. Si une donnée issue d’une requête HTTP, d’un paramètre d’API, d’un formulaire, d’un en-tête ou d’un mécanisme de recherche est concaténée directement dans une requête SQL, un attaquant peut tenter d’en modifier la logique. Selon le contexte, cela peut permettre :

• de lire des données non prévues ;
• de modifier ou supprimer des enregistrements ;
• de contourner certains contrôles applicatifs ;
• de provoquer des erreurs révélant la structure interne de l’application ;
• dans certains cas, d’obtenir une exécution plus large selon les privilèges du moteur de base de données ou de l’application.

Dans le cas d’un outil comme Nessus, l’impact dépasse la simple fuite de données. La base applicative peut contenir des éléments déterminants pour l’exploitation de la plateforme :

• résultats de scans et historiques ;
• définitions de politiques de scan ;
• configuration des cibles ;
• métadonnées d’inventaire ;
• journaux applicatifs ;
• comptes locaux ou paramètres liés à l’authentification selon la configuration ;
• informations permettant de cartographier plus finement le réseau interne.

Le risque d’altération de l’intégrité est ici central. Si un attaquant parvient à manipuler des résultats, à supprimer des entrées, à modifier des configurations ou à fausser des politiques de scan, l’organisation peut prendre des décisions de sécurité sur une base erronée. Cela peut se traduire par :

• des vulnérabilités réelles masquées dans les rapports ;
• des faux positifs injectés pour détourner l’attention des équipes ;
• des cibles de scan modifiées ou supprimées ;
• des fréquences de scan altérées ;
• des exports ou tableaux de bord devenus non fiables.

Pour un RSSI, c’est l’un des aspects les plus sensibles de cette alerte. Un outil de sécurité compromis peut devenir un point d’aveuglement. L’organisation croit observer correctement son exposition alors que la source de vérité est dégradée. Ce risque est souvent sous-estimé par rapport à la seule notion de fuite de données.

Scénarios d’attaque concrets

Sans produire de preuve de concept ni spéculer sur le point d’entrée exact non documenté ici, plusieurs scénarios réalistes découlent d’une SQLi sur une console d’administration de ce type.

• Scénario 1 : console exposée sur Internet ou via un filtrage insuffisant
  Un attaquant découvre une interface Nessus accessible publiquement, directement ou derrière un reverse proxy mal configuré. Il tente d’exploiter la faille d’injection SQL via un point d’entrée vulnérable. Si l’exploitation réussit, il peut extraire des données de configuration, des résultats de scan ou manipuler certaines informations stockées par l’application.
• Scénario 2 : accès depuis un réseau d’administration trop large
  La console n’est pas exposée à Internet, mais elle est accessible depuis un réseau d’administration partagé avec de nombreux postes ou bastions. Une compromission préalable d’un poste interne suffit alors à offrir un chemin vers l’interface Nessus. La faille devient un multiplicateur de risque dans une chaîne d’attaque interne.
• Scénario 3 : altération discrète des résultats
  L’objectif n’est pas de voler des données mais de dégrader la confiance dans les scans. Un attaquant modifie des résultats, supprime des traces de vulnérabilités sur certains actifs ou perturbe la planification des scans. L’effet recherché est la persistance furtive dans le SI, pas nécessairement la destruction.
• Scénario 4 : pivot depuis l’outil de sécurité
  Une fois la plateforme compromise, l’attaquant exploite la visibilité offerte par l’outil pour mieux cartographier le SI, identifier des segments réseau, des hôtes sensibles, des technologies déployées et les priorités de défense. Même sans exécution de code sur l’hôte, la valeur informationnelle de la plateforme peut suffire à préparer une phase ultérieure.

Pourquoi une SQLi sur un outil de scan est particulièrement critique

Dans beaucoup d’applications métier, une injection SQL expose d’abord des données locales à l’application. Sur un outil comme Nessus, la donnée compromise a une valeur stratégique. Elle peut révéler :

• quels serveurs sont les plus critiques ;
• quelles faiblesses sont déjà connues des défenseurs ;
• quels correctifs manquent sur quels actifs ;
• quels segments réseau sont scannés régulièrement ;
• quels systèmes semblent moins surveillés ;
• quelles fenêtres de maintenance existent implicitement.

Autrement dit, la compromission de l’outil ne fournit pas seulement un accès technique ; elle fournit un renseignement défensif sur l’organisation. Pour un attaquant, c’est un gain de temps considérable.

Ce point doit aussi être intégré dans les analyses de risque réglementaires ou contractuelles. Si les rapports de vulnérabilité contiennent des informations sur des clients, des environnements de production, des adresses internes ou des composants exposés, l’incident peut avoir des conséquences en matière de notification interne, de gestion de crise et de relation avec des tiers.

Impact

L’impact mentionné dans le brief éditorial est clair : compromission de données, altération des résultats et pivot sur l’outil de sécurité. Ces trois dimensions doivent être traitées séparément pour bien prioriser la remédiation.

Confidentialité

Une exploitation réussie peut exposer des données stockées par la plateforme. Selon la configuration et l’usage réel de l’instance, cela peut inclure des résultats de scans, des informations d’inventaire, des paramètres de politiques, des journaux ou d’autres métadonnées sensibles. La criticité dépend directement du contenu et du cloisonnement de l’instance.

Intégrité

C’est souvent le risque le plus sous-évalué. Si les résultats ou les paramètres de scan sont modifiables via exploitation, l’organisation peut perdre confiance dans l’outil lui-même. Cette perte d’intégrité a des effets en cascade :

• priorisation de patching basée sur des données altérées ;
• retard dans la correction de failles réellement présentes ;
• reporting de conformité inexact ;
• vision erronée de la surface d’attaque ;
• difficulté à distinguer une panne d’une manipulation malveillante.

Disponibilité

Même si l’alerte se concentre sur des SQLi, une exploitation peut aussi perturber le fonctionnement de la plateforme : erreurs applicatives, corruption logique de certaines données, blocage de traitements, ou dégradation des capacités de scan et de reporting. Sur une équipe qui dépend fortement de Nessus pour ses opérations courantes, l’effet opérationnel peut être notable.

Risque de pivot

Un scanner de vulnérabilités se situe souvent dans une zone d’administration privilégiée. Il échange avec de nombreux actifs et bénéficie parfois d’une visibilité réseau plus large que celle d’un poste standard. Même sans supposer d’exécution de code non documentée ici, la seule compromission logique de la plateforme peut aider à préparer un mouvement latéral, à sélectionner des cibles ou à comprendre quelles machines sont les plus rentables à attaquer.

Point de vigilance RSSI : la question n’est pas uniquement “un attaquant peut-il lire des données ?”, mais aussi “peut-il fausser nos instruments de mesure ?”. Lorsqu’un outil de sécurité perd son intégrité, l’organisation perd une partie de sa capacité de décision.

Comment patcher

La remédiation prioritaire consiste à mettre à jour Tenable Nessus vers la version corrigée publiée par l’éditeur. Le CERT-FR renvoie à l’advisory officiel Tenable, qui doit être utilisé comme source de vérité pour la version cible exacte et les éventuelles préconditions de mise à jour.

Comme les commandes varient selon le système d’exploitation et le mode de déploiement, il faut d’abord identifier :

• la distribution hôte ;
• le mode d’installation du package Nessus ;
• la présence éventuelle d’un dépôt éditeur ;
• les contraintes de redémarrage de service ;
• la fenêtre de maintenance disponible.

Vérifier la version installée

Avant toute action, relevez la version courante installée sur chaque instance concernée. Selon l’environnement, cela peut passer par l’interface d’administration ou par une commande locale. Les chemins et binaires exacts dépendent du packaging de l’éditeur.

# Exemple de vérification locale selon l'installation
/opt/nessus/sbin/nessuscli -v

Cette commande est donnée à titre d’exemple courant pour un déploiement local Nessus ; il faut la confirmer sur votre instance selon la documentation Tenable en vigueur.

Mise à jour sur systèmes de type Debian/Ubuntu

Si l’instance est installée via un package adapté à l’OS et qu’un dépôt ou un package éditeur est utilisé, la mise à jour se fait en installant la version corrigée publiée par Tenable. En pratique, l’opération peut ressembler à l’installation d’un nouveau paquet .deb fourni par l’éditeur.

# Exemple générique si vous disposez du paquet éditeur
sudo dpkg -i Nessus-<version_corrigee>-debian10_amd64.deb

Le nom exact du fichier dépend de la publication Tenable. Il faut utiliser le package correspondant à votre distribution et à l’architecture déployée.

Si votre organisation maintient un dépôt interne ou un miroir de paquets, la mise à jour peut aussi être orchestrée via vos outils habituels de gestion de configuration, après validation du paquet corrigé.

Mise à jour sur systèmes de type RHEL, Rocky Linux, AlmaLinux, CentOS

Sur les distributions RPM, le principe reste identique : installer la version corrigée fournie par l’éditeur.

# Exemple générique avec un paquet RPM téléchargé
sudo rpm -Uvh Nessus-<version_corrigee>-es8.x86_64.rpm

Là encore, la nomenclature exacte du fichier et la compatibilité OS doivent être vérifiées dans la documentation officielle Tenable.

Redémarrage et validation

Après mise à jour, vérifiez l’état du service et la bonne remontée de la version corrigée.

# Vérification de l'état du service
sudo systemctl status nessusd

# Redémarrage si nécessaire
sudo systemctl restart nessusd

Puis contrôlez à nouveau la version :

/opt/nessus/sbin/nessuscli -v

Enfin, connectez-vous à la console et validez les points suivants :

• la version affichée correspond bien à la version corrigée ;
• les politiques de scan sont présentes ;
• les scans planifiés sont intacts ;
• les historiques et tableaux de bord sont cohérents ;
• les intégrations externes éventuelles fonctionnent toujours.

Mesures de gouvernance autour du patch

Pour les équipes RSSI et exploitation, le patch ne doit pas être traité comme une simple opération système. Il faut aussi :

• documenter la date de correction ;
• conserver la preuve de version avant et après ;
• évaluer si la console a été exposée pendant la période de vulnérabilité ;
• prévoir une revue d’intégrité des résultats récents si l’exposition a été significative ;
• mettre à jour l’inventaire des outils de sécurité critiques.

Dans des environnements industrialisés, il est pertinent d’intégrer Nessus au même niveau de suivi que les autres composants d’administration sensibles : bastions, consoles de virtualisation, orchestrateurs, outils de sauvegarde et solutions de supervision.

Mitigation

Si la mise à jour immédiate n’est pas possible, il faut réduire au plus vite la surface d’attaque. Ces mesures ne remplacent pas le patch, mais elles peuvent diminuer le risque d’exploitation opportuniste.

Restreindre l’exposition réseau

La première mesure consiste à limiter l’accès à la console Nessus aux seuls réseaux et postes strictement nécessaires.

• supprimer toute exposition directe à Internet si elle existe ;
• restreindre l’accès à un VPN ou à un bastion d’administration ;
• filtrer par adresses source sur le pare-feu ;
• désactiver les publications inutiles via reverse proxy ;
• segmenter le réseau d’administration.

Exemple générique de restriction avec iptables sur le port d’administration, à adapter à votre contexte :

# Autoriser uniquement un sous-réseau d'administration
sudo iptables -A INPUT -p tcp --dport 8834 -s 10.0.10.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8834 -j DROP

Le port exact et les règles doivent être validés selon votre architecture et votre politique de sécurité.

Renforcer le contrôle d’accès

Si la console reste accessible, réduisez le nombre de comptes autorisés et vérifiez les mécanismes d’authentification :

• désactiver les comptes inutilisés ;
• forcer l’usage de comptes nominatifs ;
• restreindre l’accès via MFA si disponible dans votre contexte ;
• contrôler les comptes administrateurs locaux ;
• vérifier les sessions actives et récentes.

Réduire les chemins d’exposition applicatifs

Si un reverse proxy publie l’interface, vérifiez qu’il n’ajoute pas d’exposition inutile :

• pas d’accès depuis des réseaux non approuvés ;
• pas de publication sur des noms DNS publics non nécessaires ;
• journalisation activée côté proxy ;
• limitation de débit si cela s’intègre à votre politique ;
• surveillance des erreurs applicatives inhabituelles.

Superviser l’intégrité des résultats

Comme le risque d’altération est important, il faut surveiller les changements inhabituels dans les données de scan :

• disparition soudaine de nombreuses vulnérabilités sans campagne de patching corrélée ;
• modification inattendue des politiques de scan ;
• suppression de cibles ou de dossiers ;
• création de comptes ou changements de rôles non planifiés ;
• volumes d’export inhabituels.

Un contrôle simple mais utile consiste à comparer les derniers rapports avec les tendances historiques. Une chute brutale du nombre de vulnérabilités critiques sur un périmètre stable, sans changement d’exploitation correspondant, doit déclencher une vérification manuelle.

Détection

En l’absence d’indicateurs de compromission détaillés publiés dans le bref source fourni ici, il faut s’appuyer sur une détection comportementale et sur les journaux disponibles côté système, proxy et application. L’objectif est de repérer à la fois une tentative d’exploitation et d’éventuelles altérations postérieures.

Indicateurs de compromission à rechercher

• Accès anormaux à la console depuis des adresses IP inhabituelles, notamment hors plages d’administration autorisées ;
• pics d’erreurs HTTP ou de réponses applicatives anormales sur l’interface Nessus ;
• requêtes répétées vers les mêmes points d’entrée avec variations de paramètres ;
• changements de configuration non tracés par une demande de changement ;
• exports massifs ou consultations inhabituelles de résultats de scan ;
• modification de politiques, de cibles, de planifications ou de comptes ;
• redémarrages de service inexpliqués ou erreurs applicatives répétées ;
• écarts de volumétrie dans les résultats de scans sans cause opérationnelle connue.

Journaux et sources de preuve utiles

Selon l’architecture déployée, les éléments suivants peuvent être corrélés :

• journaux du service nessusd ;
• journaux système via journalctl ;
• logs du reverse proxy éventuel ;
• logs de pare-feu ;
• traces d’authentification ;
• historique des changements dans l’interface d’administration ;
• exports de rapports récents pour comparaison.

Exemples de commandes utiles pour une première revue locale :

# Journaux système liés au service
sudo journalctl -u nessusd --since "2026-06-26"

# État du service et derniers événements
sudo systemctl status nessusd

Sur un reverse proxy comme Nginx ou Apache, recherchez :

• des séquences de requêtes nombreuses sur un même endpoint ;
• des codes 500 ou 400 en hausse ;
• des tailles de réponse anormales ;
• des accès depuis des pays, ASN ou plages d’adresses inattendus ;
• des horaires incompatibles avec les usages d’administration habituels.

Exemples de signaux faibles réseau

Sans prétendre fournir des signatures d’exploitation universelles, certains signaux doivent attirer l’attention :

• tentatives répétées sur le port de la console d’administration ;
• accès depuis des scanners Internet connus ;
• sessions d’administration depuis des IP non répertoriées ;
• hausse brutale de trafic sortant depuis l’hôte Nessus vers des destinations inhabituelles.

Si l’instance a été exposée publiquement, même brièvement, une revue des logs sur la période précédant le patch est recommandée. Pour les organisations soumises à des exigences de traçabilité, cette revue doit être consignée et, si nécessaire, intégrée à une analyse d’incident.

Perspective écosystème et priorités de remédiation

Cette alerte rappelle un point structurel : les outils de sécurité sont des actifs critiques, pas des exceptions au cycle de durcissement. Consoles de scan, EDR, SIEM, outils de sauvegarde, orchestrateurs et bastions partagent un même problème : ils concentrent du privilège, de la visibilité et de la donnée sensible. À ce titre, ils doivent être gérés avec un niveau d’exigence au moins équivalent à celui des applications exposées les plus sensibles.

Dans l’écosystème réel, on observe encore souvent des pratiques fragiles :

• console publiée sur Internet pour des raisons de commodité ;
• accès d’administration ouvert à un sous-réseau trop large ;
• patching moins fréquent sur les outils “internes” ;
• absence de supervision spécifique des outils de sécurité eux-mêmes ;
• confiance excessive dans l’intégrité native des résultats produits.

Le cas Nessus illustre pourquoi ces habitudes doivent évoluer. Un scanner de vulnérabilités n’est pas seulement un composant technique ; c’est une source de décision. Si cette source est compromise, les conséquences dépassent l’incident local et peuvent contaminer toute la chaîne de gouvernance sécurité.

Pour les administrateurs et DevOps, l’ordre des priorités est généralement le suivant :

• identifier toutes les instances Nessus ;
• vérifier les versions ;
• réduire l’exposition réseau immédiatement ;
• appliquer la version corrigée publiée par Tenable ;
• contrôler l’intégrité des configurations et des résultats récents ;
• conserver des preuves de remédiation.

Pour les RSSI, il faut en parallèle :

• évaluer si l’instance était exposée à Internet ou à un périmètre d’administration trop large ;
• déterminer si une revue de compromission est nécessaire ;
• réexaminer la politique d’exposition des consoles d’outillage sécurité ;
• intégrer ces outils dans les exercices de gestion de crise et de continuité.

La source à suivre reste l’avis CERT-FR du 26 juin 2026 et surtout l’advisory officiel Tenable qu’il référence, pour les identifiants CVE, les éventuels scores CVSS, la liste précise des versions affectées et la version corrigée à déployer. Si votre organisation s’appuie sur des relais de sécurité nationaux ou sectoriels, surveillez également les mises à jour et enrichissements éventuels de l’avis.

En pratique, une console Nessus ne devrait jamais être considérée comme un simple serveur parmi d’autres. Si elle est accessible, elle doit être segmentée, journalisée, mise à jour rapidement et surveillée pour son intégrité. C’est particulièrement vrai dans les environnements hybrides, chez les hébergeurs et dans les infrastructures où plusieurs équipes accèdent aux mêmes réseaux d’administration. Pour renforcer durablement ce type d’actif, un passage en revue des mesures de durcissement et d’exploitation sécurisée reste recommandé, notamment via les bonnes pratiques rassemblées sur /categorie/pratiques.