Home   2026-10-22 19:56:51

←

Cybercriminelen nemen MikroTik-routers over via twee kritieke SSH-lekken

Original article

Cybercriminelen misbruiken twee onlangs bekendgemaakte kwetsbaarheden in routers van MikroTik. Daarmee kunnen de aanvallers apparaten overnemen waarvan de SSH-diensten via internet toegankelijk zijn.

Met een van de kwetsbaarheden, CVE-2026-67276, omzeilen aanvallers de authenticatie in Secure Shell (SSH), schrijft het Poolse CERT. MikroTik RouterOS controleert de publieke sleutels voor SSH-verificatie niet goed. Een aanvaller die een gebruikersnaam en de publieke modulus van een sleutel kent, kan daardoor een andere sleutel aanmaken en via SSH inloggen zonder dat hij de bijbehorende privésleutel heeft.

MikroTik hAP be lite with RouterOS L4, International version

De tweede kwetsbaarheid die de aanvallers inzetten, is CVE-2026-86060. Dit is een privilege-escalatiefout in SSH, waarmee een aanvaller beheerdersrechten krijgt in RouterOS. Deze fout is ontstaan doordat RouterOS niet goed omgaat met gebruikersnamen voor de SSH-login die beginnen met een niet-toegestaan teken. Aanvallers kunnen daardoor zelf een gebruikersnaam aanmaken waarmee ze SSH-sessies manipuleren.

Het Poolse CERT ontdekte deze twee kwetsbaarheden met GPT-5.5 Cyber en GPT-5.6 Sol. Beide krijgen binnen het Common Vulnerability Scoring System (CVSS) een score van 9,2 op een schaal van tien. De aanval met deze kwetsbaarheden heet MikroTrick.

Derde kwetsbaarheid

Het CERT-team licht daarnaast een derde kritieke fout uit: CVE-2026-67277. Deze kwetsbaarheid, met een CVSS-score van 8,8, raakt de bandbreedtetestdienst van RouterOS. Ongeautoriseerde aanvallers kunnen door de fout gegevens uit het kernelgeheugen laten lekken of op afstand een denial-of-serviceaanval (dos) uitvoeren, zodat het systeem opnieuw opstart.

MikroTik bracht eerder al patches uit voor de gevonden kwetsbaarheden. Het CERT-team adviseert dan ook updates zo snel mogelijk te installeren. De patches zitten in versie 7.25 beta 3, 7.24.2, 7.23.4 en 6.49.21.

Door Eveline Meijer

Nieuwsredacteur

Feedback • 07-09-2026 15:04
39 • submitter: Slamdance

07-09-2026 • 15:04

39

Submitter: Slamdance

Reacties (39)

Ik neem aan dat SSH niet standaard open staat naar de buitenwereld, dat zou nog veel kwalijker zijn.
Dan heb je al een aanvaller binnen je netwerk nodig om schade aan te richten. Niet helemaal onschuldig, maar zeker voor de thuisgebruiker niets waar je je meteen te druk over moet maken.
Nee klopt, ssh staat normaal niet aan de de WAN poort.
Daarom zit er bij mij een IP allow list op alle Management van mijn MikroTik spullen. En in een separaat VLAN.
Management NOOIT open vanaf de buitenwereld, maak een VPN en vandaar uit eventueel een mgmt toegang. Bij mij alleen mgmt vanaf bekabeld in huis ik kan in geval van nood wel mijn FW aanpassen.
Toch aardig wat die het juist hebben aangezet.

The Shadowserver Foundation, een stichting die onder andere onderzoek doet naar kwetsbare systemen op internet, meldt dat het ruim 122.000 MikroTik-routers op internet heeft gevonden die via SSH toegankelijk zijn. Het gaat om bijna zevenhonderd routers in Nederland.
Als je gebruik maakt van sftp wel.
SSH openzetten vanaf het internet is dan ook niet zo heel erg handig zeg maar.. bouw een fatsoenlijke VPN naar een managementsegment als je dat perse nodig vindt en beveilig dat.

[Reactie gewijzigd door DigitalExorcist op 7 september 2026 16:02]

