MikroTrick: RouterOS-Lücken — Update und SSH zu

MikroTik RouterOS mit SSH ins Internet: Die MikroTrick-Kette aus Auth-Bypass und Privilege Escalation wird aktiv ausgenutzt – Update jetzt, SSH zu, Flagged und Logs prüfen.

Stellen Sie sich vor: Home-Office, späte Stunde, der kleine graue MikroTik-Router blinkt brav unter dem Schreibtisch. Irgendwann haben Sie SSH „kurz“ freigegeben – für den Notfall, für den Kollegen, für den Tag, an dem das VPN mal streikt. Die Firewall-Regel stand noch da. Die Erinnerung daran nicht. Plot Twist: Genau diese Konstellation – RouterOS, SSH von außen erreichbar – ist derzeit der Schauplatz aktiver Angriffe. Spoiler: Es geht nicht um Science-Fiction und nicht um „irgendwann vielleicht“. CERT Polska hat bestätigt, dass die als MikroTrick benannte Verkettung zweier Lücken bereits genutzt wird, um Geräte mit internetexponiertem SSH vollständig zu übernehmen.

Überraschung für alle, die dachten, „meine Konfiguration ist doch speziell“: MikroTik selbst schreibt, die meisten Setups seien nicht unmittelbar gefährdet – und empfiehlt trotzdem dringend das Upgrade. Brisant wird es, sobald Management-Ports manuell geöffnet wurden. Wenig überraschend: Genau dort setzen die beobachteten Angriffe an. Der Clou für Sie als Admin oder Self-Hosterin: Patchen, SSH vom Internet nehmen, Flagged-Status und unbekannte Nutzer prüfen – in dieser Reihenfolge, ohne Panik und ohne Experimentierfreude am offenen Port.

Wir bei digital-magazin.de ordnen die Lage so ein, wie sie für Betroffene zählt: Verteidigung, Erkennung, Wiederaufbau. Keine Baupläne für Angriffe. Was folgt, stützt sich auf die öffentlichen Bulletins von CERT Polska (5. September 2026), MikroTik (3. September 2026), ergänzt um die CISA-KEV-Einträge vom 10. September und die Shadowserver-Zahlen, die Help Net Security aufgegriffen hat.

Szene: Der Notfall-Port, der nie wieder zu war

Die Szene kennt jede und jeder, der einmal einen Router „richtig“ eingerichtet hat. VPN war geplant. WireGuard lag auf der Liste. Dann kam der Termin, der Kunde, der Release. SSH von außen wirkte pragmatisch: ein Port, eine Regel, fertig. Monate später ist der Port noch offen, die Passwort- oder Key-Politik „gut genug“, und die Firmware-Version hängt irgendwo zwischen „läuft ja“ und „Update irgendwann am Wochenende“.

Das Pikante daran: Die Default-Konfiguration von MikroTik blockiert SSH aus dem Internet. Das Risiko entsteht vor allem dort, wo jemand bewusst geöffnet hat – und wo die Öffnung vergessen wurde. MikroTik betont in seinem Security-Bulletin vom 3. September 2026 ausdrücklich: Für typische Heimanwenderinnen und Heimanwender bestehe kein unmittelbares Risiko, aber alle sollten upgraden. Wer Management-Zugänge freigegeben hat, soll den Zugriff auf vertrauenswürdige Adressen beschränken oder besser ein starkes VPN wie WireGuard nutzen – und Management-Ports gar nicht erst ins Netz stellen.

Plot Twist Nummer zwei: Die Angreifer brauchen in der beobachteten MikroTrick-Kette keine gültigen Zugangsdaten im klassischen Sinn, sobald SSH öffentlich erreichbar ist. Die Verkettung aus Authentifizierungs-Bypass und Privilege Escalation kann laut CERT Polska zu voller Kontrolle führen – ohne vorherige Anmeldung. Genau deshalb ist „SSH kurz offen lassen“ derzeit keine Bagatelle, sondern der Plot Point, an dem aus einem Router ein fremdes Gerät werden kann.

