CVE-2026-86218: N-able N-central Pre-Auth RCE (CVSS 10.0) ausgenutzt

Diese Woche in unserer InSEKurity of the Week-Reihe: eine Schwachstelle, die technisch elegant, operativ katastrophal und — wenn Sie ein Managed Service Provider oder Kunde eines solchen sind — persönlich relevant ist. Am 6. September 2026 veröffentlichte N-able N-central 2026.3 Hotfix 4 für CVE-2026-86218: eine Pre-Authentication Remote Code Execution in der N-central-Management-Konsole, bewertet mit CVSS 4.0 10.0 und klassifiziert als CWE-96 Static Code Injection. Zwei Tage später, am 8. September, nahm CISA die Schwachstelle in den Known Exploited Vulnerabilities-Katalog auf, mit Frist zum 11. September — ein Drei-Tage-Fenster, was CISAs Art ist zu sagen: das passiert gerade schon jemandem.

Und tatsächlich passierte es bereits. N-ables öffentliches Advisory erklärte, es gebe “no confirmations that this vulnerability has been exploited in production environments”. Die Benachrichtigung an die Kunden bezeichnete dieselbe Lücke als Zero-Day, der “has been observed being exploited in the wild”. Huntress erfuhr von der Schwachstelle nicht aus einem Advisory, sondern aus einem Discord-Post eines N-able-Mitarbeiters in der MSPGeek-Community — und bearbeitete seit Anfang August bereits N-central-bezogene Vorfälle. watchTowr reproduzierte die Schwachstelle unabhängig. Bis zum 14. September hatte Stephen Fewer von Rapid7 ein funktionsfähiges Metasploit-Modul veröffentlicht.

Warum die CVSS 10.0 den Sachverhalt noch untertreibt: N-central ist keine Anwendung. Es ist eine RMM-Plattform — Remote Monitoring and Management — und ihr gesamter Zweck besteht darin, privilegierte, dauerhafte, skriptgesteuerte Kontrolle über jeden Endpunkt zu halten, den ein Managed Service Provider betreut. Ein einzelner N-central-Server steuert routinemäßig Tausende von Arbeitsplätzen, Servern und Domain Controllern über Dutzende voneinander unabhängiger Kundenorganisationen hinweg. Ihn zu kompromittieren ist kein Fußabdruck im Netzwerk. Es ist ein legitimer, vollständig autorisierter administrativer Kanal in jedes nachgelagerte Netzwerk gleichzeitig — über genau den Mechanismus, dem diese Netzwerke per Konstruktion vertrauen.

Die Shadowserver Foundation zählte rund 1.500 aus dem Internet erreichbare N-central-Server, konzentriert in den USA und Europa.

🚨 Zusammenfassung

CVE-ID: CVE-2026-86218
CVSS-4.0-Score: 10.0 Kritisch (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H)
CWE: CWE-96: Improper Neutralization of Directives in Statically Saved Code (“Static Code Injection”)
Betroffene Software: N-able N-central, alle Builds vor 2026.3.1.14
Nicht betroffen: N-able Cloud / NCOD (gehostete Instanzen) — diese hat N-able selbst gepatcht. Selbst betriebene On-Premises-Installationen liegen in der Verantwortung des Kunden. Agents und Probes benötigen kein Update; es handelt sich um einen serverseitigen Fix
Angriffsvektor: Netzwerk — überall dort, wo die N-central-Web-Konsole antwortet
Authentifizierung erforderlich: Keine. Die betroffene Struts-Action ist per Design unauthentifiziert
Ursache: Eine session-scoped Struts-Form auf einer unauthentifizierten Action. Zwei gleichzeitige Multipart-Requests gewinnen ein Race gegen den Multipart-Handler der Form und legen Jettys laufende Konfigurationsobjekte für die Property-Befüllung durch Apache Commons BeanUtils offen — der Angreifer schreibt damit den laufenden Servlet-Container um
Auswirkung: Beliebige OS-Kommandoausführung als Service-Konto nable, anschließend administrative Kontrolle über N-central — und damit skriptgesteuerte Codeausführung auf jedem verwalteten Endpunkt
Patch-Status: Verfügbar seit 2026-09-06 — behoben in 2026.3.1.14 (2026.3 Hotfix 4)
Ausnutzungsstatus: Aktiv ausgenutzt, bereits vor der öffentlichen Offenlegung. Von watchTowr reproduziert; ein öffentliches Metasploit-Modul folgte binnen Tagen
CISA KEV: Gelistet — aufgenommen 2026-09-08, Frist 2026-09-11 gemäß BOD 26-04, Ransomware-Nutzung als Unknown erfasst
Begleitende CVEs: CVE-2026-86206 (CVSS 6.9) und CVE-2026-86207 (CVSS 7.7), einen Tag zuvor in Hotfix 3 behoben, verkettbar zu einem Authentifizierungs-Bypass mit Anlage angreiferkontrollierter Admin-Konten
Was dabei gerne übersehen wird: Der Exploit verändert die laufende Jetty-Konfiguration im Arbeitsspeicher. Der eingeschleuste Kommando-Endpunkt überlebt, bis N-central neu gestartet wird — ein Patch ohne Neustart entfernt einen bereits vorhandenen Endpunkt nicht

🖥️ Was ist N-able N-central?

N-able N-central ist eine Remote-Monitoring-and-Management-Plattform (RMM). Es ist die Software, die ein Managed Service Provider betreibt, um die IT anderer Unternehmen zu betreiben: Sie inventarisiert Endpunkte, überwacht sie, patcht sie, alarmiert über sie, führt Skripte auf ihnen aus und öffnet Fernwartungssitzungen in sie hinein. Agents und Probes, die über Kundennetzwerke verteilt installiert sind, melden sich bei einem zentralen N-central-Server — und dieser Server sagt ihnen, was zu tun ist.

