Zum Hauptinhalt springen
S-EDV news
← Alle News
Sicherheit & Datenschutz 13.09.2026 · 10 min Lesezeit

CISA nimmt fünf aktiv ausgenutzte Lücken in den KEV-Katalog auf

Die US-Behörde CISA hat fünf Schwachstellen in JFrog Artifactory, ConnectWise ScreenConnect und MikroTik RouterOS als aktiv ausgenutzt eingestuft. Für RouterOS endet die Behördenfrist bereits am 13. September, für ScreenConnect am 14. September, für Artifactory am 25. September. Was dahintersteckt und in welcher Reihenfolge Administratoren die drei Produkte abarbeiten sollten.

Helles Editorial-Titelbild mit unscharf abgebildeter Netzwerk- und Serverhardware und der Schlagzeile Fünf Lücken im KEV-Katalog KI-generiert

Die US-Cybersicherheitsbehörde CISA hat am 10. und 11. September 2026 fünf Schwachstellen in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen. Betroffen sind drei Produkte, die in vielen Unternehmensnetzen eine tragende Rolle spielen: das Artefakt-Repository JFrog Artifactory, die Fernwartungslösung ConnectWise ScreenConnect und das Router-Betriebssystem MikroTik RouterOS. Die Katalogversion 2026.09.11 umfasst damit 1709 Einträge.

Für Administratoren ist dieses Ereignis vor allem eine Priorisierungsfrage. Die technischen Analysen zu den einzelnen Lücken liegen teilweise seit Anfang September vor. Neu ist die behördliche Einstufung als aktiv ausgenutzt, verbunden mit verbindlichen Fristen für US-Bundesbehörden. Diese Fristen sind für deutsche Unternehmen nicht bindend, sie sind aber ein brauchbarer Gradmesser dafür, wie dringend CISA das jeweilige Risiko einschätzt.

Die fünf Einträge im Überblick

Zwei der Einträge betreffen MikroTik RouterOS und wurden am 10. September aufgenommen, die übrigen drei kamen am 11. September dazu. Die Fristen fallen deutlich auseinander: drei Tage für RouterOS und ScreenConnect, vierzehn Tage für die beiden Artifactory-Lücken.

CVEProduktSchwachstellentypBetroffene VersionenFixKEV-Frist
CVE-2026-86060MikroTik RouterOSArgument Injection, Rechteausweitungab 7.24 vor 7.24.2; ab 7.0.0 vor 7.23.4; ab 6.0.0 vor 6.49.217.24.2 / 7.23.4 / 6.49.2113.09.2026
CVE-2026-67277MikroTik RouterOSFehlende Authentifizierung im btest-Dienstab 7.24 vor 7.24.2; ab 7.0.0 vor 7.23.4; ab 6.0.0 vor 6.49.217.24.2 / 7.23.4 / 6.49.2113.09.2026
CVE-2026-84869ConnectWise ScreenConnect (nur Client)Fehlende Autorisierung, unsaubere Rechteverwaltungalle Versionen vor 26.6.526.6.514.09.2026
CVE-2026-42016JFrog Artifactory (Self-Hosted)Fehlerhafte Autorisierungsprüfungvor 7.133.117.133.1125.09.2026
CVE-2026-42018JFrog Artifactory (Self-Hosted)Fehlerhafte Authentifizierungvor 7.111.20; 7.117.0 bis 7.117.26; 7.125.0 bis 7.125.18; 7.133.0 bis 7.133.27; 7.146.0 bis 7.146.77.111.20 / 7.117.27 / 7.125.19 / 7.133.28 / 7.146.825.09.2026

Der Bewertungsstand ist nicht bei allen Einträgen gleich belastbar. ConnectWise gibt für CVE-2026-84869 selbst einen CVSS-Wert von 9.9 an, CERT Polska nennt für die beiden RouterOS-Lücken 8.8 beziehungsweise 9.2. Für die beiden Artifactory-Lücken kursieren die Werte 8.1 und 7.5, diese stammen jedoch aus der Fachpresse. JFrog selbst stuft beide im eigenen Advisory nur qualitativ als hoch ein und veröffentlicht keine numerischen Werte. Die beiden Zahlen sind damit nicht unabhängig bestätigt.

MikroTik RouterOS: Frist läuft heute ab

Die beiden RouterOS-Einträge haben mit dem 13. September 2026 die kürzeste Frist, und sie sind auch operativ der dringendste Fall. CERT Polska hat die Angriffskette unter dem Namen MikroTrick beschrieben und dokumentiert aktive Übernahmen seit mindestens dem 2. September 2026.

