N-able N-central: Authentication-Bypass CVE-2026-18577 wird trotz zweier Hotfixes weiter ausgenutzt

Was ist N-central - und warum betrifft das mehr als nur N-able-Kunden

N-central ist eine Remote-Monitoring-and-Management-Plattform (RMM) des Herstellers N-able. Managed Service Provider (MSP) und interne IT-Abteilungen setzen sie ein, um von einer zentralen Konsole aus tausende Windows-, Mac- und Linux-Endpunkte zu ueberwachen, Patches auszurollen, Skripte auszufuehren und bei Bedarf per Fernzugriff auf einzelne Rechner zuzugreifen. Genau diese Zentralitaet macht RMM-Software zu einem besonders lohnenden Angriffsziel: Wer den N-central-Server kompromittiert, bekommt potenziell Zugriff auf jeden Rechner, den dieser Server verwaltet - nicht nur beim MSP selbst, sondern bei allen Kundenfirmen, die ueber diesen Server betreut werden. Sicherheitsforscher sprechen bei RMM-Plattformen deshalb von einem "Single Point of Compromise": Ein einziger erfolgreicher Angriff kann sich auf Dutzende oder Hunderte nachgelagerte Organisationen auswirken. Das ist der Grund, warum die aktuelle Luecke in N-central weit ueber die eigentliche N-able-Kundschaft hinaus relevant ist - betroffen sein koennen auch Firmen, die N-central nie selbst installiert haben, aber von einem MSP betreut werden, der es einsetzt.

Die Zeitleiste: von der ersten Ausnutzung bis zum zweiten Hotfix

Die Ereignisse ueberschlugen sich innerhalb weniger Tage:

**1. August 2026:** N-able bestaetigt aktive Ausnutzung einer Authentication-Bypass-Schwachstelle in N-central (CVE-2026-18556). Betroffen sind alle Releases bis einschliesslich Version 2026.1.

**2. August 2026:** N-able veroeffentlicht N-central 2026.3 Hotfix 1 (Build 2026.3.1.7). Der Hotfix schliesst den urspruenglich ausgenutzten Pfad - aber, wie sich kurz darauf zeigt, nicht vollstaendig.

**3. August 2026:** CISA nimmt CVE-2026-18577 - die Fortsetzung derselben Bypass-Klasse ueber einen alternativen Pfad, den Hotfix 1 nicht abdeckte - wegen bestaetigter aktiver Ausnutzung in den KEV-Katalog auf.

**4. August 2026:** CISA ergaenzt in einer Sammelmeldung drei weitere aktiv ausgenutzte Schwachstellen im KEV-Katalog, darunter auch die urspruengliche CVE-2026-18556 sowie - bei anderen Produkten - eine Luecke in IBM Langflow und eine in Apache Tomcat.

**6. August 2026:** N-able liefert N-central 2026.3 Hotfix 2 (Build 2026.3.1.10) mit zusaetzlichen Haertungsmassnahmen nach, nachdem klar wird, dass Angreifer die Luecke trotz Hotfix 1 weiter ausnutzen.

**10. August 2026:** Sicherheitsmedien berichten, dass Ausnutzungsversuche gegen ungepatchte Server weiterhin beobachtet werden - mehr als eine Woche nach der ersten Warnung.

Die kurze Taktung zwischen erstem Hotfix, KEV-Aufnahme und zweitem Hotfix ist ungewoehnlich und deutet darauf hin, dass N-able unter erheblichem Zeitdruck nachbessern musste, nachdem klar wurde, dass die erste Reparatur nicht ausreichte.

Wie der Authentication Bypass technisch funktioniert

Beide CVEs sind nach der CWE-Systematik als "Authentication Bypass Using an Alternate Path or Channel" eingeordnet - eine Schwachstellenklasse, die auch OWASP unter "Broken Access Control" beziehungsweise fehlerhafter Authentifizierungslogik fuehrt. Das Grundmuster: Eine Anwendung prueft Zugangsberechtigungen zuverlaessig auf dem regulaeren, dokumentierten Pfad - etwa dem normalen Login-Formular - laesst aber eine zweite, weniger offensichtliche Route zur selben privilegierten Funktion offen, auf der die Pruefung fehlt, falsch konfiguriert ist oder sich umgehen laesst.

Bei N-central bedeutet das konkret: Ein nicht authentifizierter Angreifer kann ueber diesen alternativen Pfad direkt administrative Funktionen der Konsole erreichen, ohne jemals ein gueltiges Passwort oder einen zweiten Faktor vorweisen zu muessen. Der erste Hotfix von N-able schloss den urspruenglich bekannten und ausgenutzten Weg (CVE-2026-18556). Was der Patch nicht abdeckte, war ein zweiter Pfad zur selben zugrunde liegenden Schwachstelle im Berechtigungsmodell - genau dieser Rest wurde als CVE-2026-18577 katalogisiert. Diese Konstellation ist ein Lehrbuchbeispiel fuer ein bekanntes Patch-Problem: Wenn ein Fix nur den beobachteten Ausnutzungsweg blockiert, statt die zugrunde liegende Ursache in der Zugriffskontrolle zu beheben, bleiben verwandte Wege offen. Sicherheitsteams sollten das bei der Bewertung eigener Patches im Hinterkopf behalten - "Exploit blockiert" ist nicht dasselbe wie "Schwachstelle behoben".