N-central ist als gehosteter Dienst (N-able Cloud on Demand) verfügbar und — für diese Schwachstelle entscheidend — als On-Premises-Appliance, die MSPs selbst betreiben. Sehr häufig mit einer direkt ins Internet veröffentlichten Web-Konsole, weil Techniker, Remote-Mitarbeitende und Probes an Kundenstandorten sie alle erreichen müssen.

Drei Eigenschaften von N-central machen aus einer Server-Kompromittierung einen organisationsübergreifenden Vorfall:

Es hat einen Agent auf allem. Der Agent läuft auf verwalteten Endpunkten mit SYSTEM- oder Root-Rechten, weil Patching und Remediation genau das erfordern. Die Skripting-Engine von N-central kann beliebige Kommandos an jede beliebige Teilmenge dieser Endpunkte ausrollen.
Es ist per Design mandantenfähig. Der N-central-Server eines MSP enthält die Kundenliste, die Zugangsdaten, die Netzwerktopologie und die Fernzugriffswege für jeden Kunden, den dieser MSP betreut. Die Mandantengrenze wird innerhalb der kompromittierten Anwendung durchgesetzt.
Seine Aktivität ist von legitimer Arbeit nicht zu unterscheiden. Ein von N-central an 400 Endpunkte verteiltes Skript sieht exakt wie Wartung aus — weil es normalerweise Wartung ist. Kein auffälliger Prozess, keine unsignierte Binärdatei, kein ungewöhnlicher Netzwerkpfad: Das vorgesehene Werkzeug wird wie vorgesehen benutzt, nur von der falschen Person.

Genau deshalb sind RMM-Plattformen seit dem Kaseya-VSA-Vorfall von 2021 ein Dauerziel. Die Management-Ebene zu übernehmen ist billiger, als tausend Endpunkte zu übernehmen — und liefert dasselbe Ergebnis.

Typische Einsatzszenarien

Endpunkt-Monitoring und Alarmierung über viele Kundenmandanten hinweg aus einer Konsole
Patch-Management für Windows, macOS, Linux und Drittanbieteranwendungen
Automatisierung und Skripting — geplante oder Ad-hoc-Kommandoausführung auf verwalteten Geräten
Fernwartung (Take Control / MSP-Support-Sitzungen) in Server, Arbeitsplätze und Domain Controller
Asset- und Inventar-Reporting für Kundenlandschaften
Orchestrierung von Backup, AV und EDR über integrierte Drittanbieter-Werkzeuge
Ticketing- und PSA-Integration als Grundlage für Abrechnung und Service-Workflow des MSP

🔍 Technische Analyse

Beschreibung der Schwachstelle

CVE-2026-86218 ist eine unauthentifizierte Remote Code Execution in der N-central-Web-Konsole. Das Frontend von N-central ist eine Java-Anwendung auf Basis von Apache Struts, ausgeliefert von Jetty und vorgelagert durch einen Envoy-Proxy. Die Schwachstelle liegt darin, wie Struts Form-Beans aus Request-Parametern befüllt — ein Mechanismus mit langer und unglücklicher Sicherheitshistorie.

Struts bildet eingehende Request-Parameter automatisch auf die Properties eines ActionForm-Objekts ab und verwendet dafür Apache Commons BeanUtils. BeanUtils unterstützt verschachtelte Property-Ausdrücke: Ein Parameter namens foo.bar.baz setzt nicht einfach ein Feld dieses Namens, sondern läuft durch den Objektgraphen — getFoo().getBar().setBaz(...). Solange dieser Durchlauf innerhalb des Form-Objekts bleibt, ist das bequem. Sobald er das Form-Objekt verlassen und die Objekte erreichen kann, aus denen der Server selbst besteht, wird daraus beliebige Umkonfiguration eines laufenden Applikationsservers. Es ist dieselbe Fehlerklasse wie die Struts-ClassLoader-Manipulation von 2014 — hier taucht sie gegen Jetty statt gegen Tomcat wieder auf.

Der Ausbruchsmechanismus in N-central ist ein Race Condition. Die betroffene Struts-Action ist session-scoped und unauthentifiziert — remoteControlAction.do, erreichbar ohne Zugangsdaten. Weil das Form-Bean in der Session statt pro Request gehalten wird, teilen sich zwei gleichzeitige Multipart-Requests dasselbe Bean. Gewinnt man das Race gegen den Multipart-Handler der Form, bleibt das Bean in einem Zustand zurück, in dem die BeanUtils-Property-Befüllung nicht länger auf die Form beschränkt ist: Sie erreicht Jettys laufende Konfiguration — den In-Memory-Objektgraphen, der den Servlet-Container beschreibt, der den Request gerade bedient.

Von dort braucht der Angreifer weder ein Memory-Corruption-Primitive noch eine Deserialisierungs-Gadget-Chain. Er konfiguriert schlicht den Webserver um.

Ursachenanalyse