Die Kette kombiniert einen Authentifizierungs-Bypass im SSH-Dienst mit einer Rechteausweitung über einen manipulierten Benutzernamen. Ergebnis ist die vollständige, unauthentifizierte Übernahme jedes Geräts, dessen SSH-Dienst aus dem öffentlichen Netz erreichbar ist. Die Standardkonfiguration von MikroTik blockiert diesen Zugriff, betroffen sind also vor allem Geräte, bei denen der Port bewusst geöffnet wurde.

Ein wichtiger Punkt für alle, die ihre Patch-Planung strikt am KEV-Katalog ausrichten: Die eigentliche Einstiegslücke der beobachteten Kette ist CVE-2026-67276, der SSH-Authentifizierungs-Bypass mit CVSS 9.2. Diese CVE steht nicht im KEV-Katalog. CERT Polska hat insgesamt sechs RouterOS-Lücken gemeldet, CISA hat davon zwei übernommen. Wer nur nach KEV patcht, bekommt hier ein unvollständiges Bild. Der Grund für die Auswahl ist öffentlich nicht bekannt. Praktisch spielt das ohnehin keine Rolle, weil alle sechs Lücken durch dieselben Releases geschlossen werden.

  • Sofort auf 7.24.2, 7.23.4 oder 6.49.21 aktualisieren, je nach genutztem Zweig.
  • Prüfen, ob SSH, WWW, WWW-SSL und der Bandwidth-Test-Server aus dem Internet erreichbar sind, und diese Dienste auf vertrauenswürdige Management-Netze begrenzen.
  • Nach dem Update das Log auf die kritische Kompromittierungsmeldung und den flagged-Marker aus /system/device-mode/print kontrollieren.
  • Die Konfiguration auf unbekannte Benutzer, Skripte, Scheduler-Aufgaben, Proxys und Tunnel durchsehen. Ein hochprivilegierter Benutzer namens ops gilt als starker Kompromittierungsindikator.
  • Die Log-Muster login failure for user - 2 from <ip> via ssh und user <name> added by ssh: - 2@<ip> sowie die von CERT Polska genannten Angreifer-Adressen 82.192.72.4 und 103.102.31.18 prüfen.

CERT Polska weist ausdrücklich darauf hin, dass das Fehlen dieser Spuren eine Kompromittierung nicht ausschließt. Auch der Flagged-Mechanismus der gepatchten Versionen erkennt nur ausgewählte Manipulationen. Ein fehlender Marker ist kein Unbedenklichkeitsnachweis.

ConnectWise ScreenConnect: das Problem sitzt im Client

CVE-2026-84869 ist mit einer Herstellerbewertung von 9.9 die am höchsten eingestufte der fünf Lücken, und sie wird in einem Detail regelmäßig falsch verstanden: Betroffen sind ausschließlich die ScreenConnect-Clients, nicht die Server. Alle Versionen vor 26.6.5 sind anfällig.

Huntress hat die Ausnutzung dokumentiert. Der Einstieg lief in den beschriebenen Fällen über Social Engineering: Ein angeblicher technischer Support brachte das Opfer dazu, Windows Quick Assist zu öffnen und den Zugriffscode herauszugeben. Anschließend installierte der Angreifer einen manipulierten ScreenConnect-Client mit einem Command-and-Control-Server unter 45.13.237.190. Die vermeintliche ausführbare Datei war in Wahrheit ein RAR-Archiv mit vier VBScript-Dateien, die nacheinander über wscript.exe laufen. Die Persistenz erfolgt über einen Run-Key namens WindowsServiceHost im Benutzerkontext.

Der Kern der Schwachstelle ist die wurmartige Ausbreitung: Bereits installierte, modifizierte Clients können dieselben Skripte automatisch auf neu verbundene ScreenConnect-Endpunkte übertragen und dort ausführen, ohne Autorisierung und ohne Bestätigung durch den Host. Aus einem einzelnen kompromittierten Rechner wird damit potenziell der gesamte betreute Gerätebestand.

  • Cloud-Instanzen erfordern keine Server-Aktion, aber die Host-Clients müssen neu installiert und die Access Agents aktualisiert werden. Dieser Schritt wird häufig übersehen und lässt verwundbare Clients zurück.
  • On-Premise-Installationen auf Version 26.6.5 anheben. Dafür ist eine gültige Lizenz nötig, bei abgelaufener Maintenance muss diese zuerst verlängert werden.
  • Als reine Übergangsmaßnahme lässt sich unter Administration, Security, Roles in jeder Rolle und für jede Session-Gruppe die Berechtigung TransferFiles abwählen. In älteren Versionen heißt sie TransferFilesInSession. Das ersetzt den Patch nicht.
  • Die ScreenConnect-Audit-Logs auf Einträge vom Typ RunFiles oder RanFiles prüfen, die aus dem Prozesskontext Guest stammen. Huntress bewertet diese Kombination als unmittelbar verdächtig.
  • Auf den Endpunkten nach den Dateien 1.vbs bis 4.vbs, nach WindowsServiceHost.vbs im AppData-Verzeichnis und nach ScreenConnect.WindowsClient.exe als Elternprozess von wscript.exe suchen.
  • Den eigenen Bestand auf nicht autorisierte ScreenConnect-Installationen durchsehen und Quick Assist per Richtlinie einschränken.