Wer bei uns schon den Blick hinter eine andere RouterOS-Meldung geworfen hat, findet Kontext unter MikroTik RouterOS Sicherheitslücke 2026. Der heutige Fall ist die schärfere Variante: aktive Ausnutzung, KEV-Katalog, sechs koordinierte Schwachstellen, ein Codename.

122.500 offene SSH-Türen – und aktive Ausnutzung

Zahlen erzeugen selten Spannung. Diese schon. Die Shadowserver Foundation meldete laut Help Net Security mindestens 122.500 MikroTik-Geräte mit von außen erreichbarem SSH in einem 24-Stunden-Scanfenster vom 5. September 2026 – ohne dass dabei geprüft wurde, ob die jeweilige Firmware verwundbar ist. Das ist keine Opferstatistik. Es ist die Größe der potenziellen Angriffsfläche: Geräte, bei denen der Management-Dienst überhaupt erst von außen ansprechbar ist.

CERT Polska hat am 5. September 2026 öffentlich gemacht, was dahintersteckt: Sechs Schwachstellen in RouterOS wurden identifiziert und koordiniert offengelegt. Die Verkettung zweier davon – unter dem Namen MikroTrick – erlaubt vollständige Kontrolle ohne Authentifizierung, wenn SSH über das Internet erreichbar ist. In den Tagen zuvor beobachtete das Team Angriffe gegen genau solche RouterOS-Instanzen. Die Bestätigung: Angreifer nutzen die Kombination, um Geräte mit öffentlich zugänglichem SSH zu übernehmen. Die Patches stoppen die beobachteten Angriffe.

Brisant ist die Zeitachse. Erfolgreiche Angriffe inklusive Anlage eines hochprivilegierten Kontos namens ops wurden von CERT Polska unter anderem mit der IP-Adresse 82.192.72.4 in Verbindung gebracht und reichen mindestens bis zum 2. September zurück. Eine weitere Adresse (103.102.31.18) tauchte in Ausnutzungsversuchen auf. Das sind Indikatoren für die Erkennung – keine Einladung zum Nachstellen. Wer solche Spuren in Logs sieht, muss sofort untersuchen; wer sie nicht sieht, darf sich trotzdem nicht in Sicherheit wiegen. Abwesenheit bekannter Artefakte schließt frühere Kompromittierung nicht aus.

Überraschung für alle, die auf „mein Gerät ist zu klein, um interessant zu sein“ setzen: Botnetze und opportunistic Scans sortieren selten nach Unternehmensgröße. Sie sortieren nach offenen Ports und bekannten Mustern. 122.500 SSH-exponierte MikroTiks sind ein Suchraster, kein exklusiver Club.

MikroTrick in hoher Flughöhe: Bypass plus Escalation

Was Sie wissen müssen – und was Sie nicht nachbauen sollten: MikroTrick ist der Kurzname für die Verkettung zweier schwerer SSH-Lücken. CERT Polska hat sie so beschrieben, dass Admins handeln können, ohne Exploit-Code zu veröffentlichen.

CVE-2026-67276 – SSH-Authentifizierungs-Bypass, CVSS 9.2. RouterOS prüfte öffentliche Schlüssel für die SSH-Anmeldung unvollständig; insbesondere wurde nicht der gesamte RSA-Public-Key mit dem dem Benutzer zugeordneten Schlüssel verglichen. In der Konsequenz konnte unter bestimmten Voraussetzungen eine Anmeldung gelingen, ohne den zugehörigen privaten Schlüssel zu besitzen – mit den Rechten des angegriffenen Kontos. Mehr technische Rezeptur brauchen Sie für die Verteidigung nicht. Und Sie sollten sie auch nicht suchen.

CVE-2026-86060 – Privilege Escalation über einen speziell präparierten Benutzernamen, ebenfalls CVSS 9.2. RouterOS handhabte bestimmte Benutzernamen im SSH-Login-Mechanismus fehlerhaft. Das Ergebnis einer erfolgreichen Ausnutzung: eine Sitzung mit vollen administrativen Rechten im RouterOS-System. Wiederum: hohe Flughöhe, keine Bauanleitung.