Vom Server zum Endpunkt: Take Control und der Cloudflare-Tunnel als Persistenzmechanismus

Der Zugriff auf die N-central-Konsole ist fuer Angreifer kein Selbstzweck, sondern der Ausgangspunkt fuer die eigentliche Ausbreitung. Sicherheitsforscher, die reale Vorfaelle analysiert haben, beschreiben ein wiederkehrendes Angriffsmuster: Der Angreifer erlangt ueber den Authentication Bypass administrative Rechte auf dem N-central-Server. Von dort nutzt er die eingebaute Take-Control-Funktion - ein reguläres Feature fuer Fernzugriff auf verwaltete Endpunkte, eigentlich Support-Technikern vorbehalten - um sich mit einzelnen Windows-Endpunkten zu verbinden. Auf dem Endpunkt registriert der Angreifer den Cloudflare-Tunnel-Client (cloudflared) als Windows-Dienst.

Der letzte Schritt ist der eigentliche Trick: Ein Cloudflare Tunnel baut eine ausgehende, verschluesselte Verbindung vom Endpunkt zur Cloudflare-Infrastruktur auf. Weil die Verbindung ausgehend ist, greifen klassische eingehende Firewall-Regeln nicht - der Tunnel sieht fuer die Netzwerkueberwachung erst einmal wie gewoehnlicher HTTPS-Verkehr zu einem verbreiteten Cloud-Dienst aus. Als registrierter Windows-Dienst uebersteht der Tunnel zudem einen Neustart und bleibt bestehen, selbst wenn der Zugriff ueber den urspruenglich kompromittierten N-central-Server spaeter unterbunden wird. Fuer IT-Teams bedeutet das: Allein das Patchen von N-central reicht nicht aus, wenn bereits ein Endpunkt kompromittiert wurde - der Tunnel muss auf den betroffenen Systemen separat gefunden und entfernt werden.

Was du jetzt pruefen musst: Build-Nummern, Indikatoren, Sofortmassnahmen

Fuer Betreiber von N-central gilt eine klare Reihenfolge. Zunaechst die Version pruefen: Alle On-Premise-Installationen vor Build 2026.3.1.10 gelten als verwundbar - auch wer bereits Hotfix 1 (Build 2026.3.1.7) eingespielt hat, ist gegen CVE-2026-18577 nicht geschuetzt und muss auf Hotfix 2 aktualisieren. Gehostete (Cloud-)Instanzen wurden laut N-able bereits automatisch durch den Hersteller aktualisiert; hier ist keine Kundenaktion noetig, eine Bestaetigung im eigenen Mandantenbereich schadet aber nicht.

Zusaetzlich sollte unabhaengig vom aktuellen Patch-Stand auf Kompromittierungsindikatoren geprueft werden, falls der Server zwischen dem 1. August und dem Einspielen von Hotfix 2 ungepatcht online war: ein unerwarteter Windows-Dienst mit dem Namen "Cloudflared" oder aehnlichen Bezeichnungen auf verwalteten Endpunkten, auffaellige svchost.exe-Dateien in Benutzer- oder Dokumentenverzeichnissen statt im regulaeren Systemverzeichnis, Take-Control-Sitzungen von unbekannten IP-Adressen, zu untypischen Uhrzeiten oder ueber Konten, die diese Funktion sonst nicht nutzen - besonders kritisch bei Zugriffen auf Domaenencontroller oder andere zentrale Systeme, sowie auf N-central-Servern selbst unerklaerliche neue Administratorkonten oder Aenderungen an Zugriffsrichtlinien.

Fuer tiefergehende forensische Pruefung auf Windows-Endpunkten bieten sich das ui_access_control.log sowie die BASupSrvc_*.log.gz-Dateien im Verzeichnis C:\ProgramData\GetSupportService_N-Central\Logs\ an - ein Abgleich beider Quellen kann unautorisierte Take-Control-Aktivitaet sichtbar machen. Bei Verdacht gilt: Server isolieren, betroffene Endpunkte einzeln auf den Cloudflare-Tunnel-Dienst pruefen und erst nach Bereinigung wieder ans Netz nehmen. Ein reines Software-Update reicht bei bereits erfolgter Kompromittierung nicht aus.

Ransomware-Geruechte und was tatsaechlich bestaetigt ist

