Les routeurs MikroTik sont partout : PME, agences, fournisseurs d'accès locaux, laboratoires. Début septembre 2026, une série de failles baptisée « MikroTrick », dont la CVE-2026-67276, a été signalée comme exploitée activement. Cet article a un but de sensibilisation et d'aide au correctif : il explique ce que ces vulnérabilités permettent, comment savoir si vous êtes concerné, comment vous protéger, et dans quel cadre il est légitime de vérifier une exposition. Il ne contient aucun mode opératoire d'attaque.
Avertissement : ForenShield n'est pas responsable de l'usage que vous faites de ces informations. Tester ou attaquer un équipement qui ne vous appartient pas, sans autorisation écrite, est une infraction pénale dans la plupart des pays.
La CVE-2026-67276 et sa publication
Les vulnérabilités ont été documentées par le CERT Polska, qui parle d'une exploitation observée dès le 2 septembre 2026, soit un jour avant la publication des versions corrigées. Le bulletin officiel de MikroTik confirme les correctifs et les recommandations du constructeur.
Les trois failles principales
| CVE | Nature | Conséquence |
|---|---|---|
| CVE-2026-67276 | Comparaison incomplète de la clé publique RSA lors de l'authentification SSH par clé | Un attaquant non authentifié peut ouvrir un canal de commande SSH sous l'identité d'un utilisateur cible, sans posséder sa clé privée |
| CVE-2026-86060 | Mauvaise gestion des arguments dans le chemin de connexion SSH (noms d'utilisateur commençant par un caractère interdit) | Modification du masque de politique de confiance de RouterOS et obtention d'un accès |
| CVE-2026-67277 | Connexion « associée » du service de test de bande passante (btest) acceptée avant la fin de l'authentification de la session principale | Dépassement d'entier (underflow) et déni de service |
Pour la première, le défaut tient à une vérification trop légère : RouterOS ne compare pas la clé publique RSA dans son intégralité pour rattacher une demande d'authentification à la clé d'un utilisateur autorisé. Cette faille est la plus grave, car elle touche l'authentification elle-même. Le CERT Polska la rapproche de la CVE-2026-86060 dans une chaîne d'attaque qui vise les routeurs dont le service SSH est joignable depuis Internet.
À retenir : le risque est maximal lorsque SSH est ouvert sur Internet. Les équipements uniquement joignables depuis un réseau d'administration isolé sont beaucoup moins exposés, mais doivent être corrigés quand même.
Pour comprendre comment se lit la gravité de ces failles, consultez notre guide sur le score CVSS. La CVE-2026-67276 est évaluée à 9,2 selon les sources publiées à ce jour.
Versions concernées et versions corrigées
Sont vulnérables les versions de RouterOS antérieures aux versions ci-dessous :
| Branche | Version corrigée |
|---|---|
| 6.x (long terme) | 6.49.21 |
| 7.x (long terme) | 7.23.4 |
| 7.x (stable) | 7.24.2 |
Une version 7.25 bêta 3 contient aussi le correctif. Une autre faille du même ensemble (CVE-2026-67278) a été traitée dans la 7.24.3 : préférez donc la version stable la plus récente disponible.
Comment corriger et se protéger
Voici l'ordre d'action recommandé :
- Fermer l'exposition avant tout. Le constructeur demande de ne pas laisser SSH ouvert vers des réseaux non fiables. Limitez l'accès à des adresses de confiance dans le pare-feu, ou passez par un VPN comme WireGuard plutôt que d'exposer le port de gestion.
- Mettre à jour RouterOS vers l'une des versions corrigées, via la fonction « Check for updates », puis redémarrer.
- Inspecter la configuration après la mise à jour. Recherchez les scripts, comptes utilisateurs, tâches planifiées ou règles que vous ne reconnaissez pas.
- Vérifier l'état « Flagged ». RouterOS signale lui-même un appareil qu'il juge compromis. Consultez les journaux système pour des entrées critiques.
- Renouveler les secrets si un doute existe : clés SSH autorisées, mots de passe d'administration, secrets VPN et Wi-Fi.
- Désactiver les services inutiles (btest, WebFig exposé, Telnet, FTP) et restreindre chaque service à ses réseaux légitimes.
Un routeur exposé pendant la période d'exploitation, puis simplement mis à jour, peut déjà avoir été compromis : la mise à jour ferme la porte, mais ne nettoie pas ce qui a été déposé avant. En cas de doute sérieux, une réinitialisation complète et une reconfiguration à partir d'une sauvegarde saine sont plus sûres.
Quand est-il légitime de tester la vulnérabilité ?
Un dépôt public, mikrotrick-poc, publie une démonstration de la CVE-2026-67276. Son auteur précise qu'elle est réservée à un usage en laboratoire. La règle est simple : tester est acceptable uniquement dans l'un de ces cas.
- Votre propre équipement, dans un laboratoire isolé, sans lien avec un réseau de production ni avec Internet.
- Un test d'intrusion contractualisé, avec un périmètre écrit, des dates précises et l'accord signé du propriétaire des systèmes.
- Un exercice de formation (CTF, plateforme de laboratoire) conçu pour cela.
Dans tous les autres cas, n'essayez pas. Se connecter à un routeur tiers sans autorisation constitue un accès frauduleux à un système d'information, même « pour vérifier » ou « pour prévenir ». Si vous découvrez qu'un équipement tiers est vulnérable, la démarche responsable consiste à alerter son propriétaire ou le CERT compétent, sans tenter d'y accéder.
Pour vérifier votre propre exposition sans exploiter quoi que ce soit, il suffit de contrôler la version de RouterOS installée et de tester, depuis l'extérieur de votre réseau, si les ports SSH et btest répondent. Un port ouvert vers Internet est déjà une raison suffisante d'agir.
Ce que ces failles rappellent
Cet épisode illustre trois principes de durcissement souvent négligés :
- Ne pas exposer les interfaces d'administration : SSH, WebFig et les services de test n'ont pas vocation à être joignables depuis Internet.
- Suivre les avis de sécurité du constructeur, et abonner une adresse d'équipe aux annonces MikroTik pour être averti le jour de la publication.
- Inventorier les équipements réseau, y compris les petits routeurs de succursales, souvent oubliés dans les campagnes de correctifs.
Pour retrouver le détail technique et l'état de vos versions, la base CVE de ForenShield permet de rechercher une vulnérabilité par identifiant, et le calculateur CVSS aide à qualifier la criticité selon votre contexte.