MikroTrick : deux failles de RouterOS permettent de prendre le contrôle de routeurs MikroTik exposés

Une chaîne de vulnérabilités dans RouterOS de MikroTik permet à un attaquant disposant seulement d'un accès réseau au service SSH d'un routeur d'en prendre entièrement le contrôle, et l'exploit n'est plus théorique. Le CERT Polska, l'équipe nationale polonaise de réponse aux incidents informatiques, a découvert six failles dans RouterOS, a coordonné leur divulgation avec MikroTik et a confirmé le 5 septembre que deux d'entre elles sont combinées dans des attaques réelles. L'équipe a donné un nom à cette chaîne : MikroTrick.

À lire aussi: Une faille d'authentification de Rejetto HFS trouvée par IA attire des tentatives d'exploitation · Google corrige CVE-2026-58704, une faille zero-day du modem des Pixel exploitée activement.

Les deux failles au cœur de la chaîne portent un score CVSS de 9,2. MikroTik a livré les correctifs avant la divulgation publique, d'abord le 3 septembre dans RouterOS versions 6.49.21, 7.23.4 et 7.24.2, ainsi que la compilation 7.25beta3. La CISA a ajouté les deux failles RouterOS à son catalogue des vulnérabilités exploitées connues le 10 septembre, donnant aux agences fédérales civiles jusqu'au 13 septembre pour corriger ou documenter des contrôles compensatoires. Le même lot concernait ConnectWise ScreenConnect et JFrog Artifactory.

L'ampleur de la cible est l'élément qui devrait faire s'arrêter le lecteur. La Shadowserver Foundation a compté environ 122 500 appareils MikroTik dont le SSH était accessible depuis internet lors d'une seule fenêtre de balayage de 24 heures, le 5 septembre. Ce chiffre n'est pas un décompte des appareils vulnérables, puisqu'aucune vérification de version n'a été faite. C'est un décompte des appareils qui répondaient sur le port dont la chaîne d'attaque a besoin.

Ce que font les deux failles

La première moitié de MikroTrick, référencée CVE-2026-67276, est un contournement d'authentification dans le serveur SSH de RouterOS. Lors de la validation de la clé publique RSA d'un utilisateur, RouterOS ne comparait qu'une partie de la clé : son type et son module public. Il ne comparait pas la clé entière, ignorant donc l'exposant public.

La distinction paraît théorique jusqu'à ce que l'on considère ce qu'elle autorise. Un attaquant qui connaît un nom d'utilisateur et le module de la clé autorisée de cet utilisateur peut construire une autre paire de clés partageant ce module, fixer son exposant public à 1 et produire une signature que RouterOS accepte. Aucune clé privée n'est nécessaire, car le serveur n'a jamais vérifié la partie de la clé qui aurait rendu la falsification impossible.

La seconde moitié, CVE-2026-86060, transforme le point d'appui obtenu par le contournement en contrôle administratif complet. RouterOS gérait mal les noms d'utilisateur SSH commençant par un caractère qu'il aurait dû rejeter. Une valeur fabriquée comme -2 atteignait un ancien assistant de connexion qui lisait le tiret initial comme le début d'une option de ligne de commande plutôt que comme un nom d'utilisateur littéral. En fournissant un nom d'utilisateur ainsi formé, un attaquant pouvait modifier le masque de politiques de confiance du routeur et aboutir à une session pleinement privilégiée.

Aucune des deux failles n'exige un mot de passe, un compte valide ou une interaction du propriétaire de l'appareil. Le duo a seulement besoin que SSH soit joignable, ce qui est exactement la façon dont beaucoup d'administrateurs le laissent pour gérer un routeur installé dans un endroit peu commode.

Une troisième faille, et trois autres

Le CERT Polska a divulgué six problèmes au total. Le troisième plus grave est CVE-2026-67277, une faille d'authentification manquante dans le service bandwidth-test, ou btest. Une connexion non authentifiée pouvait entrer dans un état réservé aux utilisateurs connectés. Combinée à une fuite de données non initialisées d'un tampon de paquets du noyau et à un dépassement d'entier négatif dans la validation de taille, elle peut exposer la mémoire du noyau ou faire redémarrer l'appareil.

Trois failles de moindre gravité complètent l'ensemble : un problème dans le client SSH, une faiblesse de validation de signature dans le traitement des certificats X.509 et une faille de divulgation d'informations dans l'interface WebFig. Aucune ne fait partie de la chaîne de prise de contrôle observée, mais elles élargissent la surface que les administrateurs doivent appréhender.

Les traces laissées par les attaquants

Le CERT Polska a rattaché la compromission confirmée à des artefacts concrets. Les journaux RouterOS des appareils attaqués contiennent des entrées ressemblant à un échec de connexion pour l'utilisateur -2, suivies d'un ajout d'utilisateur attribué à ssh:-2@ et à l'adresse de l'attaquant. L'agence a aussi signalé un compte hautement privilégié inexplicable nommé ops comme signe d'une exploitation réussie.

Les attaques qu'elle a pu confirmer, y compris la création de ce compte ops, provenaient de 82.192.72.4, une adresse d'une plage Leaseweb, active au moins depuis le 2 septembre, trois jours avant l'avis public. Une seconde adresse, 103.102.31.18, a servi aux tentatives d'exploitation. La charge observée sur les systèmes compromis était un binaire BusyBox d'architecture MIPS ressemblant fortement à une version officielle de BusyBox de 2010, livré avec des scripts Python et shell, selon la note de recherche de la Cloud Security Alliance. Réutiliser un outil public vieux d'une décennie plutôt qu'un logiciel malveillant sur mesure indique une priorité donnée à la rapidité plutôt qu'à la discrétion, ce qui correspond à un balayage à l'échelle d'internet plutôt qu'à une liste de cibles choisies à la main.