Bemerkenswert ist die Chronologie: ConnectWise veröffentlichte am 3. September 2026 eine Warnung ohne CVE und ohne Fix, verbunden mit der Empfehlung, die Dateiübertragung zu deaktivieren. Der Patch folgte erst am 8. September. Zwischen Warnung und Fix lagen also fünf Tage, in denen nur die Rollen-Mitigation zur Verfügung stand.

JFrog Artifactory: die längste Frist mit der schlechtesten Patch-Quote

Die beiden Artifactory-Lücken haben mit dem 25. September die längste Frist, was leicht als Entwarnung missverstanden wird. Wiz Research hat die Ausnutzung im Zeitraum vom 15. August bis 8. September 2026 beobachtet und beschreibt eine Zwei-Schritt-Kette: Ein unauthentifizierter POST auf /access/api/v1/aws/token/ mit abschließendem Schrägstrich liefert ein Token des internen anonymen Benutzers, das anschließend über /access/api/v1/tokens gegen einen Token mit Administratorrechten getauscht wird. In einzelnen Fällen vergingen vom ersten Request bis zum angelegten Administratorkonto weniger als fünf Minuten.

Nach der Übernahme beobachtete Wiz unter anderem bösartige Groovy-Plugins über das native Plugin-Framework, Rust-basierte Hintertüren in beschreibbaren Pfaden wie /dev/shm, /tmp und /var/tmp, hochgeladene Webshells in Repository-Pfaden sowie den Diebstahl des Cluster-Join-Keys. Der eskalierte Token behält dabei den Benutzernamen des anonymen Kontos, entsprechende Aktionen erscheinen in den Logs als Akteur token:anonymous.

Die Telemetrie von Wiz erklärt, warum die Aufnahme in den Katalog hier trotzdem berechtigt ist: Sechs Wochen nach der Veröffentlichung von CVE-2026-42016 hatten immer noch 59 Prozent der Organisationen mindestens eine verwundbare Instanz. Bei CVE-2026-42018 lag der Wert vier Wochen nach Veröffentlichung bei 62 Prozent. Die Patch-Geschwindigkeit bei als hoch eingestuften Lücken ist damit erkennbar schlecht, und genau solche Fälle adressiert der Katalog.

Für die Praxis wichtig: Betroffen sind nur Self-Hosted-Installationen. JFrog stellt für Cloud-Umgebungen ausdrücklich fest, dass diese bereits abgesichert sind und kein Handlungsbedarf besteht. Wer selbst hostet, sollte nicht nur auf die Mindestversion des eigenen Zweigs gehen, sondern auf dessen höchste sichere Version, weil im September eine dritte, kritischere Artifactory-Lücke separat in den Katalog aufgenommen wurde und in der beobachteten Praxis gemeinsam mit den beiden hier genannten ausgenutzt wird. Eine detaillierte Aufarbeitung der Angriffskette haben wir bereits veröffentlicht.

Im KEV-Katalog zu stehen ist nicht dasselbe wie gefährlich

Der Katalog beantwortet genau eine Frage: Gibt es belastbare Hinweise darauf, dass eine Schwachstelle tatsächlich ausgenutzt wird. Er ist kein Schweregrad-Ranking und keine vollständige Liste aller relevanten Risiken. Drei Missverständnisse tauchen in der Praxis regelmäßig auf.

  • Ein hoher CVSS-Wert ohne KEV-Eintrag bedeutet nicht, dass die Lücke ungefährlich ist. Umgekehrt kann ein KEV-Eintrag mit mittlerem Wert deutlich dringender sein, weil die Ausnutzung belegt ist.
  • Der Katalog ist nicht vollständig. Das Beispiel CVE-2026-67276 bei RouterOS zeigt, dass die eigentliche Einstiegslücke einer aktiv genutzten Kette fehlen kann, während Folgelücken aufgenommen werden.
  • Bei allen fünf Einträgen steht das Feld zur bekannten Nutzung durch Ransomware-Kampagnen auf dem Wert Unknown. Das heißt: CISA hat keinen bestätigten Ransomware-Bezug. Es ist weder eine Entwarnung noch ein Beleg für eine Ransomware-Kampagne.
  • Die Fristen gelten formal nur für US-Bundesbehörden. Sie sind für andere Organisationen ein Dringlichkeitssignal, keine Rechtspflicht.