Eine session-scoped ActionForm auf einer unauthentifizierten Action. Struts-Form-Beans sind normalerweise request-scoped. Session-Scope bedeutet, dass das Bean einen einzelnen Request überlebt und zwischen gleichzeitigen Requests derselben Session geteilt wird — und da die Action keine Authentifizierung verlangt, kann ein Angreifer diese Session beliebig anlegen.
Ein nicht thread-sicherer Multipart-Handler. Die Multipart-Verarbeitung der Form geht von genau einem Request zur Zeit aus. Zwei überlappende Multipart-POSTs versetzen sie in einen Zustand, den ihr Autor nie vorgesehen hat.
Unbeschränkte verschachtelte Property-Befüllung über Commons BeanUtils. Struts reicht angreiferkontrollierte Parameternamen an den Nested-Property-Resolver von BeanUtils weiter. Mit dem Form-Bean im geraceten Zustand lösen diese Namen gegen Objekte außerhalb der Form auf — darunter Jettys eigene Konfiguration.
Keine Allow-Liste für Property-Pfade. Das Framework schränkt nicht ein, welche Properties ein Request adressieren darf. Diese Fehlerklasse zu entschärfen erfordert eine explizite Ausschlussliste (class, classLoader, Container-Interna); N-central hatte keine, die diesen Pfad abdeckte.
Lebende, veränderbare Container-Konfiguration. Jettys ServletHolder-Objekte — die Bindungen zwischen URL-Pfaden und den Servlet-Klassen, die sie bedienen — sind gewöhnliche veränderbare Java-Beans im Arbeitsspeicher. Wer ihre Properties setzen kann, kann zur Laufzeit ändern, welche Klasse eine URL beantwortet.
Ein CGI-Servlet im Classpath. Jetty liefert ein CGI-Servlet mit, das für Requests auf sein Mapping ein externes Programm ausführt. Es ist nicht standardmäßig aktiviert — aber es ist vorhanden, und wer Properties auf einem Servlet-Holder setzen kann, kann ihn dorthin zeigen lassen und so konfigurieren, dass er /bin/sh aufruft.

Angriffsvektor

Das öffentliche Metasploit-Modul zielt auf einen von drei verzögert initialisierten Servlet-Holdern — LogRetrieval (Standard), FileTransfer oder AutomationManagerDownloadServlet. Die verzögerte Initialisierung ist entscheidend: Diese Holder existieren in der Konfiguration, haben ihre Servlet-Klasse aber noch nicht instanziiert, sodass ihre Properties vor der ersten Nutzung noch überschrieben werden können.

Der Ablauf von Anfang bis Ende:

+---------------------------------------------------------------+
|  ILLUSTRATIVES ABLAUFDIAGRAMM -- kein funktionsfaehiger Exploit |
+---------------------------------------------------------------+

   Angreifer                     Envoy -> Jetty -> Struts
      |                                    |
      | (1) GET  /remoteControlAction.do   |
      |----------------------------------->|   Session angelegt,
      |                                    |   session-scoped Form-Bean
      |                                    |   alloziert
      |                                    |
      | (2) POST multipart  --------\      |
      |     POST multipart  --------/      |   zwei gleichzeitige Multipart-
      |     (gleiche Session, ~0.35s)      |   Requests racen den Multipart-
      |----------------------------------->|   Handler der Form
      |                                    |
      |                                    |   Form-Bean verlaesst seinen
      |                                    |   Scope; BeanUtils-Property-
      |                                    |   Befuellung erreicht nun
      |                                    |   Jettys laufende Konfiguration
      |                                    |
      | (3) Property-Schreibzugriffe auf   |
      |     den LogRetrieval-ServletHolder:|
      |       gehaltene Klasse -> Jetty CGI|
      |       Kommando         -> /bin/sh  |
      |----------------------------------->|
      |                                    |
      | (4) GET /LogRetrieval?<Kommando>   |
      |----------------------------------->|   Jetty-CGI-Servlet fuehrt das
      |<-----------------------------------|   Kommando als 'nable' aus
      |     Kommando-Ausgabe               |
      |                                    |
      +-- Endpunkt bleibt feindlich bis zum Neustart von N-central --+

Schritt 1 — die unauthentifizierte Action erreichen. remoteControlAction.do antwortet ohne Zugangsdaten. Aufklärung gegen diesen Endpunkt wurde bereits vor der Offenlegung beobachtet; Huntress registrierte Angreifer, die /remoteControlAction.do?method=getPierDetails abfragten.

Schritt 2 — das Race gewinnen. Zwei Multipart-POSTs auf dieselbe Session, Sekundenbruchteile auseinander. Der Standardabstand im Metasploit-Modul beträgt 0,35 Sekunden — so abgestimmt, dass der zweite Request eintrifft, während der erste noch im Multipart-Handler steckt. Geht das Race verloren, liefert der Server einen Fehler und der Angreifer versucht es einfach erneut: Es gibt keine Sperre, kein Rate-Limit und keinerlei Kosten für einen Fehlversuch.

Schritt 3 — den Servlet-Holder umschreiben. Da die Property-Befüllung nun Jettys Konfiguration adressiert, setzt der Angreifer die gehaltene Klasse eines verzögert initialisierten Servlet-Holders auf Jettys mitgeliefertes CGI-Servlet und konfiguriert es so, dass es /bin/sh aufruft.

Schritt 4 — ausführen. Ein schlichter HTTP-Request auf den umgeschriebenen Pfad ist jetzt eine Shell. Kommandos laufen unter dem Service-Konto nable — der Identität, unter der N-centrals eigene Anwendung läuft, und damit der Identität, der die N-central-Datenbank, ihre Zugangsdaten und ihr Kommandokanal zu jedem Agent gehören.

Die folgende Skizze zeigt die Form der Schritte 2-3. Sie ist bewusst unvollständig und funktioniert nicht:

# ---------------------------------------------------------------------
# NUR ILLUSTRATIV -- Struktur des Race, KEIN funktionsfaehiger Exploit.
# Parameternamen und Payload-Inhalte sind absichtlich ausgelassen.
# ---------------------------------------------------------------------

# Request A und Request B werden gleichzeitig auf derselben JSESSIONID gesendet.

POST /remoteControlAction.do HTTP/1.1
Host: ncentral.example.com
Cookie: JSESSIONID=<in Schritt 1 aufgebaute Session>
Content-Type: multipart/form-data; boundary=----boundary
Content-Length: <n>

------boundary
Content-Disposition: form-data; name="<verschachtelter Property-Pfad ausgelassen>"

<Wert ausgelassen>
------boundary--

Die Authentifizierungs-Bypass-Hälfte der Geschichte ist dagegen vollständig öffentlich, weil Rapid7 sie publiziert hat. CVE-2026-86206 nutzt eine dreifache Uneinigkeit darüber aus, was ein Request-Pfad eigentlich ist:

