N-central wird aktiv angegriffen – Hotfix 4 ersetzt Hotfix 3
Seit dem 8. September 2026 gilt CVE-2026-86218 in N-central als aktiv ausgenutzt; am 9. September bestätigte N-able erstmals erfolgreiche Angriffe auf eine kleine Zahl eigener Kunden. Laut der aktualisierten Mitteilung des Herstellers müssen lokal betriebene Instanzen deshalb auf 2026.3 HF4 wechseln, auch wenn Hotfix 3 bereits installiert ist.
Entscheidend ist Build 2026.3.1.14: Das kanadische Cyber Centre führt alle früheren N-central-Versionen als betroffen und dokumentiert den CISA-KEV-Eintrag vom 8. September. Von N-able gehostete Instanzen wurden bereits gepatcht; bei diesen Umgebungen müssen Kunden Hotfix 4 nicht selbst installieren.
Build 2026.3.1.14 ist die maßgebliche Versionsgrenze
Für On-Premises-Installationen ist die Entscheidung eindeutig: Eine Build-Nummer unter 2026.3.1.14 bedeutet, dass das System gegen CVE-2026-86218 nicht ausreichend geschützt ist. Das schließt Hotfix 3 mit Build 2026.3.1.13 ausdrücklich ein.
- Lokale Instanz vor Build 2026.3.1.14: 2026.3 HF4 installieren und den erreichten Serverstand anschließend kontrollieren.
- Lokale Instanz mit Hotfix 3: erneut aktualisieren; HF3 behebt die später bekannt gewordene Schwachstelle nicht.
- Von N-able gehostete Instanz: Der Hersteller hat den Patch bereits eingespielt, sodass kein kundenseitiges Hotfix-Upgrade erforderlich ist.
Hotfix 4 ist eine serverseitige Aktualisierung. Ein gleichzeitiges Upgrade der von N-central verwalteten Agents ist dafür nicht erforderlich. Diese Trennung ist für MSPs wichtig, weil sie den zentralen Server sofort absichern können, ohne zuerst einen Rollout auf sämtliche verwalteten Endpunkte koordinieren zu müssen.
Hotfix 4 gehört zu einer neuen, unabhängigen Schwachstelle
Die dichte Abfolge der Korrekturen erklärt, weshalb ein vermeintlich aktueller Server erneut verwundbar sein kann. N-able veröffentlichte Hotfix 3 am 5. September für CVE-2026-86206 und CVE-2026-86207; am 6. September folgte Hotfix 4 für die davon unabhängige CVE-2026-86218.
Nach Angaben des Herstellers kann CVE-2026-86218 einen Zugriff auf den N-central-Server vor erfolgreicher Authentifizierung ermöglichen. Die Untersuchung von Huntress ordnet die Lücke als ausgenutzte Pre-Auth-RCE ein, bestätigt, dass HF4 den Build 2026.3.1.13 ersetzt, und hält zugleich eine wichtige Grenze fest: Bei einem untersuchten Einbruch waren ältere Appliance-Protokolle bereits rotiert, weshalb sich der konkrete Weg des Erstzugriffs nicht abschließend einer der September-Lücken zuordnen ließ.
Der Status hat sich danach weiter verschärft. Zunächst lag die Meldung eines unabhängigen Forschers über eine erfolgreiche Ausnutzung in dessen eigener Produktionsumgebung vor; am 8. September nahm CISA CVE-2026-86218 in den Katalog bekanntermaßen ausgenutzter Schwachstellen auf. Einen Tag später erklärte N-able, inzwischen selbst eine kleine Zahl erfolgreicher Angriffe auf Kunden beobachtet zu haben.
Patchen allein klärt eine mögliche Kompromittierung nicht
Build 2026.3.1.14 schließt die bekannte Schwachstelle, entfernt aber keine Veränderungen, die ein Angreifer zuvor vorgenommen haben könnte. Betreiber sollten daher nicht nur den Patchstand prüfen, sondern den Zeitraum vor der Aktualisierung auf verdächtige Verwaltungsaktivitäten untersuchen.
- Neu angelegte Benutzer sowie unerwartete Änderungen an Rollen und Berechtigungen kontrollieren.
- Besonders auf Konten mit .invalid-Adressen, vertauschten Zeichen oder nachgeahmten Domains achten.
- In envoy_proxy_HTTPS.log und syslog ncentraldms nach erfolgreichen Anfragen an interne API-Routen mit URL-kodierten Bestandteilen wie %2F suchen.
- Verbindungen aus dem von N-able beobachteten Scan-Netz 23.234.64.0/18 mit Zeitstempeln, Anmeldungen und administrativen Aktionen abgleichen.
Keines dieser Merkmale beweist für sich allein eine erfolgreiche Ausnutzung von CVE-2026-86218. Ein Netzwerkkontakt kann lediglich ein Scan gewesen sein, ungewöhnlich geschriebene Konten können einen anderen Ursprung haben, und die von Huntress beschriebenen API- und Kontenspuren entstanden im Umfeld mehrerer September-Schwachstellen. Aussagekräftig werden die Befunde erst durch ihre zeitliche und technische Korrelation.
Kurze Aufbewahrungsfristen erschweren diese Zuordnung. Verdächtige Appliance-, Proxy-, Firewall- und Authentifizierungsprotokolle sollten deshalb gesichert werden, bevor Rotation weitere historische Daten entfernt. Auch administrative Vorgänge ohne passendes Ticket oder Wartungsfenster sowie unerwartete Remote-Control-Sitzungen verdienen eine gesonderte Prüfung.
Externe Erreichbarkeit bleibt ein eigenständiges Risiko
Die Verwaltungskonsole einer lokalen N-central-Instanz sollte nicht uneingeschränkt aus dem öffentlichen Internet erreichbar sein. Sinnvolle Begrenzungen sind feste Quellnetze, IP-Freigabelisten, Firewall-Regeln oder ein verpflichtender VPN-Zugang. Diese Kontrollen verkleinern die erreichbare Angriffsfläche, ersetzen jedoch weder HF4 noch die Untersuchung möglicher Altspuren.
Damit ist die Versionsfrage geklärt: Gehostete Instanzen wurden von N-able versorgt, während lokale Systeme mindestens Build 2026.3.1.14 benötigen und Hotfix 3 nicht mehr genügt. Offen bleiben der vollständige Umfang der erfolgreichen Angriffe und weitere technische Einzelheiten zu den beobachteten Kompromittierungen; die bislang veröffentlichten Erkennungsmerkmale sind daher als Ermittlungsansätze und nicht als abschließende Beweisliste zu verstehen.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.