CVSS 10.0, Priority-Score 0.00 — und trotzdem der dringendste Patch dieser Woche

N-able hat am 6. September ein Notfall-Update für seine RMM-Plattform N-central veröffentlicht. CVE-2026-86218 erlaubt Codeausführung vor der Anmeldung — kein gültiges Konto nötig, keine Nutzerinteraktion. Behoben in N-central 2026.3 Hotfix 4, Build 2026.3.1.14.

Wer selbst hostet, hat damit den dringendsten Patch dieser Woche auf dem Tisch. Bemerkenswert ist aber etwas anderes: In der Priorisierung von NEOSEC Intel steht diese CVE auf 0.00. Das ist der interessantere Teil dieses Falls.

Die Zahlen, die sich widersprechen

Eine 10.0 bei einer Ausnutzungswahrscheinlichkeit von 0,4 Prozent. Ein Priorisierungs-Score von null bei einer Lücke, die N-able selbst als kritisch einstuft und außerplanmäßig patcht.

Beides ist korrekt berechnet. Und beides führt in die Irre, wenn man nur auf die Zahl schaut.

Warum EPSS hier strukturell blind ist

EPSS schätzt die Wahrscheinlichkeit einer realen Ausnutzung in den nächsten 30 Tagen. Das Modell stützt sich unter anderem auf öffentlich verfügbaren Exploit-Code, Erwähnungen in einschlägigen Quellen und die Verbreitung des betroffenen Produkts.

Bei CVE-2026-86218 gibt es keinen öffentlichen PoC, keine technischen Details, keine Root-Cause-Angaben — N-able hat bewusst nichts davon veröffentlicht. Und N-central ist kein Massenprodukt wie ein Webserver, sondern eine Managementplattform mit vergleichsweise kleiner, aber hochwertiger Installationsbasis.

Für das Modell heißt das: wenig Signal. Für den Angreifer heißt es etwas ganz anderes.

Ein niedriger EPSS-Wert misst die Abwesenheit öffentlicher Signale, nicht die Abwesenheit von Interesse. Bei einem Produkt, dessen Zielgruppe Managed Service Provider sind, ist genau diese Unterscheidung entscheidend.

Was der CVSS-Vektor sagt, wenn man ihn liest statt zählt

Die 10.0 ist keine Übertreibung. Der v4-Vektor lautet:

AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Netzwerk, geringe Komplexität, keine Voraussetzungen, keine Rechte, keine Nutzerinteraktion. Und dann der Teil, der bei CVSS v4 neu und hier entscheidend ist: SC:H/SI:H/SA:H — Subsequent System Impact durchgehend hoch.

Das ist die formale Aussage, dass der Schaden nicht am kompromittierten System endet. Bei einer RMM-Plattform ist das keine Theorie, sondern Bauart: Ein N-central-Server verwaltet Endpunkte über Kundenumgebungen hinweg. Wer ihn kontrolliert, kontrolliert nicht einen Server, sondern eine Verteilinfrastruktur.

Hinzu kommt die SSVC-Bewertung des CISA Coordinators im CVE-Record: exploitation: none, aber automatable: yes. Noch kein beobachteter Angriff — aber ein Angriff, der sich automatisieren ließe.

Die Vorgeschichte, die der Meldung fehlt

Dies ist nicht der erste N-central-Vorfall. Es ist der dritte in dreizehn Monaten, und die Entwicklung geht in die falsche Richtung.

August 2025. CVE-2025-8875 (unsichere Deserialisierung) und CVE-2025-8876 (Command Injection) wurden von der CISA am Tag ihrer Offenlegung in den KEV-Katalog aufgenommen — bei fehlenden technischen Details und ohne öffentlichen PoC ein starkes Indiz für Zero-Day-Ausnutzung. N-able bestätigte Ausnutzung in einer begrenzten Zahl selbstgehosteter Umgebungen. Beide Lücken waren post-authentication; Beobachter werteten das seinerzeit als mildernden Umstand.

August 2026. Fast genau ein Jahr später erneut aktive Ausnutzung, erneut KEV-Aufnahme, diesmal mit Authentifizierungs-Umgehung und administrativem Zugriff auf dem Server.

September 2026. CVE-2026-86218, jetzt pre-authentication. Der mildernde Umstand von 2025 ist weg.

Die Hotfix-Kadenz erzählt dieselbe Geschichte: Hotfix 3 war Build 2026.3.1.13, Hotfix 4 ist 2026.3.1.14. Zwei Notfall-Updates in kurzer Folge.