# Reproduziert aus Rapid7s veroeffentlichter Analyse zu CVE-2026-86206
# (behoben in 2026.3.1.13). Gezeigt, um die Fehlerklasse "Parser-Confusion"
# zu erklaeren -- nur gegen Systeme einsetzen, fuer die Sie autorisiert sind.
#
#   Envoy      sieht  /dms;/services/ServerUI  -> trifft seine Blockregeln
#                     fuer /dms/services nicht und leitet weiter
#   Jetty      behandelt ";..." als Path-Parameter und entfernt es, dispatcht
#                     also auf /dms/services/ServerUI -> das SOAP-Servlet
#   N-central  prueft den Forwarded-Header, um lokale Aufrufer zu erkennen;
#                     der fehlerhafte Wert laesst LocalHostUtils.xffCheck()
#                     fail-open laufen und true zurueckgeben

POST /dms;/services/ServerUI HTTP/1.1
Host: ncentral.example.com
Forwarded: for="127.0.0.\1"
Content-Type: text/xml; charset=utf-8
SOAPAction: ""

CVE-2026-86207 erledigt dann den Rest: UserTwoFactorLogin in com.nable.server.ui bindet eine Benutzer-ID an die Session, bevor die Legacy-Zwei-Faktor-Authentifizierung überhaupt versucht wird. Eingebaute Konten — ID 1 (N-able Administrator), ID 50 (Product Administrator), ID 51 (N-able Support) — besitzen kein Legacy-2FA-Profil, sodass ein Aufruf der Methode mit einem Dummy-Passwort eine Exception auslöst. Die Exception bricht die Authentifizierung ab, lässt die Session aber an den privilegierten Benutzer gebunden zurück. Nachfolgende SOAP-Aufrufe an ServerUI2 legen angreiferkontrollierte System-Administratorkonten an.

Verkettet liefern CVE-2026-86206 + CVE-2026-86207 einem Angreifer ein Admin-Konto in der Konsole. CVE-2026-86218 liefert ihm das darunterliegende Betriebssystem. Beide wurden innerhalb von 24 Stunden gepatcht — und ein Angreifer in freier Wildbahn hatte Anfang September Zugriff auf beide.

Ausnutzung in freier Wildbahn

Die Abfolge von August bis September ist der entscheidende Kontext. Das war keine einzelne schlechte Woche, sondern vier Notfall-Hotfixes in fünf Wochen:

1.-2. August 2026 — N-able legt die Authentifizierungs-Bypässe CVE-2026-18556 und CVE-2026-18577 offen. Huntress registriert am 1. August Angriffsaktivität von 173.249.252.200, 87.249.138.34, 37.19.210.32, 68.235.46.214 und am 2. August von 37.153.90.88, 92.118.112.181.
2. August — Hotfix 1 (2026.3.1.7).
6. August — Hotfix 2 (2026.3.1.10). Weitere Angreiferinfrastruktur beobachtet: 173.249.252.176, 185.156.46.150, 23.234.94.43, 68.235.46.235.
4. September — Huntress legt eine Kundenkompromittierung offen. Die konkret genutzte CVE ließ sich nicht bestätigen, weil das Logging nicht ausreichte, um es zu belegen.
5. September — Hotfix 3 (2026.3.1.13) für CVE-2026-86206 und CVE-2026-86207, gemeldet von Stephen Fewer (Rapid7) und von Huntress. Am selben Tag Aktivität von 23.234.100.105 und 23.234.97.68 (Tzulo-VPN-Infrastruktur).
6. September — Hotfix 4 (2026.3.1.14) für CVE-2026-86218, offengelegt als Zero-Day.
8. September — CISA KEV, Frist 11. September. Rapid7 veröffentlicht seine technische Analyse der Auth-Bypass-Kette.
9. September — bestätigte Ausnutzung gegen Kunden gemeldet.
14. September — öffentliches Metasploit-Modul für CVE-2026-86218, getestet gegen 2025.4.1.2 und 2026.3.1.13, wobei 2026.3.1.14 den Exploit nachweislich bricht.

N-able benannte zusätzlich 23.234.64.0/18 als Quelle von Scanning-Aktivität gegen N-central-Instanzen — bemerkenswert: Drei der oben genannten Huntress-IoC-Adressen liegen innerhalb dieses Bereichs.

Nach der Kompromittierung beobachtete Huntress, wie Angreifer N-central exakt so nutzten, wie es ein Administrator täte:

Ausführung von Skripten auf verwalteten Endpunkten über N-centrals eigene Automatisierungs-Engine
Ausrollen von Cloudflare-Tunneln zur Persistenz (Account-Tag 5568cd69c754b392121f1dbb8f900fda)
Öffnen von Fernwartungssitzungen in Domain Controller
Anlage von Administratorkonten mit E-Mail-Adressen in der reservierten TLD .invalid sowie von Konten mit Zeichenvertauschungen, die einen flüchtigen Blick auf die Benutzerliste überstehen sollen

Zur Angreiferinfrastruktur gehörten die Domains mousears.synology[.]me, wagoosh.direct.quickconnect[.]to und who-ripped-one.direct.quickconnect[.]to — Synology-QuickConnect-Hostnamen, eine bemerkenswert günstige Möglichkeit, einen C2-Endpunkt zu betreiben, der auf etwas Harmloses auflöst.

Auswirkungen nach erfolgreicher Ausnutzung