La chronologie est inconfortable. L'exploitation était en cours le 2 septembre. MikroTik a livré les correctifs le 3 septembre. La divulgation publique est arrivée le 5 septembre. Pendant plusieurs jours, une prise de contrôle non authentifiée fonctionnelle a existé contre des appareils qui n'avaient aucun numéro CVE à rechercher ni aucun avis à lire.

Pourquoi les équipements de périphérie et de gestion restent pris pour cible

RouterOS est un incontournable en périphérie de réseau. Les fournisseurs d'accès internet, les petites et moyennes entreprises et les passionnés de réseau l'utilisent parce que le matériel est bon marché et les options de configuration profondes. Ces mêmes qualités rendent les appareils attrayants : ils se trouvent sur le périmètre, tout ce qui se trouve derrière leur fait confiance et ils sont souvent installés une fois puis laissés sans surveillance.

Cette combinaison s'est déjà manifestée. Une enquête Censys de 2023 citée par la note de la CSA a compté près de 450 000 hôtes exposant encore des interfaces de configuration RouterOS vulnérables des mois après un correctif critique antérieur. Les appareils dans lesquels personne ne se connecte sont aussi des appareils que personne ne corrige selon un calendrier, ce qui allonge la fenêtre durant laquelle une faille connue reste utile à un attaquant.

La comparaison avec les affaires GitLab et Artifactory des mêmes semaines est éclairante. Dans chaque cas, le logiciel vulnérable se trouvait à l'intérieur du périmètre, détenait des identifiants ou contrôlait le trafic, et était corrigé à un rythme plus lent que les applications exposées à internet qui attirent davantage l'attention. Les plans de gestion sont dignes de confiance par conception. Qui en atteint un hérite d'une grande partie de cette confiance.

Les réserves à garder en tête

Le contournement d'authentification de MikroTrick est grave, et sa portée pratique est plus étroite que ne le suggère le seul score CVSS. La clé falsifiée doit partager un module avec une vraie clé autorisée, ce qui signifie que l'attaquant doit connaître ce module. Les clés réutilisées sur une flotte d'appareils, publiées par accident ou générées avec des paramètres faibles rendent cela plus facile. La note de la CSA rapporte que la technique a été reproduite de manière fiable contre des clés RSA générées avec un faible exposant public, tandis que les clés utilisant l'exposant courant 65537 n'étaient pas uniformément sensibles. Les organisations devraient y voir une raison d'inventorier et de régénérer les clés SSH autorisées sur les appareils RouterOS, et une raison de ne pas supposer que tout routeur exposé est trivialement exploitable.

La seconde réserve concerne le contrôle de compromission du fournisseur. RouterOS analyse désormais sa configuration au démarrage, désactive les entrées suspectes reconnues, écrit un message critique dans le journal et marque l'appareil comme Flagged. Le CERT Polska précise explicitement que ce mécanisme ne détecte que certaines traces. L'absence de la marque n'est pas la preuve qu'un appareil est propre. Les administrateurs devraient traiter la marque comme un signal parmi d'autres, et non comme un certificat de bonne santé.

Ce que les administrateurs devraient faire maintenant

Les conseils du CERT Polska sont directs, et l'ordre compte.

• Mettez à niveau RouterOS immédiatement vers 6.49.21, 7.23.4, 7.24.2 ou la compilation 7.25beta3. Corrigez d'abord ; le reste relève du triage.
• Si une mise à niveau immédiate est impossible, désactivez SSH, WWW/WWW-SSL et le serveur bandwidth-test, ou limitez chacun à des réseaux de gestion de confiance. Évitez d'initier des connexions TLS depuis un appareil non corrigé ou d'utiliser son client SSH intégré vers des hôtes non fiables.
• Vérifiez la sortie de /system/device-mode/print pour la marque Flagged, et examinez /system history et la liste des utilisateurs à la recherche de l'artefact -2, d'un compte ops inattendu ou d'autres connexions inconnues.
• Inspectez la configuration à la recherche d'utilisateurs, de scripts, de tâches du planificateur, de serveurs proxy et de tunnels inconnus.
• Traitez comme compromis tout appareil portant la marque Flagged, présentant des changements de configuration inexpliqués ou des scripts non reconnus. Isolez-le, préservez ses journaux et sa configuration, reconstruisez-le à partir d'une configuration saine connue et renouvelez mots de passe, clés et autres secrets. Ne restaurez pas aveuglément une sauvegarde complète issue d'un appareil suspect.

Ce qu'il faut surveiller

La question immédiate est l'adoption. Les correctifs sont disponibles et l'exploitation est documentée, mais la population à risque est vaste et lente à bouger. Le décompte de Shadowserver suggère que le nombre d'appareils avec SSH ouvert se compte en centaines de milliers, et la date limite de la CISA ne s'applique qu'aux agences fédérales. Les preuves de compromission devraient suivre les corrections avec retard, car un appareil reconstruit sur place sans inspection peut transporter un intrus plus loin.

Un second fil à suivre est la manière dont les failles ont été trouvées. Le CERT Polska attribue leur découverte à Sławomir Rozbicki et aux modèles GPT-5.5-cyber et GPT-5.6-sol, utilisés dans un laboratoire à base d'agents sous supervision des chercheurs. Si la recherche assistée par modèles continue de trouver de telles chaînes dans les micrologiciels de périphérie, la pression sur les fournisseurs pour réduire l'écart entre un correctif privé et des conseils publics exploitables augmentera, et non l'inverse.

Image de couverture : « MikroTIK hAP Lite and RouterBOARD 750 » de Stacatto, Wikimedia Commons, CC BY-SA 4.0.