N-able N-central CVE-2026-18577: Authentication Bypass mit bestätigten Kundenkompromittierungen — in der CISA-KEV, Fix nur mit Hotfix 2

TL;DR — 90 Sekunden

Betroffen?

Alle N-able N-central-Installationen vor Build 2026.3.1.10 (Hotfix 2) — sowohl selbstgehostete On-Premises-Instanzen als auch, bis zur automatischen Aktualisierung durch N-able, gehostete Cloud-Instanzen. Der erste Hotfix (Build 2026.3.1.7 vom 02.08.2026) reicht laut N-able nicht aus.

Risiko?

Authentication Bypass über einen alternativen Pfad, der den Fix für CVE-2026-18556 umgeht (CVE-2026-18577, CVSS 8.2) — führt zur vollständigen Übernahme von N-central-Admin-Konten aus der Ferne, teils über das mitgelieferte Standardkonto „MSP Support“. Aktiv ausgenutzt, bestätigte Kundenkompromittierungen, in der CISA-KEV seit 03.08.2026.

Sofortmaßnahme?

Auf Build 2026.3.1.10 (Hotfix 2, 06.08.2026) aktualisieren — nicht nur auf Hotfix 1. Gehostete Instanzen wurden laut N-able bereits automatisch aktualisiert; selbstgehostete Installationen müssen manuell upgraden. Parallel Take-Control-Sitzungsprotokolle und Zugriffslogs auf die bekannten Indikatoren prüfen.

Empfehlung?

MSPs sollten die Aktualisierung nicht nur durchführen, sondern auch prüfen, ob vor dem Patch bereits nicht autorisierte Take-Control-Sitzungen stattfanden. Unternehmen, die selbst keinen N-central betreiben, aber von einem MSP betreut werden, sollten aktiv nachfragen, ob dieser N-central einsetzt, gepatcht hat und die eigenen Endpunkte auf die genannten Indikatoren geprüft wurden.

Kritikalität?

kritisch (Hero-Badge) — CVSS 8.2, bestätigte aktive Ausnutzung mit realen Kundenkompromittierungen, CISA-KEV-Eintrag und ein Blast-Radius, der über den N-central-Server hinaus auf sämtliche über Take Control erreichbaren Kunden-Endpunkte reicht.

Was ist das Problem?

N-central ist die Remote-Monitoring-and-Management-Plattform (RMM) des Herstellers N-able: MSPs installieren Agenten auf den Endpunkten ihrer Kundenunternehmen und verwalten darüber zentral Patchstände, Monitoring, Backups und — über die integrierte „Take Control“-Funktion — den direkten Fernzugriff auf einzelne Rechner. N-central ist sowohl als selbstgehostete On-Premises-Installation als auch als von N-able gehostete Cloud-Variante verfügbar; laut N-able sind beide Betriebsarten von der aktuellen Schwachstelle betroffen.

Ausgangspunkt der aktuellen Lage ist CVE-2026-18556, eine unauthentifizierte Möglichkeit zur Übernahme von Administrator-Konten, die N-able nach eigener Einschätzung mit Version 2026.2 behoben hatte. Der Fix erwies sich jedoch als unvollständig: Sicherheitsforscher fanden einen alternativen Weg, dieselbe zugrunde liegende Schwäche in der Authentifizierungslogik auszunutzen, den der ursprüngliche Patch nicht abdeckte. Dieser Bypass wurde als eigenständige Schwachstelle unter CVE-2026-18577 registriert und erweitert den betroffenen Versionsbereich auf praktisch alle Builds vor 2026.3.1.7. CISA beschreibt die Lücke knapp als „authentication bypass using an alternate path or channel that allows for authentication bypass and account takeover in N-central“ — eine Formulierung, die exakt auf das Muster „Patch schließt einen Weg, Angreifer nehmen den anderen“ passt.