Kommandoausführung als nable auf dem N-central-Server — dem Konto, dem die Anwendung, ihre Konfiguration und ihr Datenbankzugriff gehören.
Vollständiger Lesezugriff auf die N-central-Datenbank: Kundenmandanten, Geräteinventare, hinterlegte Zugangsdaten, Integrations-Secrets und die Topologie jedes verwalteten Netzwerks.
Administrative Konten in der Konsole, angelegt entweder über die RCE oder über die Kette CVE-2026-86206/86207 — Persistenz, die den Fix auf Betriebssystemebene überlebt und wie ein legitimer Benutzer aussieht.
Beliebige Skriptausführung auf jedem verwalteten Endpunkt, mit SYSTEM- oder Root-Rechten, über den dafür vorgesehenen Automatisierungsmechanismus.
Interaktive Fernwartung in jede verwaltete Maschine, einschließlich Domain Controller — womit eine RMM-Kompromittierung zur Active-Directory-Kompromittierung mehrerer voneinander unabhängiger Kunden wird.
Zusammenbruch der Mandantengrenze. Jeder Kunde dieses MSP ist aus derselben Konsole erreichbar, und die Trennung zwischen ihnen wird von der Anwendung durchgesetzt, die der Angreifer nun kontrolliert.
Persistenz im Arbeitsspeicher. Der umgeschriebene Servlet-Holder ist eine lebende Konfigurationsänderung, keine Datei auf der Platte. Es gibt keine abgelegte Binärdatei zu finden — und die Änderung besteht fort, bis N-central neu gestartet wird.
Ein vertrauenswürdiger Ausrollkanal für Ransomware. Das ist das Kaseya-VSA-Muster: Der schnellste Weg zu gleichzeitiger Verschlüsselung in vielen Organisationen ist das Werkzeug, dem sie alle zu vertrauen beschlossen haben.

📊 Impact-Bewertung

Unmittelbare Auswirkungen

Unauthentifizierte RCE auf jedem aus dem Internet erreichbaren N-central-Server unterhalb von 2026.3.1.14
Rund 1.500 im Internet exponierte N-central-Server laut Shadowserver, überwiegend USA und Europa
Ein öffentliches Metasploit-Modul, das die erforderliche Qualifikation von “Sicherheitsforscher” auf “check eintippen” senkt
Bestätigte Ausnutzung in freier Wildbahn, bevor der Patch existierte — ein echter Zero-Day, kein Wettlauf gegen die Patch-Lücke
Mandantenübergreifender Wirkungsradius: Ein einziger kompromittierter Server exponiert jeden Kunden dieses MSP
Forensische Schwierigkeiten: Mindestens ein bestätigtes Opfer konnte den Einstiegsvektor nicht ermitteln, weil das Logging unzureichend war

Betroffene Versionen

Version / Build	Status
Alle N-central-Builds vor 2026.3.1.14	Verwundbar
2026.3.1.7 (Hotfix 1, 2. Aug.)	Verwundbar
2026.3.1.10 (Hotfix 2, 6. Aug.)	Verwundbar
2026.3.1.13 (Hotfix 3, 5. Sep.)	Verwundbar — behebt nur CVE-2026-86206/86207
2026.3.1.14 (Hotfix 4, 6. Sep.)	Behoben
N-able Cloud / NCOD (gehostet)	Von N-able gepatcht — kein Kundenhandeln nötig
Agents und Probes	Nicht betroffen — kein Agent-Update erforderlich

Direkte Upgrade-Pfade auf 2026.3.1.14 existieren von 2025.4, 2026.1, 2026.2, 2026.3 und jedem 2026.3-Hotfix aus. Hotfix 3 reicht nicht — HF3 liegt einen Tag vor CVE-2026-86218.

Betroffene Umgebungen

Managed Service Provider mit selbst betriebenem N-central — das ist die gesamte Risikopopulation
MSPs, deren Konsole im Internet veröffentlicht ist — die betriebliche Standardhaltung, weil Remote-Techniker und Probes an Kundenstandorten sie erreichen müssen
Jeder Kunde jedes solchen MSP, der weder Einblick in den Patch-Stand der Konsole hat noch eine Möglichkeit, ihn zu überprüfen
Organisationen, die N-central intern für die eigene Mehrstandort-Landschaft betreiben
Umgebungen, in denen N-central-Agents Domain Controller erreichen — also praktisch alle

Angreiferprofile

Ransomware-Affiliates, für die eine RMM-Konsole der ideale Ausrollmechanismus ist: privilegiert, vorinstalliert und von EDR als vertrauenswürdig eingestuft
Access Broker, die einen einzelnen N-central-Zugang als N separate Unternehmenszugänge verkaufen können
Opportunistische Massenscanner, nun ausgestattet mit einem Metasploit-Modul und einer Zielliste von rund 1.500 Hosts
Staatsnahe Akteure, für die ein MSP ein Supply-Chain-Weg zu konkreten nachgelagerten Zielen ist, die einzeln schwerer zu erreichen wären

🛡️ Gegenmaßnahmen

Sofortmaßnahmen (Priorität 1)

1. Build feststellen, dann auf 2026.3.1.14 aktualisieren.

Der installierte Build wird in der N-central-Konsole unter System Settings > N-central Server > Version Management angezeigt — dort werden auch System-Upgrades installiert. Diese Ansicht ist auf System- oder Product-Administrator-Konten beschränkt. Alles unterhalb von 2026.3.1.14 ist verwundbar.

2. Feststellen, ob die Konsole aus dem Internet erreichbar ist.

# Den HTTP-Status der Konsole von AUSSERHALB des eigenen Netzwerks abfragen
# (von einem externen Host ausfuehren, nicht aus dem Management-LAN).
# Jede 200/302 bedeutet: Ein unauthentifizierter Angreifer erreicht die Action.
curl -sk -o /dev/null -w '%{http_code}\n' https://ncentral.example.com/

3. Zugriff auf die Konsole während des Patchens einschränken.

# HTTPS zur N-central-Konsole nur aus dem Management-Netz zulassen,
# alles Uebrige verwerfen. 10.10.0.0/24 an das eigene Netz anpassen.
sudo iptables -A INPUT -p tcp --dport 443 -s 10.10.0.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j DROP