Der vorgeschriebene Handlungstext ist bei allen fünf Einträgen wortgleich und verweist auf die Direktive BOD 26-04, die Sicherheitsupdates nach Risiko priorisiert. Interessanter als der Text ist die Fristlänge: Drei Tage statt der üblicherweise längeren Fenster signalisieren, dass CISA die betroffenen Systeme als unmittelbar internet-exponiert und akut ausgenutzt einstuft.

Priorisierung: in welcher Reihenfolge abarbeiten

Wer alle drei Produkte im Einsatz hat, sollte sich nicht an der alphabetischen Reihenfolge der Herstellernamen orientieren, sondern an der Kombination aus Erreichbarkeit, belegter Ausnutzung und Schadenspotenzial.

An erster Stelle steht MikroTik RouterOS. Die Geräte stehen definitionsgemäß am Netzrand, die Übernahme erfolgt unauthentifiziert, es gibt dokumentierte erfolgreiche Angriffe seit Anfang September, und die Frist ist bereits heute erreicht. Ein übernommener Router bedeutet zudem, dass sämtliche darüber laufende Kommunikation als kompromittiert gelten muss.

An zweiter Stelle folgt ScreenConnect. Die Lücke wird ausgenutzt, sie breitet sich wurmartig über verbundene Endpunkte aus, und Fernwartungswerkzeuge haben üblicherweise administrativen Zugriff auf genau die Systeme, die man schützen will. Der Aufwand ist hier höher als erwartet, weil Clients und Access Agents einzeln nachgezogen werden müssen.

An dritter Stelle steht Artifactory, allerdings nur bei Self-Hosted-Betrieb. Die Frist ist länger, das Schadenspotenzial dafür strategisch am größten: Artifactory ist ein Build-Artefakt-Repository, eine Kompromittierung ist ein Lieferkettenvorfall. Bei einem Verdacht reicht es nicht, den Server zu bereinigen, es müssen auch die ausgelieferten Artefakte und die daraus gebauten Systeme betrachtet werden.

Eine übergreifende Empfehlung gilt für alle drei Fälle: Management-Zugänge gehören nicht ins offene Internet. Wer SSH, Weboberflächen oder Fernwartungsdienste hinter einen VPN-Zugang legt, nimmt einer ganzen Klasse solcher Lücken die Angriffsfläche, unabhängig vom aktuellen Patch-Stand.

Was jetzt konkret zu tun ist

Für kleine Unternehmen ohne dediziertes Schwachstellenmanagement lässt sich der Vorgang in einem überschaubaren Arbeitsblock abarbeiten. Entscheidend ist, zuerst eine ehrliche Bestandsaufnahme zu machen, statt sofort mit dem Patchen zu beginnen.

  • Bestand klären: Welche MikroTik-Geräte, welche ScreenConnect-Installationen und welche Artifactory-Instanzen laufen tatsächlich, und in welchen Versionen.
  • Erreichbarkeit prüfen: Welche dieser Systeme sind aus dem Internet ansprechbar, und über welche Ports.
  • Patchen in der oben genannten Reihenfolge, bei ScreenConnect einschließlich der Clients und Access Agents.
  • Erst nach dem Patch die genannten Kompromittierungsindikatoren prüfen, bei Artifactory rückwirkend mindestens bis zum 15. August 2026.
  • Bei einem Verdacht das betroffene System isolieren, Logs und Konfiguration vor jedem Reset sichern und anschließend Passwörter, Tokens und Schlüssel rotieren. Ein Backup vom kompromittierten Gerät nicht ungeprüft zurückspielen.

Der letzte Punkt wird am häufigsten übersprungen. Ein eingespieltes Update schließt die Lücke, es entfernt aber weder ein angelegtes Administratorkonto noch einen hinterlegten SSH-Schlüssel noch eine bereits laufende Hintertür.

Passende Anleitungen auf S-EDV

Quellen

CISA KEVJFrog ArtifactoryConnectWise ScreenConnectMikroTik RouterOSSchwachstellenPatch-Management