MikroTik corrige le détournement de routeurs via le SSH exposé sur Internet
CERT Polska révèle que des attaquants prennent le contrôle administratif complet de routeurs MikroTik dont le SSH est accessible depuis Internet, sans authentification. Mettez à jour RouterOS et auditez la configuration avant toute remise en service.
5 septembre 2026. CERT Polska publie un avertissement d’attaque visant des routeurs MikroTik dont le service SSH est accessible depuis Internet. Des attaques réussies remontent au moins au 2 septembre 2026, et l’éditeur a déjà diffusé des correctifs RouterOS dans plusieurs canaux. Pourquoi c’est important : un routeur est le point de passage de tout le trafic d’un réseau — le compromettre sans authentification revient à offrir à l’attaquant une position d’observateur et de pivot sur l’ensemble des flux.
Un accès administrateur sans authentification
Les attaquants exploitent le SSH du routeur lorsqu’il est joignable depuis Internet, pour obtenir le contrôle administratif complet de l’appareil, sans authentification. CERT Polska baptise la combinaison de deux failles « MikroTrick », sans pour autant identifier publiquement les deux vulnérabilités qui composent la chaîne, ni expliquer précisément comment elles se combinent pour produire l’accès root.
Ce silence technique ne change rien à l’urgence. L’avertissement ne mentionne ni nombre de victimes, ni identité des attaquants, au moment de la revue menée par The Hacker News le 6 septembre 2026. Le point décisif est ailleurs : l’attaque réussit sans vol préalable de mot de passe, ce qui signifie que la simple exposition du port de gestion suffit à transformer un routeur en machine contrôlée.
Le statut de zero-day reste non tranché. Les notes de version de 7.25beta3 portent une date de changelog du 2 septembre, tandis que les premiers correctifs ont été annoncés le 3 septembre. Cette chronologie ne permet pas d’établir si un correctif était public avant le début des attaques.
Les versions concernées et les correctifs
CERT Polska liste les plages affectées et les versions qui corrigent l’attaque observée. Le tableau suivant reprend l’essentiel des versions publiées par MikroTik.
- RouterOS 6, de 6.0.0 à 6.49.20 inclus : mise à jour vers 6.49.21 (correctif de sécurité de la branche 6).
- RouterOS 7, de 7.0.0 à 7.23.3 inclus : mise à jour vers 7.23.4, ou 7.23.5 sur le canal long-term.
- RouterOS 7.24 à 7.24.1 : mise à jour vers 7.24.2 (correctif de sécurité du canal stable).
- Canal development : le correctif est intégré à 7.25beta3.
Un détail de version compte : 7.23.5 corrige une régression IPv6 DHCP introduite par 7.23.4, tout en conservant le correctif de sécurité. Sur le canal long-term, privilégiez donc 7.23.5 plutôt que 7.23.4.
La surface d’exposition : SSH, WWW, bandwidth-test
Le pare-feu par défaut de MikroTik bloque l’accès public aux ports de gestion tant que ses règles restent intactes. Le problème survient quand cette protection est désactivée ou modifiée — une pratique courante chez ceux qui administrent leurs routeurs à distance sans passer par un VPN.
En attendant la mise à jour, CERT Polska recommande de désactiver les services exposés ou de les restreindre aux réseaux d’administration de confiance, en particulier SSH, WWW/WWW-SSL et bandwidth-test. Il conseille aussi de ne pas initier de connexion TLS ni d’utiliser les clients SSH intégrés à RouterOS depuis un appareil non corrigé — ces restrictions provisoires couvrent un ensemble plus large de vulnérabilités et ne remplacent pas la mise à jour.
# Désactiver le SSH exposé en attendant la mise à jour
/ip service disable ssh
/ip service disable www,www-sslLe message est sans ambiguïté : tant que le routeur n’est pas corrigé, la seule posture sûre est de retirer du réseau public tout service de gestion.
Ce qu’il faut inspecter après la mise à jour
La mise à jour ne suffit pas. Un routeur déjà compromis le reste après correction, car l’attaquant a pu y installer des scripts, des comptes ou des règles persistants. CERT Polska recommande plusieurs vérifications après le redémarrage.
D’abord, RouterOS possède un statut « Flagged » : il se déclenche quand les contrôles de démarrage détectent une configuration suspecte, désactivent les entrées concernées et restreignent certaines fonctions. La commande ci-dessous affiche ce statut.
/system device-mode printEnsuite, examinez les journaux et la configuration à la recherche de comptes inconnus, de scripts ou de tout changement non reconnu. CERT Polska pointe deux signaux concrets : des comptes « ops » hautement privilégiés inattendus, et des journaux de création de compte contenant « ssh:-2@ ».
/user print
/system script print
/log print where message~"ssh:-2@"Le marqueur ssh:-2@ mérite une explication : il signale une connexion SSH entrante qui a abouti à la création d’un compte par un chemin non interactif — précisément le profil d’une automatisation d’attaque plutôt que d’une administration humaine. Sa présence dans les journaux est un indicateur fiable de compromission, même en l’absence d’autre anomalie visible.
Si l’avertissement, les journaux ou la configuration laissent penser à une compromission, ne videz pas le statut Flagged avant d’avoir préservé les preuves et terminé l’analyse.
La marche à suivre en cas de compromission
Quand la compromission est établie, CERT Polska impose une séquence stricte, dans cet ordre.
- Isoler le routeur du réseau et préserver ses journaux et sa configuration avant toute réinitialisation.
- Restaurer les réglages d’usine et reconstruire avec une configuration de confiance vérifiée — ne pas restaurer aveuglément une sauvegarde complète issue de l’appareil potentiellement compromis.
- Changer les mots de passe, clés et autres secrets utilisés dans l’environnement, car ils ont pu être collectés pendant la compromission.
Cette séquence vaut pour toute compromission d’un équipement réseau, pas seulement MikroTik : un routeur contrôlé a pu observer du trafic, voler des identifiants et pivoter vers le reste du réseau. Le traiter comme un simple « appareil à reflasher » sous-estime le périmètre du sinistre.
Pourquoi MikroTik est une cible privilégiée
Les routeurs MikroTik ne sont pas visés par hasard. Leur rapport puissance/prix, leur présence massive chez les FAI et les opérateurs sans fil, et la proportion d’installations laissées dans leur configuration par défaut en font une cible de choix pour les botnets depuis des années.
En 2018, la faille CVE-2018-14847 dans le service Winbox permettait de lire des fichiers sensibles du routeur. Elle a été exploitée à grande échelle : plus de 200 000 appareils ont été infectés avec des mineurs de cryptomonnaie et transformés en proxies SOCKS.
En 2021, le botnet Meris — assemblé à partir d’environ 200 000 routeurs MikroTik — a lancé des attaques par déni de service d’une intensité record, frappant notamment Yandex.
Cette récurrence change la lecture de l’épisode en cours. Une compromission MikroTik n’est presque jamais un incident isolé : les appareils infectés rejoignent des infrastructures persistantes, réutilisées pour des attaques ultérieures. D’où l’importance de ne pas se contenter de patcher, mais de vérifier l’état réel de chaque appareil exposé avant de le remettre en service.
Verdict
Si vous exposez un routeur MikroTik en SSH sur Internet, mettez à jour RouterOS vers une version corrigée dès maintenant — 6.49.21, 7.23.5, 7.24.2 ou 7.25beta3 selon votre canal — puis désactivez l’exposition directe des services de gestion.
Si le routeur était exposé depuis le 2 septembre au moins, ne vous contentez pas de patcher : isolez, préservez les journaux, inspectez les comptes et scripts, et ne reconstruisez qu’à partir d’une configuration de confiance.
Si vous voulez éliminer la classe de risque, arrêtez d’administrer vos équipements réseau en SSH direct depuis Internet : un VPN ou un réseau de gestion dédié ferme la porte que « MikroTrick » exploite, quelle que soit la prochaine faille.