# nftables-Aequivalent fuer Hosts, die nft statt iptables verwenden.
# Setzt voraus, dass die Standardtabelle "inet filter" mit Chain "input"
# bereits existiert (nft list ruleset zeigt es); andernfalls zuerst anlegen.
sudo nft add rule inet filter input tcp dport 443 ip saddr 10.10.0.0/24 accept
sudo nft add rule inet filter input tcp dport 443 drop

4. N-central nach dem Patchen neu starten.

Dieser Schritt wird leicht übersprungen und ist teuer, wenn man ihn überspringt. Der Servlet-Austausch des Exploits ist eine In-Memory-Änderung an der laufenden Jetty-Konfiguration. Den Code auf der Platte zu patchen macht eine bereits erfolgte Umkonfiguration im Prozess nicht rückgängig. Besteht auch nur die Möglichkeit, dass der Server vor dem Patchen angefasst wurde, starten Sie den Dienst neu.

5. Behebung mit dem öffentlichen Modul verifizieren — ausschließlich auf eigenen Systemen.

# Modul von Stephen Fewer (Rapid7), eingereicht als Draft-PR #21896 im
# metasploit-framework. Der Modulpfad kann sich beim Merge noch aendern.
# NUR gegen N-central-Server einsetzen, die Ihnen gehoeren oder fuer die
# Sie vertraglich zum Test beauftragt sind.
#
# check() liest die Produktversion aus den Fehler-Metadaten der unauthenti-
# fizierten Action und vergleicht sie mit 2026.3.1.14:
#   "safe"     -> 2026.3.1.14 oder neuer
#   "appears"  -> verwundbarer Build erkannt

msf6 > use exploit/linux/http/nable_ncentral_unauth_rce_cve_2026_86218
msf6 > set RHOSTS ncentral.example.com
msf6 > set RPORT 443
msf6 > set SSL true
msf6 > check

Detektionsmaßnahmen

Die Logs von N-central lassen sich aus der Konsole herunterladen (Administration Utilities > View Logs). Relevant sind hier vor allem envoy_proxy_HTTPS.log und ui_access_control.log; auch die ncentraldms-Syslog-Ausgabe lohnt sich. Die folgenden Kommandos setzen voraus, dass Sie diese Dateien lokal vorliegen haben — passen Sie die Pfade an.

# 1. Aufklaerung gegen die verwundbare unauthentifizierte Struts-Action.
#    Angreifer wurden vor der Offenlegung beim Abfragen von
#    method=getPierDetails beobachtet.
grep -E -i 'remoteControlAction\.do' envoy_proxy_HTTPS.log

# 2. Das Race selbst: zwei fast gleichzeitige Multipart-POSTs auf diese
#    Action in einer Session. Zeitstempel innerhalb einer Sekunde sind
#    das Signal.
grep -E 'POST[^"]*remoteControlAction\.do' envoy_proxy_HTTPS.log | tail -n 200

# 3. Die Servlet-Holder, die der oeffentliche Exploit in eine Shell
#    verwandeln kann. Requests auf diese Pfade mit kommandoartigen
#    Parametern sind Post-Exploitation.
grep -E -i '/(LogRetrieval|FileTransfer|AutomationManagerDownloadServlet)' \
    envoy_proxy_HTTPS.log

# 4. N-able benannte 23.234.64.0/18 als Quelle von Scanning-Aktivitaet.
#    Dieser CIDR umfasst 23.234.64.0 bis 23.234.127.255.
grep -E '(^|[^0-9])23\.234\.(6[4-9]|[7-9][0-9]|1[01][0-9]|12[0-7])\.[0-9]{1,3}' \
    envoy_proxy_HTTPS.log

# 5. Huntress-IoC-Adressen aus den N-central-Vorfaellen im August/September.
cat > /tmp/ncentral-ioc-ips.txt <<'EOF'
173.249.252.200
87.249.138.34
37.19.210.32
68.235.46.214
37.153.90.88
92.118.112.181
173.249.252.176
185.156.46.150
23.234.94.43
68.235.46.235
23.234.100.105
23.234.97.68
EOF

# -F vergleicht die Adressen literal, -f liest die Muster aus der Datei.
grep -F -f /tmp/ncentral-ioc-ips.txt envoy_proxy_HTTPS.log ui_access_control.log

# 6. Backdoor-Administratorkonten. N-able wies auf Konten hin, deren
#    E-Mail-Adressen die reservierte TLD .invalid (RFC 2606) verwenden.
#    Benutzerliste aus der Konsole exportieren und pruefen -- und zusaetzlich
#    mit den Augen nach aehnlich aussehenden Namen suchen.
grep -E -i '\.invalid([^A-Za-z0-9]|$)' ncentral-users.csv

Auf verwalteten Windows-Endpunkten prüfen Sie, ob jemand eine Fernwartungssitzung geöffnet hat, die er nicht hätte öffnen sollen:

# Take-Control- / MSP-Support-Sitzungslogs auf verwalteten Endpunkten.
# Zeitstempel gegen Sitzungen abgleichen, die sich per Ticket belegen lassen.
Get-ChildItem -Path 'C:\ProgramData\GetSupportService_N-Central\Logs' `
              -Filter 'BASupSrvc_*.log.gz' -ErrorAction SilentlyContinue |
    Sort-Object -Property LastWriteTime -Descending |
    Select-Object -Property Name, LastWriteTime, Length

# Die Event-IDs 4102, 8192 und 8193 wurden mit "MSP Support"-Sitzungen in
# Verbindung gebracht. Jedes Eventlog durchsuchen, das tatsaechlich
# Datensaetze enthaelt, da der Kanalname je nach Agent-Version variiert.
Get-WinEvent -ListLog * -ErrorAction SilentlyContinue |
    Where-Object { $_.RecordCount -gt 0 } |
    ForEach-Object {
        Get-WinEvent -FilterHashtable @{ LogName = $_.LogName; Id = 4102, 8192, 8193 } `
                     -ErrorAction SilentlyContinue
    } |
    Select-Object -Property TimeCreated, LogName, Id, Message