Im Umfeld der Berichterstattung kursiert auch die Behauptung, die Angriffe seien einem mutmasslich chinesischen Bedrohungsakteur zuzuordnen und dienten der Vorbereitung von Ransomware-Einsaetzen. Diese Einordnung stammt bislang aus einer einzelnen Quelle und ist weder von CISA noch von N-able offiziell bestaetigt worden. Wir behandeln sie deshalb ausdruecklich als unbestaetigtes Geruecht, nicht als gesicherte Tatsache. Was tatsaechlich belegt ist: aktive Ausnutzung seit dem 1. August, Aufnahme in den CISA-KEV-Katalog, und ein dokumentiertes Angriffsmuster ueber Take Control und Cloudflare-Tunnel. Ob und in welchem Umfang die Kampagne mit einer bestimmten Gruppierung oder mit Ransomware-Vorfaellen zusammenhaengt, ist derzeit nicht serioes zu beziffern - Vorsicht ist angebracht bei reisserischen Ueberschriften dazu, bis belastbarere Quellen vorliegen.

Einordnung: Warum unvollstaendige Patches ein wiederkehrendes Muster sind

Der Fall N-central ist kein Einzelfall. Immer wieder zeigt sich, dass ein erster Patch einen konkret beobachteten Exploit blockiert, ohne die zugrunde liegende Schwachlogik zu beheben - mit der Folge, dass Angreifer oder Sicherheitsforscher innerhalb weniger Tage einen alternativen Weg zur selben Wirkung finden. Fuer Betreiber kritischer Infrastruktur wie RMM-Plattformen bedeutet das: Ein veroeffentlichter Hotfix ist ein Anlass, wachsam zu bleiben, kein Grund zur Entwarnung. Wer auf Nummer sicher gehen will, sollte nach dem Einspielen eines sicherheitsrelevanten Patches aktiv nach Nachfolgemeldungen des Herstellers suchen, statt sich allein auf die urspruengliche Ankuendigung zu verlassen - im konkreten Fall lag zwischen Hotfix 1 und der Erkenntnis, dass er nicht ausreicht, nur ein Tag.

• FAQ:Muss ich als Endkunde eines MSP selbst etwas tun?Direkt in der Regel nicht - das Patchen von N-central liegt in der Verantwortung des MSP, der die Plattform betreibt. Sinnvoll ist trotzdem eine kurze Nachfrage beim eigenen Dienstleister, ob und wann Hotfix 2 eingespielt wurde und ob eine Pruefung auf Kompromittierungsindikatoren stattgefunden hat.Reicht der erste Hotfix (Build 2026.3.1.7) aus?Nein. Er schliesst nur den urspruenglich bekannten Pfad (CVE-2026-18556), nicht aber den alternativen Weg, der zu CVE-2026-18577 fuehrt. Erst Build 2026.3.1.10 (Hotfix 2) oder neuer gilt als vollstaendig abgesichert.Woran erkenne ich, ob mein N-central-Server bereits kompromittiert wurde?Wichtige Hinweise sind unerwartete "Cloudflared"-Dienste oder verdaechtige svchost.exe-Dateien auf verwalteten Endpunkten sowie Take-Control-Sitzungen von unbekannten IPs oder zu ungewoehnlichen Zeiten. Ein Abgleich von ui_access_control.log mit den BASupSrvc-Logdateien kann zusaetzliche Klarheit schaffen.Ist die gehostete (Cloud-)Version von N-central auch betroffen?Die Schwachstelle selbst betraf auch gehostete Instanzen, N-able hat diese aber laut eigener Angabe bereits automatisch aktualisiert. Kundenseitig ist hier keine eigene Update-Aktion noetig, eine Bestaetigung im Mandantenbereich schadet dennoch nicht.Stimmt es, dass die Angriffe mit Ransomware zusammenhaengen?Das wird berichtet, ist aber bislang nur durch eine einzelne Quelle gestuetzt und weder von CISA noch von N-able bestaetigt. Bis belastbarere Belege vorliegen, ist das als Geruecht und nicht als gesicherte Tatsache zu behandeln.
• Fazit: Der Fall zeigt exemplarisch, wie kurzlebig die Sicherheit nach einem ersten Patch sein kann: Neun Tage lagen zwischen der ersten Warnung und dem zweiten, tatsaechlich wirksamen Hotfix - Zeit, in der Angreifer nachweislich aktiv blieben. Wer N-central selbst betreibt, sollte jetzt die Build-Nummer pruefen, bei Unsicherheit nach Kompromittierungsindikatoren suchen und Update-Meldungen des Herstellers auch nach dem ersten Patch weiterverfolgen. Unbestaetigte Zuschreibungen zu bestimmten Akteuren oder Ransomware-Kampagnen sollten dabei nicht mit belegten Fakten verwechselt werden.
• Quellen: CISA - CISA Adds One Known Exploited Vulnerability to Catalog (03.08.2026), CISA - CISA Adds Three Known Exploited Vulnerabilities to Catalog (04.08.2026), N-able Status - Hotfix 1 (02.08.2026), N-able Status - Hotfix 2 (06.08.2026), Help Net Security - 03.08.2026, Help Net Security - 10.08.2026, GovInfoSecurity - unbestaetigte Einzelquelle
• Weiterführende Links: CISA Known Exploited Vulnerabilities Catalog, OWASP - Broken Access Control, N-able 2026.3 HF1 Release Notes