Für Angreifer ist das besonders wertvoll, weil N-central selbst kein gewöhnliches Endpunkt-System ist, sondern die zentrale Verwaltungsinstanz für potenziell hunderte Kundenumgebungen eines MSP. Eine erfolgreiche Kontenübernahme auf dieser Ebene wirkt sich damit nicht nur auf den N-central-Server selbst aus, sondern schlägt unmittelbar auf alle darüber verwalteten Kunden durch.

Wer ist betroffen?

N-central wird nicht typischerweise von Endanwendern selbst betrieben, sondern von Managed Service Providern (MSPs) — IT-Dienstleistern, die für eine Vielzahl von Kundenunternehmen Monitoring, Patching und Support übernehmen. Genau das macht die Betroffenheitsfrage für die meisten Leser:innen dieses Beitrags zweistufig: Wer selbst MSP ist oder eine eigene N-central-Instanz betreibt, ist unmittelbar betroffen und muss patchen. Wer dagegen IT-Dienstleistungen von einem MSP bezieht, kennt möglicherweise nicht einmal den Namen des im Hintergrund eingesetzten RMM-Produkts — ist über die Take-Control-Anbindung des eigenen MSP aber potenziell ebenso im Blast-Radius, ohne selbst etwas patchen zu können. Für diese Gruppe ist aktives Nachfragen beim eigenen Dienstleister die einzig wirksame Handlungsoption, siehe Abschnitt „Betreiberempfehlung“.

Auswirkungen

Eine erfolgreiche Ausnutzung von CVE-2026-18577 gibt einem Angreifer administrativen Zugriff auf den N-central-Server — in der Praxis vollständige Kontrolle über die zentrale Verwaltungsinstanz eines MSP. Von dort aus lässt sich die eingebaute „Take Control“-Funktion missbrauchen, um auf jeden verwalteten Kunden-Endpunkt fernzugreifen, für den der MSP eine Take-Control-Berechtigung eingerichtet hat — technisch dieselbe Funktionalität, die Support-Techniker:innen im Alltag für Fernwartung nutzen, nur eben mit Admin-Rechten und ohne Zustimmung der eigentlichen Nutzenden.

Laut übereinstimmender Berichterstattung (u. a. Huntress, Rapid7) zeigt sich in den bislang beobachteten Angriffen ein wiederkehrendes Muster: Angreifer melden sich unter Nutzung des im N-central-Standardumfang enthaltenen „MSP Support“-Kontos von den bekannten IOC-IP-Adressen aus an, führen anschließend Prozessenumeration und Aufklärung auf den erreichbaren Systemen durch — mit besonderem Fokus auf Domain-Controller —, bevor sie sich lateral in der Zielumgebung weiterbewegen oder die Verbindung zunächst wieder trennen. Für Persistenz wird laut Berichten der legitime Cloudflare-Tunnel-Client (cloudflared) missbraucht, der als scheinbar harmloser Dienst eine verdeckte Command-and-Control-Verbindung nach außen aufbaut, ohne dass klassische eingehende Firewall-Regeln greifen. Weil ein einzelner kompromittierter N-central-Server potenziell Dutzende bis Hunderte Kundenumgebungen abdeckt, ist das Schadenspotenzial eines erfolgreichen Angriffs damit strukturell höher als bei den meisten Einzelsystem-Schwachstellen — es handelt sich faktisch um ein Lieferketten-Risiko mit RMM als Hebel.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Heute handeln, wenn … Sie selbst eine selbstgehostete N-central-Instanz betreiben, die noch nicht auf Build 2026.3.1.10 (Hotfix 2) aktualisiert ist — unabhängig davon, ob bereits Hotfix 1 installiert wurde.
• Mit Priorität prüfen, wenn … Sie N-central als gehostete Cloud-Instanz nutzen: N-able hat die Mitigation dort laut eigener Aussage automatisch ausgerollt, eine Verifikation der eigenen Take-Control- und Zugriffslogs auf die genannten Indikatoren bleibt dennoch sinnvoll.
• Nur beobachten, wenn … Ihr Unternehmen selbst keinen N-central betreibt, sondern von einem MSP betreut wird — hier ist aktives Nachfragen beim Dienstleister die richtige Maßnahme, siehe unten.