Weitere Suche, für die es kein einzelnes Kommando gibt und die einen Menschen braucht:

Cloudflare-Tunnel auf dem N-central-Server oder auf verwalteten Endpunkten — ein cloudflared-Prozess oder -Dienst, den niemand ausgerollt hat
Von N-central ausgeführte Skripte, die sich keinem Ticket, keinem Change-Record und keinem geplanten Wartungsfenster zuordnen lassen
Fernwartungssitzungen in Domain Controller — in den meisten MSPs selten genug, dass jede einzelne individuell erklärbar sein sollte
Berechtigungs- und Rollenänderungen an bestehenden N-central-Konten, nicht nur neu angelegte Konten

Langfristige Sicherheitsverbesserungen

Nehmen Sie die RMM-Konsole aus dem Internet. Stellen Sie sie hinter ein VPN oder einen identitätsbewussten Proxy. Diese eine Änderung hätte jede der vier N-central-CVEs dieser fünfwöchigen Serie neutralisiert — unabhängig vom Patch-Stand.
Erzwingen Sie MFA für alle administrativen N-central-Konten — und beachten Sie, dass CVE-2026-86207 ein Bypass des Legacy-Zwei-Faktor-Handlers war. Prüfen Sie also auch, ob Sie sich noch auf einen veralteten 2FA-Pfad verlassen.
Behandeln Sie den RMM-Server als Tier-0-Asset. Er besitzt privilegierte, skriptgesteuerte Ausführungsrechte auf Domain Controllern. Er verdient dieselbe Isolation, Überwachung und Change-Kontrolle wie ein Domain Controller.
Leiten Sie N-central-Logs in Echtzeit vom System weg. Mindestens ein bestätigtes Opfer konnte den Einstiegsvektor nicht ermitteln, weil die Logs unzureichend waren. Zentrales Logging ist der Unterschied zwischen “wir haben gepatcht” und “wir wissen, was passiert ist”.
Starten Sie den Dienst nach jedem Security-Hotfix neu. Eine Kompromittierung im Arbeitsspeicher ist für einen Patch auf Dateiebene unsichtbar — und genau die erzeugt diese Schwachstelle.
Auditieren Sie die Administratorliste regelmäßig, nicht erst im Vorfall. Backdoor-Konten mit plausiblen Namen findet man durch periodische Durchsicht, nicht durch Alarmierung.
Abonnieren Sie status.n-able.com und leiten Sie es an einen Menschen weiter. Die vier Hotfixes kamen an Wochenenden und außerhalb der Geschäftszeiten. Ein Hersteller-Status-Feed, der in einem ungelesenen Postfach landet, ist keine Kontrolle.
Wenn Sie Kunde eines MSP sind, fragen Sie direkt nach: Welche N-central-Build-Nummer läuft, ist die Konsole aus dem Internet erreichbar, und wurde die vom KEV geforderte Triage abgeschlossen? Sie hängen an dessen Patch-Zyklus — ob Sie Einblick darin haben oder nicht.

⚠️ Warum ist das kritisch?

CVSS 10.0 ist die Obergrenze. Netzwerk-Vektor, geringe Komplexität, keine Privilegien, keine Benutzerinteraktion, vollständige Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit — und ein Scope-Wechsel, weil die kompromittierte Komponente andere kontrolliert.
Sie wurde ausgenutzt, bevor außerhalb des Angreiferkreises jemand von ihr wusste. Es gab kein sicheres Fenster, in dem man dem Angriff durch Patchen hätte zuvorkommen können.
Es existiert ein öffentliches Metasploit-Modul. Der Exploit ist jetzt für jeden ein set RHOSTS entfernt.
Der Wirkungsradius sind fremde Netzwerke. Die Kunden eines MSP erben dieses Risiko, ohne gefragt und meist ohne informiert zu werden.
Der Angriff nutzt die legitimen Funktionen der Plattform. Die Aktivität nach der Kompromittierung besteht aus Skriptausführung und Fernwartung — genau dem, wofür N-central existiert. EDR schlägt nicht an, weil dem Werkzeug per Design vertraut wird.
Die Persistenz liegt im Arbeitsspeicher. Patchen ohne Neustart kann den Kommando-Endpunkt eines Angreifers auf einem “gepatchten” Server aktiv lassen.
Vier Notfall-Hotfixes in fünf Wochen deuten auf eine Angriffsfläche hin, die weiterhin aktiv von Forschern wie Angreifern untersucht wird. Mit dem nächsten Fund sollte man planerisch rechnen.
CISA gab drei Tage. Aufgenommen am 8. September, fällig am 11. September. Diese Frist bindet formal Bundesbehörden, ist aber zugleich das deutlichste verfügbare Signal dafür, wie schnell CISA mit einer Massenausnutzung rechnete.

📅 Zeitlinie und Offenlegung