Der Clou der Kette: Bypass und Escalation zusammen – bei öffentlich erreichbarem SSH – ergeben laut CERT Polska die Übernahme ohne vorherige Authentifizierung. Das ist der Plot Twist, der aus „SSH ist doch nur Management“ ein „das Gerät gehört mir nicht mehr“ macht.

Dazu kommt CVE-2026-67277 – Bandwidth-Test-Dienst, CVSS 8.8: Speicherpreisgabe und Denial-of-Service. Der Dienst erlaubte unauthentifizierten Verbindungen Zustände, die eigentlich erst nach Login erreichbar sein sollten; kombiniert mit weiteren Fehlern konnten Kernel-Speicherlecks oder ein Remote-DoS mit Neustart die Folge sein. Drei weitere, weniger schwere Lücken betreffen SSH-Client, X.509-Zertifikatsbehandlung und die WebFig-Oberfläche – relevant für die Gesamtlage, aber nicht der Kern von MikroTrick.

Wir bei digital-magazin.de halten uns bewusst an diese Flughöhe. Wer mehr Details will, liest die Originalquellen. Wer Angriffe automatisieren will, bekommt von uns nichts. Verteidigung beginnt mit Patch und Angriffsflächenreduktion – nicht mit Neugier am Proof-of-Concept.

Die Primärquelle mit der klarsten Einordnung finden Sie bei CERT Polska – MikroTik RouterOS aktiv ausgenutzt. Das Herstellerbulletin liegt unter MikroTik September 2026 Vulnerability.

Patch-Versionen: Was Sie installieren sollten

MikroTik hat Fixes in allen Kanälen veröffentlicht. Laut Security-Bulletin und CERT Polska enthalten folgende Versionen die Korrekturen:

Das Update erscheint im Menü „Check for updates“. MikroTik spricht von einem wichtigen Security-Update: Die meisten Konfigurationen seien nicht gefährdet, das Upgrade sei dennoch dringend empfohlen. Parallel – erstmals in dieser Form – gingen Push-Benachrichtigungen an Nutzerinnen und Nutzer der MikroTik-App. Wenig überraschend: Wer die App nicht nutzt, bekommt den Hinweis trotzdem über Bulletin und Changelog – sofern man hinschaut.

Wenn das Patchen nicht sofort möglich ist, nennt CERT Polska vorübergehende Maßnahmen: exponierte Dienste deaktivieren oder den Zugriff von außerhalb vertrauenswürdiger Management-Netze sperren – insbesondere SSH, WWW/WWW-SSL und den Bandwidth-Test-Server. Zusätzlich: Von ungepatchten Geräten keine TLS-Verbindungen initiieren und die eingebauten SSH-Clients (/system ssh, /system ssh-exec) nicht über untrusted Netze oder zu untrusted Hosts nutzen. Das sind Notbremsen. Sie ersetzen das Update nicht.

Wer Router-Alternativen und Firmware-Disziplin im Blick behält, findet bei uns auch den Blick hinter OpenWrt-Sicherheitsupdates – was hinter der Meldung wirklich steckt. Unterschiedliche Stacks, gleiche Lektion: Update-Fenster nicht verschlafen.

CISA setzt zwei Lücken auf die KEV-Liste

Am 10. September 2026 hat die US-Behörde CISA zwei der MikroTik-Schwachstellen in den Known Exploited Vulnerabilities Catalog aufgenommen: CVE-2026-67277 (Missing Authentication for Critical Function) und CVE-2026-86060 (Improper Neutralization of Argument Delimiters). Für Behörden und Organisationen mit KEV-Pflichten ist das ein harter Termin-Hinweis. Für alle anderen ist es die öffentliche Bestätigung: Diese Lücken werden nicht nur theoretisch diskutiert – sie gelten als bekannt ausgenutzt.