Schritt 1 — Auf Hotfix 2 (Build 2026.3.1.10) aktualisieren

# Installierte Version pruefen: N-central-Weboberflaeche -> About / Systeminformationen
#
# Wichtig: Hotfix 1 (Build 2026.3.1.7, veroeffentlicht 02.08.2026) reicht laut
# N-able NICHT aus. Erst Hotfix 2 (Build 2026.3.1.10, veroeffentlicht 06.08.2026)
# schliesst CVE-2026-18577 vollstaendig.
#
# Unterstuetzte Upgrade-Pfade direkt auf Build 2026.3.1.10 laut N-able-Statusseite:
#   2025.4               -> 2026.3.1.10
#   2026.1               -> 2026.3.1.10
#   2026.2               -> 2026.3.1.10
#   2026.3               -> 2026.3.1.10
#   2026.3.1 (Hotfix 1)  -> 2026.3.1.10
#
# Gehostete (Cloud-)Instanzen: laut N-able automatisch aktualisiert, keine Aktion noetig.
# Selbstgehostete (On-Premises-)Instanzen: manuelles Upgrade zwingend erforderlich.

Schritt 2 — Take-Control- und Zugriffsprotokolle prüfen

# N-central-Zugriffslog auf Sitzungen von den bekannten IOC-IP-Adressen und auf
# ungewoehnliche Aktivitaet des Standardkontos "MSP Support" pruefen
# (Log-Pfad/-Name je nach Version, u. a. ui_access_control.log)
#
# Take-Control-Sitzungshistorie auf nicht erklaerbare Sitzungen ausserhalb
# regulaerer Support-Zeiten oder gegenueber unerwarteten Zielsystemen (insbesondere
# Domain-Controller) durchsehen

Schritt 3 — Zugangsdaten und API-Keys rotieren (generelle Empfehlung)

N-able selbst benennt in der öffentlichen Kommunikation keinen verpflichtenden Rotationsschritt; angesichts des Charakters der Schwachstelle — Übernahme eines Admin-Kontos mit Zugriff auf sämtliche in N-central hinterlegten Zugangsdaten und API-Keys für angebundene Kundenumgebungen — ist eine vorsorgliche Rotation aller in N-central gespeicherten Credentials und API-Keys nach dem Update dennoch eine naheliegende, allgemein übliche Absicherungsmaßnahme, insbesondere wenn Indikatoren für eine Kompromittierung vorliegen.

Für Kunden eines MSP: was Sie fragen sollten

• Setzt unser Dienstleister N-able N-central ein — und wenn ja, selbstgehostet oder als N-able-gehostete Cloud-Instanz?
• Ist die Instanz bereits auf Build 2026.3.1.10 (Hotfix 2) aktualisiert, nicht nur auf Hotfix 1?
• Wurden die Take-Control- und Zugriffsprotokolle für unsere Umgebung gezielt auf die bekannten Indikatoren geprüft?
• Wurden auf unseren Endpunkten die unter „Detection / Prüfung“ genannten Artefakte (svchost.exe im Documents-Ordner, Dienst „Cloudflared“) gesucht?

Detection / Prüfung

N-able und Huntress haben im Verlauf der Untersuchung mehrere konkrete Indikatoren veröffentlicht. Die folgenden Angaben stammen aus der öffentlichen Berichterstattung und sollten als Ausgangspunkt für eine eigene Prüfung verstanden werden, nicht als vollständige forensische Anleitung.

Bekannte Artefakte auf Endpunkten

