N-able corrige une RCE critique pré-authentification dans N-central, tandis que les signalements d’exploitation se contredisent

N-able a publié une mise à jour d’urgence pour N-central, sa plateforme de supervision et de gestion à distance installée sur site, afin de corriger une vulnérabilité critique permettant l’exécution de code à distance sans authentification.

Référencée sous CVE-2026-86218, cette faille concerne toutes les versions de N-central antérieures à 2026.3.1.14. Cela inclut 2026.3.1.13, distribuée sous la forme de Hotfix 3 peu avant la divulgation de la nouvelle vulnérabilité.

La version corrigée, N-central 2026.3.1.14, est disponible sous la forme de 2026.3 Hotfix 4. N-able a publié et mis à jour la fiche CVE le 6 septembre 2026 et exhorte tous ses clients utilisant la version installée sur site à effectuer immédiatement la mise à niveau.

La question de savoir si des attaquants exploitent déjà la vulnérabilité reste floue. N-able a publié des déclarations contradictoires : certains avis de l’entreprise indiquent qu’aucune exploitation en production n’a été confirmée, tandis qu’un avis d’incident distinct affirme qu’une exploitation a été observée dans la nature.

Une faille de gravité maximale ne nécessitant aucun identifiant

CVE-2026-86218 obtient le score maximal de 10,0 selon CVSS 4.0, avec le vecteur suivant :

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

L’évaluation décrit une vulnérabilité accessible via le réseau et exploitable avec une faible complexité d’attaque. L’attaquant n’a besoin ni d’un compte, ni de privilèges, ni de l’intervention d’un utilisateur légitime.

Une exploitation réussie peut avoir des conséquences importantes sur la confidentialité, l’intégrité et la disponibilité, à la fois sur le serveur N-central et sur les systèmes en aval. Cette portée est particulièrement préoccupante pour un produit RMM, puisque les serveurs N-central administrent des parcs de terminaux clients et fournissent des fonctionnalités de prise de contrôle à distance.

La faiblesse sous-jacente est classée CWE-96, qui correspond à une neutralisation incorrecte de directives dans du code enregistré de manière statique. Cette catégorie est généralement décrite comme une injection de code statique : des directives contrôlées par l’attaquant sont intégrées à du code ou à une autre ressource exécutable, puis enregistrées et traitées ultérieurement.

N-able n’a pas publié le composant vulnérable, le format des requêtes nécessaires, la procédure d’exploitation ni aucun autre détail technique permettant de reproduire le problème. Aucun indicateur de compromission public n’a été communiqué.

D’après la fiche CVE, la plage concernée commence à la version 0 et couvre toutes les versions antérieures à 2026.3.1.14. Le produit vulnérable est le serveur N-central, et non les agents qu’il gère.

Les systèmes équipés de Hotfix 3 restent exposés

Hotfix 4 est nécessaire même sur les serveurs ayant déjà reçu Hotfix 3, build 2026.3.1.13. La version précédente corrigeait deux failles distinctes :

• CVE-2026-86206 concernait un accès non autorisé aux API internes via le filtre de contrôle d’accès aux API internes de N-central. N-able lui a attribué un score CVSS de 6,9, moyen, tandis que la NVD la classe sous CWE-791. Elle est corrigée dans N-central 2026.3 HF3 et 2026.4.
• CVE-2026-86207 était un contournement de l’authentification affectant des API exclusivement internes. N-able lui a attribué un score CVSS de 7,7, élevé ; elle est classée sous CWE-305. Les versions antérieures à 2026.3 HF3 sont concernées.

N-able affirme que ces deux vulnérabilités n’ont aucun lien avec CVE-2026-86218. L’installation de Hotfix 3 ne permet donc pas de neutraliser la nouvelle voie d’exécution de code pré-authentification.

Hotfix 4 est la quatrième mise à jour de la branche N-central 2026.3 en cinq semaines. Hotfix 1, build 2026.3.1.7, est arrivé le 2 août pour corriger CVE-2026-18577, une correction incomplète d’un précédent contournement de l’authentification. Hotfix 2, build 2026.3.1.10, a suivi le 6 août avec des mesures de renforcement supplémentaires.

Hotfix 3, build 2026.3.1.13, a été publié le 5 septembre. Hotfix 4 a suivi le 6 septembre.

Cette succession rapide signifie que les administrateurs ne peuvent pas considérer la présence d’un correctif 2026.3 récent comme la preuve qu’un serveur est protégé. Le numéro de build doit être vérifié directement.

N-able livre des versions contradictoires sur l’exploitation active

Le statut de l’exploitation reste indéterminé.

Les documents de publication de Hotfix 4 et la mise à jour de statut de N-able indiquent qu’un tiers externe a signalé la vulnérabilité de manière responsable dans le cadre du programme de divulgation de l’entreprise. Ces communications précisent que N-able ne dispose d’aucune preuve confirmée d’une exploitation dans des environnements de production.

Un avis d’incident distinct de N-able fournit toutefois une version différente. Il indique qu’un troisième chercheur indépendant en sécurité a signalé une nouvelle vulnérabilité sans lien avec les précédentes, qui avait été observée en cours d’exploitation dans la nature.

Cet avis ne précise pas qui a observé les attaques, quels environnements ont été touchés, quand l’activité s’est produite ni comment l’exploitation a été vérifiée. La documentation de N-able qualifie également CVE-2026-86218 de « zero-day critique », sans toutefois définir la manière dont l’entreprise emploie ce terme.