Het is niet handig wanneer je niet een paar basisregels in acht neemt. Zodra je dat wel doet, kan er niet zoveel spannends gebeuren. OpenSSH is veilig, MicroTik heeft één of andere halfgare implementatie bij elkaar spaghetti't, en daar zit het probleem. Niet bij OpenSSH of SSHds die naar buiten exposed zijn.
OpenSSH en allerhande libraries die die gebruikt zijn ook niet bepaald verschoond van lekken en issues... gewoon niet openzetten vanaf het internet, maar netjes achter een VPN en met keys ipv wachtwoorden, dat soort werk.
Alsof VPN-services geen lekken en issues hebben..? Wanneer je root login disabled, fail2ban z'n werk laat doen, en/of desgewenst alleen via RSA-sleutels laat inloggen laat ik rustig al mijn SSH'tjes naar buiten open staan hoor. De drie dingen die ik noem zijn veel eenvoudiger in te stellen dan een fatsoenlijke VPN-verbinding opzetten. En bovendien heb je dan niet eens volle overlap in de Venn-diagram van use cases.
Dat is ook zo. Ik ben zelf groot fan van Zerotier, een soort VXLAN meets VPN, dat draait ook 'native' op de Mikrotik als package. Geen poorten die naar binnen toe openstaan, gratis voor 10 devices, je hoeft alleen naar buiten te communiceren en niet de andere kant op, uitstekend te filteren op zowel Zerotier niveau als op Mikrotik niveau.. en installeren is 5 minuten werk. ZT connecteert alleen 'naar buiten toe' en zodra je een tweede device in je VXLAN opneemt praten ze als een mesh met elkaar. Snelheid is ook uitstekend.

Mikrotik erin, iPhone erin, (werk)laptop erin en je hebt overal en altijd toegang, en anderen niet. Sterker nog, ik woon in bij m'n ouders en die hebben hun Ziggo modem ook niet in bridge mode staan; inkomend verkeer is onmogelijk richting de Mikrotik die ik erachter heb hangen maar Zerotier connect gewoon binnen 3 seconden.

[Reactie gewijzigd door DigitalExorcist op 7 september 2026 16:30]

Oeps, gelukkig hier vrijwel alle poorten dichtgezet, maar toch snel even updaten zodra ik thuis ben.

In het gelinkte artikel staat dat iedereen een push notificatie gehad zou moeten hebben op de mobiele app, maar ik heb iig niets gezien.

(tip in IP > Services kan je de SSH volledig uitschakelen)
Ik heb de push notificatie ook niet gehad. Nu maar ingeschreven voor de nieuwsbrief. Je hebt een optie om alleen security gerelateerd nieuws te ontvangen.
Lekker bezig daar bij MicroTik met een eigen ssh implementatie die brak is dan. Dit is dus geen SSH bug, maar een MicroTik implementatie bug. Het protocol is prima.
Waarbij je je meteen weer afvraagt waarom men voor dit soort dingen het wiel opnieuw wilt uitvinden?
OpenVPN hebben ze ook gebouwd op basis van een eigen implementatie.
Los van dat het in dit artikel in ieder geval nergens staat of het een eigen implementatie is of dat ze gewoon de versie uit Linux hebben gepakt (waarop RouterOS is gebaseerd). Moet je je library die je gebruikt wel zo gebruiken en integreren dat dit past in jouw beoogde doel hiervoor. Bijvoorbeeld: Hoe kan een standaard SSH library jouw sessie valideren als jij zelf gaat over het aanmaken en beheer van gebruikers. Dan moet je dit stukje toch zelf regelen. En juist hierin zit de fout.

Daarnaast als ik kijk naar de puinzooi aan pakketjes die je soms krijgt, loont het soms echt wel om het wiel dan maar opnieuw uit te vinden, en je dit op de duur minder tijd vergt om te onderhouden. Of soms zit je met licenties die niet passen bij je beoogde doel, dan wel heb je eisen dat je applicatie op bepaalde hardware moet draaien (die ze ook zelf ontwikkelen) waardoor je wellicht andere eisen hebt aan libraries etc etc.
Ik heb de push notificatie vorige week ontvangen, gelijk de hele zwik aan access points, routerboard, CRS switch en CHR geupdate. Bij mijn weten de eerste keer dat ik een push notificatie van Mikrotik heb ontvangen. Maar ging best soepel bij mij.

