Am späten Abend des Sonntag, 8. November, veröffentlichte der Sicherheitsforscher Sean Bales ein GitHub-Repository namens Able2Shell. Darin: Proof-of-Concept-Exploits für mehr als dreißig angebliche Zero-Day-Schwachstellen in N-central, der Remote-Monitoring-and-Management-Plattform (RMM), mit der MSPs und IT-Teams die Laptops, Server und Netze anderer Leute betreiben.
Am Montagnachmittag hatte N-able seine gehosteten N-central-Umgebungen in Amerika, Europa und Asien-Pazifik abgeschaltet. On-Premises-Kunden sollten ihre Server „bis auf Weiteres“ herunterfahren. Ein Hersteller mit Tausenden Partnern und Hunderttausenden Endpunkten entschied sich für Ausfall statt Exposition.
Das ist kein normaler Montag. Das ist eine aufgebrochene Haustür, während der Schlüsseldienst noch die Anleitung liest.
Was da konkret veröffentlicht wurde
Das Repository zielt auf N-central Appliance 2026.4.0.31, einen Vorab-Build, und Bales geht davon aus, dass die meisten, wenn nicht alle Fehler auch ältere Versionen betreffen. Schon die Kategorien zeigen die Tiefe:
- Umgehung der Authentifizierung
- Offenlegung von Zugangsdaten
- Beliebiges Schreiben von Dateien und Directory Traversal
- Cross-Site-Scripting (XSS), das als root ausgeführt werden kann, wenn ein Administrator manipulierte Patch-Metadaten öffnet
- XML-External-Entity-(XXE-)Injection
- Remote Code Execution (RCE)
- Eine lokale Rechteausweitung, die Code des Dienstbenutzers
nablebis root bringt
Am schlimmsten ist eine Kette. Ein unauthentifiziertes XXE in der Service-Import-Funktion erlaubt es, eine vertrauenswürdige lokale Sitzung zu stehlen, ein Kontopasswort zurückzusetzen und Befehle als nable auszuführen. Dieselbe Kette kann ein aktives Default-Administrator-Konto mit Angreifer-Zugangsdaten anlegen: Ein Fremder besitzt plötzlich die Konsole, die deinen gesamten Bestand verwaltet. Bales stellte ein Video des kompletten Angriffs online, Terminalausgabe inklusive.
N-able erklärt, man habe keine aktive Ausnutzung und keinen unbefugten Datenzugriff festgestellt, ein Hotfix sei in Entwicklung und Validierung. Updates sollen alle vier Stunden kommen. Ecoverse-Dienste hinter N-able Login blieben erreichbar. Alles andere ging dunkel.
Ein Detail, das man sacken lassen sollte: Bales bestätigte gegenüber BleepingComputer, dass die Entdeckung KI-gestützt war. Über dreißig Lücken in einer Enterprise-Appliance, in einem einzigen Research-Zyklus. Das ist der neue Maßstab.
Warum er es tat – und warum das mehr zählt als die Bugs
Bales sagt, er habe die koordinierte Offenlegung bewusst übersprungen. Grund: Er hatte rund fünf bis sechs Monate zuvor zwei unabhängige RCEs in einem anderen N-able-Produkt gemeldet, dazu eine Rechteausweitung. Diese seien bis heute ungepatcht. Follow-up-Mails über vier bis sechs Wochen seien unbeantwortet geblieben. Ein Bug-Bounty-Honorar habe er nie erhalten. Nach der Veröffentlichung meldeten sich CEO und CTO von N-able und baten ihn, das Repository zu entfernen und mitzuarbeiten – ohne Drohungen.
N-ables Antwort auf Fragen zu diesen früheren Meldungen: keine.
Ist es also ein rücksichtsloser Forscher, der an einem Montag lebende Exploits veröffentlicht, oder ein Disclosure-Prozess, der so wirkungslos ist, dass Publizität der einzige Hebel war? Beides kann stimmen. Die unbequeme Lehre: Der einzige Druck, der diesen Hersteller bewegt hat, war öffentliche Blamage plus ein weltweiter Ausfall.
Und es gibt einen echten Preis. Irgendwo arbeitet diese Woche ein MSP-Techniker in einer 40-Personen-Praxis ohne Konsole. Dreißig ungepatchte Exploits zu veröffentlichen bringt normale Nutzer in Gefahr.
Das RMM-Problem, das niemand auf die Folie drucken will
RMM ist per Design die privilegierteste Software im Haus: Agenten auf jedem Endpunkt, Zugangsdaten für jede Kundenumgebung, Remote-Shell, Patch-Verteilung, Skriptausführung. Das Geschäftsmodell heißt „eine Konsole, hunderte Organisationen“. Das Sicherheitsmodell heißt oft „vertrau uns“.
Deshalb ist es ein Ziel, das Geld druckt:
- Ein Login, hunderte Tenants. Wer die RMM übernimmt, erbt jede Kundenbeziehung dahinter.
- Remote-Ausführung inklusive. Laterale Bewegung muss man nicht suchen, sie ist Feature.
- Signierte Agenten überall. Endpoint-Schutz winkt den Traffic durch, weil er von der Management-Plattform kommt.
- Verzögertes Patchen. Eine Appliance ist eine Appliance. Niemand patcht sie dienstagnachts wie einen Webserver.
Was in den nächsten 72 Stunden zu tun ist
- Erst Inventar. Welche N-central-Instanzen besitzt oder erbst du über einen Partner, und welche Endpunkte sind noch registriert? Man kann nicht abschalten, was man nicht findet.
- Isolieren. Gehostete Umgebungen sind bereits offline. On-Premises: herunterfahren wie angewiesen – oder, falls nicht möglich, eingehenden Zugriff auf bekannte Management-IPs begrenzen und externe Exposition sofort beenden.
- Davon ausgehen, dass die Zugangsdaten verbrannt sind. Alles rotieren, was die Plattform gespeichert hat: Deployment-Zugangsdaten, Dienstkonten, API-Token, delegierte Microsoft-365- und Google-Workspace-Verbindungen, SNMP-Strings, Backup-Zugangsdaten.
- Nach Spuren der Kette suchen. Neue lokale Administratoren, ein aktives Default-Administrator-Konto, ausgehende Verbindungen des
nable-Benutzers, unerwartete Passwort-Resets, Service-Import-Aufrufe, die niemand gemacht hat. - EDR auf Kindprozesse des RMM-Agenten prüfen. Alles, was von dort Shells oder Packprogramme startet, verdient diese Woche einen Blick.
- Den Restore-Pfad testen, bevor man ihn braucht. Ein Hotfix kommt. Der Rollback-Plan darf nicht „sehen wir dann“ heißen.
- Das erwartete Disclosure-SLA aufschreiben. Und jeden RMM-Hersteller bitten, das seine schriftlich zu nennen – inklusive Bounty-Bedingungen und Antwortzeiten.
Der Golf-Winkel
Für Kunden in Dubai und der weiteren Golfregion landet das an einer konkreten Stelle. Outsourced IT ist im Mittelstand hier Standard, und ein großer Teil davon läuft über genau diese Werkzeugklasse. Wer reguliert ist, für den ist die Patch-Latenz des Dienstleisters jetzt Aufsichtsrisiko, keine Fußnote. Regulierer fragen dasselbe: Wer kann Code in deiner Umgebung ausführen, und woher weißt du das?
Die ehrliche Antwort lautet meist: „unser MSP, über eine Konsole, die wir nie geprüft haben“. Das muss vor dem nächsten Vorfall aktualisiert werden, nicht danach.
Das Fazit
N-central kommt zurück, vermutlich in Tagen. Ein Hotfix erscheint, Partner patchen, die Nachrichtenlage zieht weiter.
Die Lehre, die die Woche überlebt, ist kleiner und härter: Deine Vertrauensgrenze ist eine Liste von Vendor-Berechtigungen, und diese Liste ist länger als dein Organigramm. Ein RMM-Ausfall nervt für einen Tag. Eine kompromittierte RMM ist jeder Kunde, den du hast – in einem Browser-Tab eines Angreifers.