• Eine Datei namens svchost.exe im Documents-Ordner betroffener Nutzer:innen — Achtung: Das ist nicht die echte Windows-Systemdatei svchost.exe (die regär unter C:\Windows\System32 liegt), sondern eine bösartige Datei, die bewusst den Namen der legitimen Windows-Komponente trägt, um bei einer oberflächlichen Prüfung nicht aufzufallen.
• Ein neu registrierter Windows-Dienst namens „Cloudflared“, der den legitimen Cloudflare-Tunnel-Client missbraucht, um eine verdeckte, ausgehende Verbindung für Command-and-Control aufzubauen.
• Laut Huntress zusätzlich beobachtete, ungewöhnliche DDNS-artige Domainnamen im Netzwerkverkehr (u. a. auf synology.me- und quickconnect.to-Subdomains) — diese Angaben stammen aus Sekundärquellen und sollten vor Ort verifiziert werden.

Bekannte Netzwerk-IOCs

Erste Berichterstattung (u. a. der CISA-KEV-Eintrag) nannte vier IP-Adressen, die als VPN-Exit-Nodes (Mullvad/NordVPN) identifiziert wurden:

• 173.249.252.200
• 87.249.138.34
• 37.19.210.32
• 68.235.46.214

Huntress' laufende Recherche hat diese Liste im Verlauf der Untersuchung um weitere Adressen erweitert; zum Zeitpunkt dieses Beitrags wurden zusätzlich u. a. 37.153.90.88, 92.118.112.181, 173.249.252.176, 185.156.46.150, 23.234.94.43 und 68.235.46.235 genannt. Die genaue, abschließende Zahl und Zusammensetzung der IOC-Liste war zum Zeitpunkt der Recherche noch im Fluss — für eine aktuelle, autoritative Liste empfiehlt sich der direkte Blick in N-ables Entwicklerportal bzw. die Huntress-Quelle (siehe Quellen).

N-central-seitige Prüfung

• Zugriffslog (u. a. ui_access_control.log) auf Sitzungen von den genannten IP-Adressen durchsuchen.
• Aktivität des Standardkontos „MSP Support“ auf ungewöhnliche Zeiten oder untypische Zielsysteme prüfen.
• Take-Control-Sitzungsverlauf auf nicht durch reguläre Supportvorgänge erklärbare Sitzungen durchsehen, mit besonderem Augenmerk auf Domain-Controller und andere kritische Server.

Endpunktseitige Prüfung

• Auf betroffenen Windows-Endpunkten den Dateisystempfad C:\ProgramData\GetSupportService_N-Central\Logs\ auf Dateien nach dem Muster BASupSrvc_*.log.gz und deren Erstellungszeitpunkte im Vergleich zu auffälligen N-central-Sitzungen prüfen.
• Windows-Ereignisprotokolle auf Sitzungen mit Bezug zum „MSP Support“-Konto sowie auf Start/Ende von Take-Control-Sitzungen durchsuchen.
• Windows-Dienste auf einen unerwarteten Eintrag namens „Cloudflared“ sowie Documents-Ordner auf eine untergeschobene svchost.exe prüfen.

N-able stellt nach eigenen Angaben zusätzliche Erkennungswerkzeuge und eine aktuelle IOC-Liste über das eigene Entwicklerportal bereit; wer selbst N-central betreibt, sollte diese Quelle direkt konsultieren, da sich der Kenntnisstand zu dieser aktiven Kampagne noch weiterentwickelt.

Betreiberempfehlung

MSPs, die N-central selbst betreiben