Ik heb uiteraard geen open SSH, alleen via een Wireguard VPN, dus was als het goed is niet kwetsbaar maar better safe than sorry.
Wie zet z'n SSH nog open naar buiten toe?
Er is niet veel mis met OpenSSH open zetten. Tenzij Jan en alleman zijn eigen zwakkere implementatie gaat schrijven.
Er is geen garantie dat openssh veilig is, indien niet nodig kun je beter geen ssh naar buiten open zetten
Er is geen enkele garantie, maar er is weinig veiliger dan openssh?
Je zet het achter een vpn zoals wireguard (of old school OpenVPN).
Right.. of je nou een jumpbox met OpenSSH of Wireguard er voor zet maakt bijzonder weinig verschil. Zolang je openssh PasswordAuthentication no en KbdInteractiveAuthentication no gebruikt in je config is het verschil wat? Beide oplossingen gebruiken public keys. Daarnaast luisteren wij naar een beperkte set IP adressen. Wireguard is inherent niet een veiliger protocol dan openssh.
Ben het helemaal met je eens. VPN’s zijn er zo ingeslopen bij veel mensen als de holy grail dat je continu in deze discussies raakt.

OpenSSH kan prima aan het internet als jumpbox, via Agent forwarding kan je daarna bij je machines daar achter. Uiteraard alleen met keys, niet met password, precies zoals jij beschrijft.

Zo heb je gewoon meerdere lagen beveiliging en dat werkt goed.
Hmmm...ik denk dat de attack surface van Wireguard kleiner is dan die van OpenSSH. In die zin is het wel inherent veiliger denk ik. Maar een goed dichtgespijkerde SSH is volgens mij uiteindelijk veilig genoeg. Maar daar kun je over van mening verschillen.
Interactieve ssh sessies zijn sowieso tricky. Zeker als je ziet hoeveel default users er op veel Linux distributies al aanwezig zijn. Die worden meestal wel redelijk afgeschermd zonder shell e.d. maar dan nog. Als je nog veel gebruikers aanmaakt met zwakke wachtwoorden begint het wel een dingetje te worden. En toegegeven de drempel daarvoor op wireguard is misschien hoger.
Dat is sarcasme hoop ik...
Nope. Vertel mij eens wat veiliger is?
VPN tunnel? Maar een ssh met key en MFA kan best veilig opgezet worden.
Check, interactieve logins hebben we uit staan. En ook geen ssh op elke box, alleen een openBSD doos als jumpbox. En ondersteunen alleen de PQC ciphers vanuit onze beroepsdeformatie.
Maar OpenSSH heeft ook een sloot aan CVEs, daar zitten ook gaten in die net zo ernstig waren als deze gaten...

En OpenSSH openzetten naar buiten toe is net zo onveilig gebleken de laatste jaren.

Zet een (VPN) tunnel op van remote locatie naar binnen je network en als je echt paranoid wil wezen stel je in dat je dit alleen met bepaalde IPs en certificaten kan...
Mijn OpenSSHs staan gewoon open naar buiten hoor. Root login disabled en fail2ban goed geconfigureerd. Komt u maar ;)
Ja, maar dan staat ssh ook niet 'gewoon' open maar goed beveiligd lijkt me :) (of in ieder geval over nagedacht). Ik zou het niet doen..

[Reactie gewijzigd door Jef61 op 7 september 2026 16:19]

Jep, inderdaad. En om het nog iets lastiger te maken kun je ook password based logins uitzetten en alleen logins obv een cert toestaan.

Ik heb eigenlijk meer vertrouwen in OpenSSH / LibreSSH dan de verschillende VPN protocollen ondanks dat het 'oude' code is..
Zonet de update gedaan. Security voor alles.
Iemand anders bij wie de update faalde?

Bij mij faalde hij bij het opnieuw opstarten, en bleef hij uit/ging niet meer aan(alle lampjes bleven uit). Zodra ik de stekker er opnieuw in deed starte hij weer netjes op alsof er niks aan de hand was, maar niet geüpdatet.

Toen ik de SSD, welke via USB aangesloten zat er uit haalde, lukte de update wel.

Heel raar...
Ssh bereikbaar via het internet zonder knockd (poort knocking) en of fail2ban pure armoede.

Zelf laat ik sshd op het wireguard tunnel addres luisteren waarbij ik ook nog eens een knock secret instel. Dus zonder wg sleutel en ook nog eens knock sequence is er geen toegang tot de ssh server.
Met het huidige AI-geweld lijkt het mij meer de vraag wanneer mijn router aan de beurt is voor overname door een (staats)hacker. Ik kan er moeilijk drie achter elkaar zetten.

Om te kunnen reageren moet je ingelogd zijn