Des attaquants exploitent des vulnérabilités de MikroTik RouterOS pour obtenir le contrôle administratif complet de routeurs lorsque SSH est accessible depuis Internet public.
Des attaques réussies sont observées depuis le 2 septembre au moins, soit un jour avant la publication par MikroTik des versions corrigées de RouterOS. Les administrateurs doivent immédiatement mettre à jour les appareils vulnérables et vérifier si des attaquants ont obtenu un accès avant l’installation des correctifs.
CERT Polska a identifié six vulnérabilités de RouterOS et confirmé que des attaquants utilisent activement une chaîne de deux failles qu’il a baptisée MikroTrick. Cette chaîne peut prendre le contrôle d’un appareil exposé à Internet sans authentification, et le CERT indique que les correctifs publiés stoppent les attaques observées.
Quelles vulnérabilités de MikroTik RouterOS ont été divulguées
Deux des six vulnérabilités ont obtenu un score CVSS de 9,2.
CVE-2026-67276 est un contournement de l’authentification SSH lié à une vérification incomplète des clés publiques RSA. Un attaquant qui connaît un nom d’utilisateur et le module public d’une clé RSA autorisée peut potentiellement s’authentifier sans posséder la clé privée correspondante.
CVE-2026-86060 affecte la manière dont RouterOS gère certains noms d’utilisateur SSH. Un nom d’utilisateur spécialement conçu peut manipuler la politique attribuée à la session ainsi créée et conduire à l’obtention de privilèges administratifs complets.
Les autres failles comprennent CVE-2026-67277 dans le service de test de bande passante, CVE-2026-67278 dans la validation des certificats X.509, CVE-2026-67279 dans l’état d’authentification SSH, et CVE-2026-67281 dans l’interface WebFig. Les descriptions techniques complètes sont disponibles dans l’avis CVE de CERT Polska.
L’alerte concernant l’exploitation active n’identifie pas les deux numéros CVE utilisés dans les attaques observées par le CERT. Les chercheurs de Tolmo ont reproduit indépendamment une prise de contrôle sans authentification au moyen de CVE-2026-67279 et de CVE-2026-86060.
Le scénario ainsi reproduit commence par la faille affectant l’état SSH. Après une nouvelle négociation de clé demandée par le client, CVE-2026-67279 peut permettre à un client non authentifié d’atteindre un état de session qui devrait nécessiter une authentification. CVE-2026-86060 peut ensuite transformer cette session en une session disposant de tous les privilèges RouterOS.
Pour les défenseurs, l’exploitation active et l’exposition à Internet rendent ces vulnérabilités plus prioritaires que ne le laisseraient penser leurs scores individuels, une approche de plus en plus utilisée dans la gestion des vulnérabilités au-delà de CVSS.
Quelles versions de RouterOS contiennent les correctifs
MikroTik répertorie les correctifs dans les versions suivantes :
- 7.25beta3
- 7.24.2
- 7.23.4
- 6.49.21
MikroTik recommande d’effectuer la mise à niveau même lorsqu’une configuration n’est pas immédiatement exposée. La configuration par défaut bloque l’accès SSH depuis Internet, mais les appareils dont les administrateurs ont ouvert SSH à des réseaux non fiables sont les plus clairement exposés aux attaques observées.
Si l’application du correctif ne peut pas être effectuée immédiatement, le CERT recommande de limiter l’accès à SSH, WWW/WWW-SSL et au test de bande passante aux réseaux d’administration de confiance. Les administrateurs doivent également éviter les connexions TLS sortantes et l’utilisation du client SSH intégré de RouterOS depuis un appareil non corrigé.
Réduire le nombre de services d’administration exposés peut limiter immédiatement la surface d’attaque, mais cela ne remplace pas l’installation de la mise à jour de sécurité.
Vérifier les appareils RouterOS à la recherche de signes de compromission
La mise à jour corrige les vulnérabilités connues, mais elle ne permet pas de déterminer si un appareil a été compromis auparavant.
Les versions corrigées de RouterOS vérifient la configuration au démarrage à la recherche de signes connus de modifications non autorisées. Lorsqu’une configuration suspecte est détectée, RouterOS peut désactiver les entrées reconnues, inscrire un message critique dans le journal et attribuer à l’appareil l’état Flagged.
Les administrateurs peuvent vérifier le marqueur avec :
/system/device-mode/print
Un routeur qui n’est pas marqué « Flagged » ne doit pas automatiquement être considéré comme sain. Le CERT indique que ce mécanisme ne détecte que certaines traces de compromission.
Les indicateurs connus comprennent :
login failure for user -2 from <ip> via sshuser <name> added by ssh:-2@<ip>- Un utilisateur disposant de privilèges élevés, nommé de manière inattendue
ops - Une activité d’attaque réussie depuis
82.192.72.4 - Des tentatives d’exploitation depuis
103.102.31.18
Le CERT a relié les attaques réussies qu’il a analysées, notamment la création du compte ops à 82.192.72.4. L’activité remonte au 2 septembre au moins.
Les administrateurs doivent également examiner les utilisateurs, scripts, tâches du planificateur, serveurs proxy, tunnels et autres modifications de configuration qu’ils ne reconnaissent pas. L’absence des indicateurs publiés n’exclut pas une activité non autorisée.
Que faire si un routeur MikroTik a été compromis
Un appareil marqué « Flagged » ou tout autre élément attestant une compromission doit déclencher une réponse à incident, et pas seulement la suppression du compte ou de l’entrée de configuration suspecte.
Isolez le routeur et préservez ses journaux ainsi que sa configuration avant de le réinitialiser. N’effacez pas le marqueur « Flagged » avant d’avoir recueilli les éléments nécessaires à l’enquête.
Une fois ces éléments sécurisés, rétablissez les paramètres d’usine de l’appareil et reconstruisez-le à partir d’une configuration de confiance. Renouvelez les mots de passe, les clés et les autres secrets qui ont pu être accessibles via le routeur.
Ne restaurez pas aveuglément une sauvegarde complète effectuée à partir de l’appareil potentiellement compromis. Des utilisateurs, scripts, tâches planifiées malveillants ou d’autres éléments de configuration non autorisés pourraient être restaurés avec elle.
Le même principe s’applique à la cyberrésilience et à la reprise : remettre un appareil en ligne ne suffit pas si sa configuration ne peut pas elle aussi être considérée comme fiable.
Corriger d’abord, enquêter ensuite
Tout appareil RouterOS affecté doit être mis à jour immédiatement, en donnant la priorité la plus élevée aux appareils dont SSH est exposé à Internet.
Pour les routeurs vulnérables et accessibles publiquement le 2 septembre ou après cette date, la mise à jour doit être suivie d’un examen des journaux et de la configuration. Une mise à niveau réussie empêche les attaques contrées par les correctifs, mais elle ne peut pas annuler l’accès déjà obtenu par un attaquant.
Vérifiez la version de RouterOS, limitez l’accès à l’administration, examinez l’état « Flagged », recherchez les indicateurs publiés et enquêtez sur toute configuration qui ne correspond pas à l’état de référence connu comme sain.
Google a corrigé le sixième zero-day exploité de Chrome de 2026 après avoir confirmé que CVE-2026-85046 était utilisé dans des attaques.