Wer jetzt was tun muss

Gehostete Umgebungen (NCOD) sind laut N-able bereits gepatcht, dort ist keine Aktion nötig.

Selbstgehostete Installationen brauchen Build 2026.3.1.14. Direkte Upgrades werden unterstützt aus 2025.4, 2026.1, 2026.2, 2026.3 und 2026.3.1 Hotfix 1 und 2. Wer auf älteren Ständen läuft, muss zuerst auf einen dieser Zwischenstände migrieren. Die Agenten müssen für diese Lücke nicht aktualisiert werden.

Vier Punkte, die über das reine Einspielen hinausgehen:

1. Protokolle sichern, bevor die Wartung beginnt. Server- und Authentifizierungsprotokolle wegschreiben, dann patchen. Ein Update entfernt die Spuren einer bereits erfolgten Kompromittierung nicht — aber Wartungsarbeiten können sie überschreiben. Wer nach dem Patch feststellt, dass er kompromittiert war, will die Protokolle von vorher haben.
2. Erreichbarkeit prüfen und reduzieren. Jeden selbstgehosteten N-central-Server erfassen, Build-Nummer verifizieren, administrative Oberflächen auf freigegebene Managementnetze beschränken. Ein aus dem Internet erreichbarer RMM-Server ist eine Entscheidung, die man nach diesem Jahr begründen können sollte.
3. Rückblickend auswerten. Ungewöhnliche Zugriffe, auffällige Prozessausführung, neue Konten, geänderte Skripte oder Automatisierungsaufgaben. Bei einer Plattform, die Code auf Endpunkte verteilt, ist die Frage nach manipulierten Automatisierungen mindestens so wichtig wie die nach dem Server selbst.
4. Privilegien überprüfen. Welche Konten haben Zugriff, welche Dienstkonten hängen daran, was kann von dort aus erreicht werden?

Der Punkt, der über diesen Fall hinausgeht

Wir haben an anderer Stelle beschrieben, warum CVSS als alleinige Priorisierungsgrundlage nicht trägt und warum EPSS und KEV-Status die besseren Signale sind. Dieser Fall ist das Gegenbeispiel — und deshalb lehrreich.

EPSS sagt: 0,4 Prozent. KEV sagt: nicht gelistet. Priority-Score sagt: 0.00. Alle drei Signale zeigen nach unten, und alle drei sind für sich genommen korrekt.

Was sie nicht wissen können: dass dieser eine Server hunderte Kundenumgebungen administriert. Der Asset-Kontext ist die Größe, die kein externer Score enthält — er kommt aus Ihrem eigenen Inventar. Ein Priorisierungsmodell ohne Asset-Gewichtung ist ein Vorschlag, keine Entscheidung.

Für NEOSEC Intel heißt das konkret: Der Priority-Score verdichtet technische Schwere, Ausnutzungswahrscheinlichkeit, KEV-Status und Asset-Kontext zu einer Rangfolge. Im öffentlichen Katalog fehlt die letzte dieser vier Größen naturgemäß — es gibt dort keinen Kundenbezug. Und dann steht, wie hier, eine Null bei einer Lücke, die man heute Nacht schließt.

Und für Managed Service Provider gilt der Satz, den man nicht oft genug sagen kann: Ihre Managementplattform ist die Lieferkette Ihrer Kunden. NIS-2 verlangt in Artikel 21 Absatz 2 Buchstabe d Sicherheit der Lieferkette. Für ein Unternehmen, dessen IT-Dienstleister N-central einsetzt, ist der Patchstand dieses Servers eine Frage der eigenen Compliance — auch wenn der Server jemand anderem gehört.

Das ist eine Frage, die Sie stellen dürfen. Und eine, die Sie beantworten können sollten, wenn Sie der Dienstleister sind.

Quellen

• CVE-2026-86218 im NEOSEC-Intel-Katalog
• N-able Security Advisory zu CVE-2026-86218
• N-able Status: N-central 2026.3 Hotfix 4
• BSI CERT-Bund WID-SEC-2026-3205
• Tamilselvan, „Critical N-able N-central Flaw Enables Unauthenticated Pre-Auth Remote Code Execution", Cyber Press, 7. September 2026
• CISA — Aufnahme von CVE-2025-8875 und CVE-2025-8876 in den KEV-Katalog, 13. August 2025

Zum Zeitpunkt der CyberPress-Meldung war kein CVSS-Wert sichtbar. Der CVE-Record des Herstellers als CNA enthält inzwischen einen CVSS-v4-Basiswert von 10.0.