N-central ist offline. Woran erkennt ein MSP trotzdem, dass ein Kunde down ist?

Am Montag, dem 9. November 2026, hat N-able alle gehosteten N-central-Umgebungen in Amerika, Europa und Asien-Pazifik offline genommen. Kunden, die N-central auf eigenen Servern betreiben, sollten diese ebenfalls abschalten. Wenige Stunden zuvor hatte ein unabhängiger Forscher unter dem Namen Able2Shell Proof-of-Concept-Exploits für 33 ungepatchte Schwachstellen der Plattform veröffentlicht.

N-central ist die Plattform für Remote Monitoring and Management (RMM), mit der viele Managed Service Provider die Rechner ihrer Kunden überwachen, patchen und erreichen. Die Abschaltung war die sichere Entscheidung. Sie bedeutet aber auch: Solange N-central offline bleibt, fehlt einem MSP, der sich darauf verlässt, genau das System, das ihm melden würde, dass ein Kunde down ist. Dieser Beitrag erklärt, was passiert ist, was weiter funktioniert und was Sie einrichten sollten, das nicht zusammen mit Ihrem RMM ausfällt.

Was passierte

Die Schwachstellen sind gravierend. Die erste Kette im Write-up braucht keine Zugangsdaten: Am Ende führt sie Befehle auf dem Server aus und optional legt sie ein neues Administratorkonto an. Eine weitere braucht ebenfalls keine Zugangsdaten und erreicht Root, sobald ein Administrator eine manipulierte Patch-Seite öffnet. Weitere Schwachstellen legen Zugangsdaten offen oder erlauben es Angreifern, Dateien auf dem Server zu schreiben. Das Repository sagt nicht, ob N-able vor der Veröffentlichung informiert wurde.

Das README nennt 2026.4.0.31 einen Pre-Release-Build und sagt, die meisten Schwachstellen, “wenn nicht alle”, sollten auch in früheren Versionen funktionieren, einschließlich des aktuellen Releases. Deshalb hat N-able jeden Server als gefährdet behandelt.

N-able sieht nach eigenen Angaben Scans, die mit dem veröffentlichten Code zusammenhängen. Es gebe aber “no evidence that any customer environment has been successfully exploited”. watchTowr meldete Exploit-Versuche gegen seine N-central-Honeypots in der Nacht zum 9. November. Honeypots sind Köder. Das belegt also Versuche, keine kompromittierten Kunden.

Was weiter funktioniert

Die Statusseite von N-able listet auf, was weiter läuft. Die Cloud-Dienste hinter N-able Login (Asset View, Patching, Vulnerability Management, Scripting, Richtlinien und Tagging) bleiben für gehostete und On-Premises-Partner online. Außerdem hat N-able N-able.app, Take Control aus Asset View und Windows-Patching auf Abruf als Preview freigegeben, sodass Techniker weiterhin auf Endpunkte zugreifen und diese patchen können.

Nicht läuft N-central selbst und damit das Monitoring, das ein MSP dort aufgebaut hat: Service-Checks, Schwellenwerte, die daraus entstehenden Alerts und die Tickets, die diese Alerts öffnen. Solange der Server aus ist, erreicht ihn nichts, also schlägt auch nichts Alarm.

Der dritte N-central-Notfall seit August

• August. Angreifer nutzten ab dem 31. Juli eine Umgehung der Authentifizierung in On-Premises-N-central aus. N-able zufolge wurde eine “begrenzte” Zahl von Kunden kompromittiert. In den gemeldeten Fällen übernahmen die Angreifer ein Administratorkonto und verbanden sich über Take Control mit verwalteten Endpunkten. CISA nahm CVE-2026-18556 und CVE-2026-18577 in ihren Katalog der Known Exploited Vulnerabilities auf, mit einer Frist von drei Tagen für Bundesbehörden.
• September. N-able lieferte binnen zwei Tagen zwei Hotfixes aus, der zweite für CVE-2026-86218, eine Schwachstelle für Remote Code Execution ohne Authentifizierung mit der Bewertung 10,0. Huntress beschrieb sie als ausgenutzt. In den Release Notes von N-able hieß es, es gebe keine Bestätigung für eine Ausnutzung in Produktivsystemen.
• November. Able2Shell und eine vollständige Abschaltung von N-central.

Das ist nicht nur ein Problem von N-able. Ein RMM-Server erreicht jeden Rechner, den ein MSP verwaltet. Deshalb sind RMM-Plattformen ein Ziel für alle, die viele Netzwerke auf einmal wollen. Jeder MSP sollte damit planen, dass sein RMM ausfallen kann, egal von welchem Anbieter.

Ihr RMM ist auch Ihr Monitoring

Bei den meisten MSPs überwacht das RMM die Kunden. Agents melden an den Server, und der Server entscheidet, was einen Alert wert ist. Das funktioniert, bis der Server selbst offline gehen muss. Dann wird das Dashboard nicht rot, sondern bleibt stehen. Die Website, das VPN-Gateway oder der Mailserver eines Kunden kann während des Ausfalls ausfallen, und Sie erfahren es zuerst durch einen Anruf des Kunden.