Prüfen Sie umgehend den Patch-Stand Ihrer N-central-Instanz: Hotfix 1 allein reicht nicht, erst Build 2026.3.1.10 (Hotfix 2) schließt CVE-2026-18577 vollständig. Prüfen Sie parallel Take-Control- und Zugriffsprotokolle rückwirkend auf die genannten Indikatoren — auch nach dem Update, um festzustellen, ob vor der Aktualisierung bereits nicht autorisierte Zugriffe stattfanden. Erwägen Sie eine vorsorgliche Rotation der in N-central hinterlegten Zugangsdaten und API-Keys sowie eine gezielte Prüfung Ihrer verwalteten Kunden-Endpunkte auf die endpunktseitigen Artefakte. Kommunizieren Sie proaktiv mit Ihren eigenen Kund:innen — gerade weil diese in aller Regel nicht wissen, dass ihre Umgebung über N-central verwaltet wird, erwarten sie von Ihnen als Dienstleister eine aktive Information, keine stille Behebung im Hintergrund.

Unternehmen, die von einem MSP betreut werden

Sie können N-central selbst nicht patchen, aber Sie können und sollten aktiv nachfragen: ob Ihr Dienstleister N-central einsetzt, ob die Instanz bereits auf Hotfix 2 aktualisiert ist, ob Ihre Umgebung gezielt auf die genannten IOCs geprüft wurde und ob es Hinweise auf nicht autorisierte Take-Control-Sitzungen gegen Ihre Systeme gibt. Ein Dienstleister, der auf diese Fragen keine klare Antwort geben kann oder will, ist selbst ein Warnsignal.

Decision block

• Sofort patchen: Eigene N-central-Instanz auf Build 2026.3.1.10 (Hotfix 2) aktualisieren, nicht auf Hotfix 1 stehen bleiben.
• Kompensieren, falls Patch verzögert: Zugriff auf die N-central-Weboberfläche auf vertrauenswürdige Netze/VPN beschränken, Multi-Faktor-Authentifizierung für alle administrativen Konten erzwingen, „MSP Support“-Konto besonders überwachen oder deaktivieren, falls im eigenen Betrieb nicht benötigt.
• Beobachten: Take-Control- und Zugriffsprotokolle laufend auf die genannten Indikatoren prüfen, auch nach dem Update — als Nachweis, ob vor der Aktualisierung bereits Zugriffe stattfanden.

Fazit

CVE-2026-18577 ist ein Lehrstück darüber, wie unvollständige Patches funktionieren: Ein Hersteller schließt eine Schwachstelle, Angreifer finden den zweiten Weg zum selben Ziel, und plötzlich braucht es einen zweiten CVE-Eintrag und einen weiteren Hotfix, um dieselbe zugrunde liegende Schwäche wirklich zu beseitigen — bei N-central binnen weniger Tage gleich zweimal (Hotfix 1 am 02.08., Hotfix 2 am 06.08.2026). Was diesen Fall über den reinen Patch-Zyklus hinaus relevant macht, ist die bestätigte aktive Ausnutzung mit realen Kundenkompromittierungen und die Rolle von N-central als zentrale Verwaltungsinstanz für MSPs: Ein einziger übernommener Server öffnet über die Take-Control-Funktion potenziell den Weg zu jedem verwalteten Kunden-Endpunkt. Wer RMM- oder ähnliche Fernwartungsplattformen einsetzt oder — als Kunde eines MSP — indirekt von ihnen abhängt, sollte diesen Fall als Anlass nehmen, die eigene Abhängigkeit von einem einzelnen, hochprivilegierten Werkzeug grundsätzlich zu hinterfragen: Patchen allein reicht nicht, wenn die Architektur selbst einen derart großen Blast-Radius erlaubt.

Quellen

• The Hacker News — CISA Adds Exploited N-able N-central Flaw to KEV Catalog
• The Hacker News — N-able Says Attackers Take Over N-central Servers After Initial Fix Proves Incomplete
• Huntress — Critical N-able N-central Vulnerability and Active Exploitation
• N-able Status — N-central 2026.3 Hotfix 1: Mitigation for CVE-2026-18577
• N-able Status — N-central 2026.3 Hotfix 2: Additional Mitigation for CVE-2026-18577
• N-able — N-central Security Update, August 6, 2026
• Rapid7 — CVE-2026-18577: N-able N-central Authentication Bypass Exploited in the Wild