2026-08-01/02 — N-able legt CVE-2026-18556 und CVE-2026-18577 offen; Huntress registriert an denselben Tagen Angriffsaktivität
2026-08-02 — Hotfix 1 (2026.3.1.7)
2026-08-06 — Hotfix 2 (2026.3.1.10); weitere Angreiferinfrastruktur beobachtet
2026-08-27 — Rapid7 kontaktiert N-able zur Authentifizierungs-Bypass-Kette; N-able antwortet noch am selben Tag
2026-08-28 — Rapid7 liefert technische Analyse und ein Exploit-Skript
2026-09-04 — Huntress legt eine Kundenkompromittierung offen; Einstiegsvektor wegen unzureichenden Loggings unbestätigt
2026-09-05 — Hotfix 3 (2026.3.1.13) behebt CVE-2026-86206 (CVSS 6.9) und CVE-2026-86207 (CVSS 7.7)
2026-09-05 — Huntress und N-able beobachten eine neue Exploit-Kette im Einsatz; Aktivität von Tzulo-VPN-Infrastruktur
2026-09-06 — Hotfix 4 (2026.3.1.14) behebt CVE-2026-86218, offengelegt als Zero-Day
2026-09-06/07 — N-able veröffentlicht sein Advisory; öffentlicher Wortlaut und Kundenbenachrichtigung widersprechen sich in der Frage, ob Ausnutzung bestätigt war
2026-09-08 — CISA nimmt CVE-2026-86218 in den KEV-Katalog auf, Frist 2026-09-11; Rapid7 veröffentlicht seine Analyse zu CVE-2026-86206/86207
2026-09-09 — Bestätigte Ausnutzung gegen Kunden gemeldet
2026-09-14 — Öffentliches Metasploit-Modul veröffentlicht (Draft-PR #21896)

📚 Ressourcen und Referenzen

🤝 SEKurity Unterstützt Sie

Drei Wochen, drei Systeme, deren einzige Aufgabe es war, vertrauenswürdig zu sein: die Appliance, die Ihr VPN terminiert, das Repository, aus dem Ihre Builds ziehen, und nun die Konsole, die administrative Rechte auf jeder Maschine hält, die Ihr Dienstleister verwaltet. Dieses Muster ist kein Zufall. Angreifer haben verstanden, dass der billigste Weg in viele Organisationen über den einen Anbieter führt, an den sie alle ihr Vertrauen ausgelagert haben — und Management-Ebenen sind systematisch untergetestet, weil sie Infrastruktur sind, weil sie funktionieren und weil niemand einen Penetrationstest gegen das System einplant, das die Updates der Penetrationstest-Werkzeuge ausrollt.

Wenn Sie ein MSP sind, lauten die Fragen: Ist Ihre Konsole aus dem Internet erreichbar, auf welchem Build läuft sie, haben Sie sie nach Hotfix 4 neu gestartet, und können Sie aus Ihren Logs belegen, was zwischen dem 1. August und dem 6. September auf ihr passiert ist? Wenn Sie Kunde eines MSP sind, ist die Frage einfacher und schwerer zu beantworten: Hat irgendjemand Ihrem Dienstleister diese vier Fragen gestellt? Wir helfen auf beiden Seiten dieses Gesprächs.

Unsere Leistungen

Penetration Testing: Webanwendungen, Mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Einsätze
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Management-Infrastruktur ist unser Antrieb.

Quellen

CISA — Known Exploited Vulnerabilities Catalog — KEV-Eintrag zu CVE-2026-86218, aufgenommen 2026-09-08, Frist 2026-09-11, Ransomware-Nutzung Unknown
N-able Status — N-central 2026.3 Hotfix 4 — CVE-2026-86218 — korrigierter Build 2026.3.1.14, Veröffentlichungsdatum, Upgrade-Pfade, gehostet vs. On-Premises
N-able — N-central Security Update: Take Action to Apply 2026.3 HF4 — CVSS-Werte zu CVE-2026-86206/86207, der Scanning-Bereich 23.234.64.0/18, Hinweise zu .invalid-Konten
Rapid7 — CVE-2026-86206, CVE-2026-86207: N-able N-central Authentication Bypass (FIXED) — die Pfad-Uneinigkeit bei /dms;/services/ServerUI, das Fail-open des Forwarded-Headers in LocalHostUtils.xffCheck(), die Session-Bindung in UserTwoFactorLogin, eingebaute Benutzer-IDs, Offenlegungszeitlinie
Huntress — Rapid Response: Critical N-able N-central Vulnerability and Active Exploitation — IoC-Adressen und -Domains, Cloudflare-Tunnel-Account-Tag, getPierDetails-Aufklärung, Log-Dateinamen, Windows-Endpunkt-Artefakte und Event-IDs, Hotfix-Zeitlinie
Metasploit Framework PR #21896 — N-able N-central Struts BeanUtils Unauthenticated RCE — Ursachenbeschreibung, das Multipart-Race, der Austausch gegen Jettys CGI-Servlet, die Holder LogRetrieval/FileTransfer/AutomationManagerDownloadServlet, Modul-Optionen, getestete Versionen
The Hacker News — N-able N-central Pre-Auth RCE Flaw Exploited in the Wild — Reproduktion durch watchTowr, KEV-Listung, Aussagen von N-able
BleepingComputer — N-able patches max severity N-central flaw amid ongoing attacks — Shadowserver-Zahl von rund 1.500 exponierten Servern, Hotfix-Abfolge
Help Net Security — N-able patches critical N-central zero-day exploited in the wild (CVE-2026-86218) — der Offenlegungsweg über den MSPGeek-Discord, der Widerspruch zwischen öffentlicher und Kundenkommunikation von N-able
Arctic Wolf — CVE-2026-86218: Active Exploitation of N-able N-central — CWE-96-Klassifizierung, Verkettung mit CVE-2026-86206/86207, Hinweise zu Gegenmaßnahmen
IONIX — CVE-2026-86218 Threat Center — CVSS-v4.0-Vektor
securityonline.info — N-central RCE CVE-2026-86218 Exploited, Metasploit PoC Out — Zuordnung des Metasploit-Moduls und der Ausführungskontext nable
EntryZero — Top 5 Hacker-relevante Schwachstellen — wöchentliche Schwachstellen-Shortlist, aus der das Thema dieser Woche ausgewählt wurde

InSEKurity of the Week (CW37/2026): N-able N-central Pre-Auth RCE ueber Struts-BeanUtils-Race (CVE-2026-86218)