Die Lösung ist kein zweites RMM. Es ist eine kleine Auswahl an Checks, die außerhalb Ihres Management-Stacks laufen, jeden Kunden aus Sicht des Internets prüfen und Menschen direkt alarmieren.

Was Sie außerhalb des RMM behalten sollten

1. Einen Outside-in-Check für jeden Dienst, von dem ein Kunde abhängt. Website und Portale über HTTPS, ein VPN- oder Remote-Desktop-Gateway als TCP-Port-Check, Mail-Submission auf Port 587 oder 465, die öffentliche Adresse einer Firewall mit einem Ping-Check sowie die Zertifikate und Domains davor. Diese laufen weiter, wenn Ihr RMM ausfällt, denn sie hängen nicht davon ab.
2. Mehr als einen Standort. Prüfen Sie von mindestens zwei Standorten aus und alarmieren Sie erst, wenn mehr als einer fehlschlägt. So weckt ein einzelner schlechter Netzwerkpfad niemanden um 3 Uhr nachts.
3. Heartbeats für geplante Jobs. Lassen Sie den Backup-Job jedes Kunden nach dem Ende eine Heartbeat-URL aufrufen. Kommt der Aufruf nicht rechtzeitig an, erhalten Sie einen Alert, ganz gleich, ob Ihr RMM es bemerken könnte.
4. Alerts, die direkt zu Menschen gehen. Senden Sie diese Checks an Rufbereitschafts-Handys, einen Slack- oder Teams-Kanal und Ihr Paging-Tool, nicht in eine Warteschlange, die nur Ihr RMM oder PSA liest.
5. Eine Statusseite, die Ihre Kunden finden. Bei einem Anbieterausfall wie diesem wollen Kunden wissen, ob ihre Systeme betroffen sind und was Sie dagegen tun. Mit einer Statusseite, die außerhalb Ihres Stacks gehostet wird, sagen Sie es nur einmal. Der Umgang von N-able damit ist eine gute Vorlage: ein gebündelter Beitrag, Updates mit Zeitstempel, was weiter funktioniert und was Kunden tun sollten.
6. Ein Abonnement der Statusseiten Ihrer Anbieter. Auf der Seite von N-able unter uptime.n-able.com wurde dieser Incident angekündigt, und sie hat einen Abonnieren-Button.

Was Outside-in-Checks nicht leisten

Sie sehen, was das Internet sieht. Sie melden nicht, dass eine Festplatte vollläuft, ein Patch fehlgeschlagen ist oder der Virenschutz auf einem Laptop nicht mehr läuft, und sie erreichen keinen Server, der nur im internen Netzwerk des Kunden steht. Das bleibt die Aufgabe des RMM. Für die Sicherheit tun sie ebenfalls nichts: Wenn Ihr N-central-Server exponiert war, folgen Sie den Hinweisen von N-able und suchen Sie nach Anzeichen einer Kompromittierung.

Für On-Premises-Server empfiehlt Huntress, Logins und Authentifizierungsaktivität ab dem 8. November zu prüfen und nach unbekannten Remote-Sitzungen, neu bereitgestellten Skripten und neuen Administratorkonten zu suchen. Lassen Sie den Server offline, bis N-able bestätigt, dass er sicher ist, und spielen Sie dann den Hotfix ein. Huntress weist darauf hin, dass der Hotfix die angezeigte Versionsnummer möglicherweise nicht ändert. Prüfen Sie daher in den Upgrade-Hinweisen von N-able, wie Sie die Installation bestätigen.

Wenn Sie Kunden-Websites betreuen

Mit unserem Partnerprogramm erhält jeder Ihrer Kunden ein eigenes Site Qwality-Konto: Checks im 30-Sekunden-Takt von AWS, Google Cloud und Microsoft Azure, Alerts an Slack, Teams, SMS und Ihr Paging-Tool sowie eine Statusseite auf der eigenen Domain des Kunden im Branding des Kunden. Wir rechnen alles einmal im Monat gesammelt mit Ihnen ab, und nichts davon läuft über Ihr RMM.

Quellen

• Statusseite von N-able: N-central Critical Security Incident (Incident 202580, eröffnet am 9. November 2026; gelesen am 10. November 2026, 19:22 UTC)
• Sean Bales: Able2Shell, N-Central N-Able (GitHub, committet am 9. November 2026)
• Huntress: N-able disables cloud services following disclosure of “Able2Shell” exploit chains (9. November 2026)
• The Hacker News: N-able takes N-central cloud offline after researcher discloses 33 zero-days with PoC exploits (10. November 2026)
• Help Net Security: Attackers exploit N-able N-central flaw to reach managed endpoints (CVE-2026-18577) (3. August 2026)
• The Register: Feds get 3 days to patch N-able flaw under active exploit (4. August 2026)
• Huntress: Kritische Schwachstelle in N-able N-central und aktive Ausnutzung