Brisant an der Auswahl: CISA hat nicht die gesamte MikroTrick-Erzählung als einen Eintrag katalogisiert, sondern zwei konkrete CVEs hervorgehoben – darunter die Privilege-Escalation-Komponente der SSH-Kette und die Bandwidth-Test-Lücke. Für Ihre Priorisierung heißt das: Patchen bleibt Pflicht, unabhängig davon, ob Ihre Organisation formell dem KEV-Katalog folgt. Der Katalog ist ein Signal, kein Ersatz für Hersteller- und CERT-Empfehlungen.

Spoiler für alle, die auf „mein Gerät steht in Europa, CISA betrifft mich nicht“ warten: Angreifer und Scanner orientieren sich nicht an Behördenzuständigkeiten. Sie orientieren sich an offenen Ports und veröffentlichten Fixes. Wenn Patches draußen sind und die Community Diffs lesen kann, steigt der Druck – CERT Polska hat die Veröffentlichung bewusst beschleunigt, weil gepatchte Pakete bereits öffentlich waren und vergleichende Analysen Teile der behobenen Fehler rekonstruieren ließen. Deshalb: begrenzt beschrieben, keine Exploit-Details, Update sofort.

Checkliste: Update, SSH, Flagged, unbekannte Konten

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptBlurred system log screen with a soft padlock metaphor nearby, documentary cybersecurity lifestyle, no readable log lines, no logos, no exploit diagrams, 16:9

Hier die Verteidigungsschritte in der Reihenfolge, die in der Praxis zählt. Speichern, abarbeiten, abhaken – ohne Heldenstory.

1. RouterOS auf eine Fix-Version bringen. 7.25beta3, 7.24.2, 7.23.4 oder 6.49.21 – je nach Kanal. Nach dem Update nicht sofort weiterklicken, als wäre nichts gewesen. Der eigentliche Plot beginnt erst jetzt: Prüfung auf Kompromittierungsspuren.

2. SSH vom Internet nehmen. Default blockiert; manuell geöffnete Regeln schließen oder auf vertrauenswürdige IPs begrenzen. Besser: Management nur über VPN – MikroTik nennt WireGuard ausdrücklich. Keine Management-Ports „kurz“ offen lassen. Wer VPN-Praxis vertiefen will, findet bei uns den VPN-Ratgeber.

3. Flagged-Status und Logs prüfen. In den gepatchten Versionen scannt RouterOS beim Start die Konfiguration auf bekannte Spuren unerlaubter Änderungen, deaktiviert erkannte verdächtige Einträge, schreibt eine kritische Logmeldung und setzt den Marker Flagged. Konzeptuell prüfen Sie das über die Geräte-/Device-Mode-Ausgabe (bei CERT Polska genannt: /system/device-mode/print) und über den Log-Bereich. Fehlt Flagged, ist das kein Freibrief: Der Mechanismus erkennt nur ausgewählte Spuren.

4. Bekannte IoCs in den Logs suchen – nur zur Erkennung. Beobachtete Angriffe hinterließen unter anderem Einträge der Form login failure for user -2 from … via ssh und user … added by ssh:-2@…. Ein weiteres Indiz: ein hochprivilegierter Benutzer namens ops, den Sie nicht angelegt haben. Jede dieser Spuren bedeutet: sofort untersuchen. Keine der Spuren bedeutet: alles in Ordnung.

5. Unbekannte Nutzer, Skripte, Scheduler, Proxy, Tunnel. Auch ohne Flagged: Konfiguration durchgehen. Fremde Accounts, Skripte, Zeitpläne, Proxys, Tunnel – alles, was Sie nicht wiedererkennen, ist verdächtig. MikroTik sagt dasselbe klar: Auch ohne Flagged nach dem Upgrade inspizieren.

6. Temporär exponierte Dienste absichern, bis gepatcht ist. SSH, WWW/WWW-SSL, Bandwidth-Test – nicht von überall erreichbar lassen. Das ist Schadensbegrenzung, kein Ersatz für den Fix.