L’incident était toujours ouvert sur la page d’état de N-able le 7 septembre 2026. Aucun acteur malveillant n’a été identifié.

Huntress a commencé à examiner une compromission le 4 septembre, après l’intrusion dans l’environnement N-central de production entièrement corrigé d’un client. Ses chercheurs ont reproduit une chaîne d’exploitation contre le build 2026.3.1.10, qui pourrait impliquer l’une des deux vulnérabilités corrigées par la suite dans Hotfix 3, ou les deux.

Cependant, les journaux pertinents de l’appliance avaient déjà subi une rotation. Huntress n’a pas pu déterminer si CVE-2026-86218 faisait partie de cette intrusion.

Il existe donc une raison crédible de considérer la faille comme une menace immédiate, mais aucune preuve documentée publiquement ne permet encore d’établir l’existence d’une attaque spécifique utilisant cette CVE.

D’anciennes failles de N-central ont été ajoutées au catalogue KEV de la CISA

Il n’a pas été signalé que CVE-2026-86218 avait été ajoutée au catalogue des vulnérabilités exploitées connues de l’agence américaine de cybersécurité et de sécurité des infrastructures (CISA). Aucune échéance de remédiation KEV n’est connue pour cette vulnérabilité.

Plusieurs vulnérabilités récentes de N-central ont toutefois été ajoutées au catalogue.

CVE-2026-18577, une correction incomplète permettant un contournement de l’authentification et une prise de contrôle de compte, a été ajoutée au catalogue KEV le 3 août 2026. Les agences fédérales ont reçu une échéance de remédiation fixée au 6 août 2026. La faille concerne les versions de N-central antérieures à 2026.3 et obtient un score CVSS 3.1 de 8,1.

CVE-2026-18556 a été ajoutée le 4 août 2026, avec une remédiation exigée au plus tard le 7 août 2026. Ce contournement de l’authentification par une voie alternative concerne N-central <= 2026.1 et obtient un score CVSS de 7,4.

Pour ces deux vulnérabilités, la CISA exige des mesures d’atténuation conformes aux instructions du fournisseur, aux recommandations de correction fondées sur les risques de la BOD 26-04 ainsi qu’à ses exigences en matière de triage forensique.

Deux failles plus anciennes de N-central, CVE-2025-8875 et CVE-2025-8876, ont été ajoutées au catalogue KEV le 13 août 2025, avec une échéance fédérale fixée au 20 août 2025. Elles ont obtenu respectivement des scores CVSS de 7,8 et 8,8. La CISA a demandé aux organisations d’appliquer les mesures d’atténuation du fournisseur, de suivre les recommandations cloud applicables de la BOD 22-01 ou d’abandonner le produit si aucune mesure d’atténuation n’était disponible.

L’historique récent est important sur le plan opérationnel : N-central a été ciblé à plusieurs reprises au moyen de vulnérabilités permettant d’obtenir des accès privilégiés ou d’exécuter du code.

Appliquer le correctif en priorité, puis rechercher les accès persistants

Toute organisation utilisant N-central sur site devrait installer 2026.3 Hotfix 4, afin de mettre le serveur à jour vers le build 2026.3.1.14. N-able propose des chemins de mise à niveau directs depuis :

• 2025.4
• 2026.1
• 2026.2
• 2026.3
• Les builds Hotfix 2026.3.1 existants

Les agents gérés n’ont pas besoin d’être mis à jour pour CVE-2026-86218. La version hébergée N-central Online, également appelée NCOD, aurait déjà été corrigée.

Si l’installation immédiate est impossible, les administrateurs devraient restreindre l’accès entrant à la console au moyen d’une liste d’autorisation d’adresses IP ou d’un VPN. Un serveur N-central accessible depuis Internet et ne pouvant pas être corrigé rapidement devrait être temporairement retiré du réseau.

L’application du correctif ne suffit pas à établir qu’un système déjà exposé est sain. Les administrateurs devraient vérifier dans N-central l’absence d’utilisateurs non autorisés, de créations de comptes inattendues et de modifications inexpliquées des privilèges.

Lors d’attaques précédentes détectées après une intrusion le 31 juillet, les attaquants ont utilisé des accès administratifs pour détourner la fonctionnalité Take Control de N-central. Ils ont ensuite enregistré des services de tunnel Cloudflare sur des terminaux gérés, ce qui leur a permis de conserver un accès après la suppression de leur point d’entrée par N-central.

Les équipes de défense devraient donc examiner :

• Les modifications apportées aux comptes administrateurs et utilisateurs ;
• L’activité de Take Control sur l’ensemble des terminaux gérés ;
• Les accès aux API internes de N-central ;
• Les tunnels Cloudflare nouveaux ou non autorisés ;
• Les sessions de gestion à distance inattendues ;
• Les journaux disponibles du serveur et de l’appliance avant leur rotation.

N-able n’a publié ni indicateurs propres à CVE, ni solution de contournement, ni règles de détection détaillées. Tant que la contradiction concernant l’exploitation n’est pas résolue, les organisations devraient considérer le build 2026.3.1.14 comme la version minimale sûre et conserver les éléments de preuve avant leur suppression par la politique habituelle de rétention des journaux.