Wir bei digital-magazin.de sehen in solchen Checklisten den Unterschied zwischen „ich habe den Artikel gelesen“ und „mein Gerät ist wieder unter Kontrolle“. Der Clou steckt selten im dramatischsten CVE-Satz – sondern in der einen Firewall-Regel, die niemand mehr erinnerte, und in dem einen Account namens ops, den niemand bestellt hat.

Wer Self-Hosting und Admin-Hygiene ohnehin ernst nimmt, sollte parallel unseren Überblick zu sicherer Admin-Praxis bei Self-Hosting, Docker und Kubernetes mitdenken: andere Stacks, gleiche Disziplin – wenig Angriffsfläche, klare Secrets-Rotation, keine blinden Backups aus der Kompromittierungsphase.

Wenn Flagged leuchtet: Isolieren, sichern, neu aufbauen

Plot Twist für Optimisten: Flagged heißt nicht „vielleicht ein Fehlalarm, den man wegklickt“. CERT Polska und MikroTik sind hier eindeutig. Wenn der Marker, die Logs, die Konfiguration oder andere Umstände auf eine mögliche Kompromittierung deuten, gehen Sie davon aus, dass das Gerät übernommen wurde.

Isolieren. Gerät vom Netz nehmen bzw. so segmentieren, dass es nicht weiter als Sprungbrett dienen kann. Keine Experimente „noch schnell eine Datei ziehen“ über denselben Management-Pfad, den Angreifer vielleicht schon kennen.

Logs und Konfiguration sichern. Bevor Sie zurücksetzen: Material sichern – Logs, Config, alles, was die Analyse und die Meldung an Ihr zuständiges CSIRT braucht. CERT Polska verweist dazu auf eigene Hinweise zur Sicherung von Logs und Konfiguration bei MikroTik. Den Flagged-Marker nicht vor Abschluss der Analyse und Sicherung löschen.

Factory Reset, dann vertrauenswürdige Neuaufsetzung. Nach der Sicherung: Werkseinstellungen, Neuaufbau auf Basis einer geprüften, vertrauenswürdigen Konfiguration – nicht das blinde Einspielen eines vollständigen Backups aus der verdächtigen Phase. Passwörter, Schlüssel und andere Secrets rotieren. Was auf dem kompromittierten Gerät lag, gilt als verbrannt, bis das Gegenteil bewiesen ist.

Das Pikante daran aus Krimi-Sicht: Das Backup, das Sie „zur Sicherheit“ aufheben, kann genau die Persistenz enthalten, die Sie loswerden wollen – unbekannte Nutzer, Skripte, Scheduler, Tunnel. Wer blind restored, schreibt den zweiten Akt des gleichen Stücks. Überraschung: Sauber neu aufsetzen dauert länger als Restore – und ist trotzdem der kürzere Weg zurück zu einem Gerät, dem Sie wieder vertrauen.

Wenn Sie Vorfälle melden: den üblichen Weg über Ihr nationales CSIRT bzw. die von CERT Polska genannten Kanäle nutzen. Keine öffentlichen „Hilferufe“ mit Config-Dumps, die weitere Secrets leaken.

Was MikroTik sagt – und was Sie daraus machen

Das Herstellerbulletin vom 3. September 2026 ist bewusst knapp gehalten: wichtiges Security-Update, die meisten Konfigurationen nicht gefährdet, Upgrade hoch empfohlen, Details zunächst zurückgehalten, damit Zeit zum Patchen bleibt. Codename MikroTrick; CVEs 67276, 86060, 67277; Verweis auf CERT.pl. Flagged erscheint im Log; Dokumentation zum Flagged-Status beachten; auch ohne Flagged unbekannte Skripte und Nutzer prüfen.

Für Home-User: kein unmittelbares Risiko laut Hersteller, aber trotzdem upgraden. Für alle, die SSH oder andere Management-Dienste freigegeben haben: Regeln schließen, VPN nutzen, Ports nicht offen lassen. Das ist keine neue Philosophie – es ist die alte, die jetzt einen aktuellen Anlass hat.

Brisant bleibt die Diskrepanz zwischen Default (SSH zu) und Realität (122.500 Geräte mit SSH erreichbar). Defaults schützen nur, solange niemand sie „pragmatisch“ außer Kraft setzt. Der Gallows-Humor schreibt sich hier von selbst: Der Notfall-Port überlebt den Notfall. Der Patch-Hinweis kommt per App-Push. Und irgendwo in einem Log steht vielleicht schon user ops added by ssh:-2@… – während im Home-Office noch die Frage kreist, ob man „das Update wirklich jetzt“ machen muss.

Ja. Jetzt.

Warum „SSH kurz offen“ gerade so teuer ist

Es gibt Konfigurationen, die jahrelang folgenlos bleiben – bis sie es nicht mehr tun. Öffentliches SSH auf einem Router gehört in diese Kategorie. Solange niemand die passende Kette kennt oder die Patches noch nicht draußen sind, wirkt der Port harmlos. Sobald Bulletins, Diffs und Scanner synchron laufen, wird aus der pragmatischen Ausnahme ein systematisch abgesuchtes Ziel.

Das Pikante an MikroTrick: Die Default-Politik von MikroTik war bereits defensiv. SSH aus dem Internet ist standardmäßig blockiert. Die beobachtete Ausnutzung trifft vor allem dort, wo jemand manuell geöffnet hat – Unternehmen, Labs, Homelabs mit Fernwartung, Setups mit „temporärer“ Ausnahme. Shadowservers 122.500 sind die Summe solcher Ausnahmen und Fehlkonfigurationen, nicht der Beweis, dass jedes dieser Geräte verwundbar ist. Aber jedes davon ist adressierbar. Und adressierbar reicht für Scans.

Plot Twist für alle, die VPN „später“ geplant hatten: WireGuard oder ein vergleichbar starkes VPN ist genau die Architektur, die MikroTik jetzt wieder in den Vordergrund stellt – Management ohne offene Management-Ports. Wer den VPN-Ratgeber schon kennt, braucht keine neue Religion. Nur die Erinnerung, dass der Notfall-Port den Notfall überlebt hat.

Für Self-Hosterinnen und Self-Hoster gilt dieselbe Logik wie bei Docker-Hosts und Admin-Panels: Wenig Angriffsfläche schlägt clevere Exceptions. Unser Stück zu sicherer Admin-Praxis sagt das für andere Stacks; MikroTrick sagt es für RouterOS mit SSH.

Und noch ein Spoiler zur Erkennung: Flagged ist ein Hinweis, kein Vollbeweis und kein Freispruch. CERT Polska betont ausdrücklich, dass der Marker nur ausgewählte Spuren kennt und dass unbekannte Schwachstellen nicht ausgeschlossen werden können. Deshalb die doppelte Pflicht nach dem Update: Marker und Logs lesen – und trotzdem Nutzer, Skripte, Scheduler, Proxy und Tunnel manuell gegen Ihr Soll-Bild prüfen. ops, das Sie nicht angelegt haben, ist kein Easter Egg. Es ist ein Alarm.

Weiterlesen

Die MikroTrick-Woche endet nicht mit einem dramatischen Schlusswort. Sie endet mit einem geänderten Update-Status, einer geschlossenen SSH-Regel und einer Konfiguration, in der Sie jeden Nutzer und jedes Skript wiedererkennen. Wenig überraschend ist das langweiliger als ein Krimi – und genau deshalb die richtige Auflösung. RouterOS patchen, SSH vom Internet nehmen, Flagged und Logs lesen, unbekannte Konten und Automatisierungen entfernen, im Verdachtsfall isolieren und sauber neu aufsetzen. Der Rest ist Disziplin: Management nur über VPN, Secrets rotieren, Backups nicht blind aus der Kompromittierungsphase zurückspielen. Wenn Ihr MikroTik danach wieder nur blinkt, weil er Pakete routet – und nicht, weil irgendwer namens ops mitregiert –, dann ist die Geschichte für heute zu Ende. Bis zum nächsten Bulletin. Bis zur nächsten „kurz offenen“ Regel. Bis Sie die Checkliste schon abgearbeitet haben, bevor der Push kommt.