MikroTik RouterOS : deux failles sans correctif sur l'API, à fermer si elle est exposée

CISA a publié coup sur coup, les 28 et 30 juillet, deux avis distincts sur MikroTik RouterOS, le système d'exploitation qui équipe les routeurs de la marque et sa version virtuelle Cloud Hosted Router (CHR). Les deux failles visent le service API d'administration, celui que les routeurs MikroTik exposent pour être pilotés à distance par un logiciel de gestion ou un script. Aucune des deux n'a de correctif à ce jour.

MikroTik est un choix fréquent pour les petites structures qui veulent un routeur ou un pare-feu costaud sans payer le tarif d'un Fortinet ou d'un Cisco. C'est ce qui rend ces deux avis pertinents pour une PME. Il y a de bonnes chances qu'un boîtier MikroTik tourne quelque part sur le réseau, parfois installé par un prestataire il y a plusieurs années et jamais revu depuis.

La première faille : pas de frein au brute force

CVE-2026-16347, notée 8.8 sur 10 en CVSS v3, touche l'authentification de l'API RouterOS. Selon l'avis CISA, le système "ne met en place ni limitation de débit, ni blocage de compte, ni restriction par adresse source" efficace contre les tentatives de connexion répétées. Un délai fixe existe bien entre deux tentatives sur une même connexion, mais il se contourne en ouvrant plusieurs connexions en parallèle : le nombre total de tentatives par seconde reste donc élevé.

Concrètement, un mot de passe administrateur de faible longueur, exposé sur Internet via l'API, peut être deviné par un outil de brute force sans déclencher de protection. Un fil de discussion sur le forum officiel MikroTik mentionne que RouterOS 7.20 a introduit un délai de connexion, amélioré ensuite en 7.21.4 (branche long terme) et 7.22 (branche stable). Plusieurs utilisateurs y notent toutefois que cette pause reste insuffisante face à une attaque un peu sérieuse.

La seconde faille : la clé WireGuard en clair

CVE-2026-14227 est plus grave dans ses conséquences mais plus étroite dans ses conditions. Elle permet à quelqu'un qui dispose déjà d'un accès API à faibles privilèges d'extraire la clé privée WireGuard du routeur en clair. Avec cette clé, il peut se faire passer pour le routeur sur le VPN et déchiffrer le trafic qui y transite. L'avis CISA la classe en CWE-613 (expiration de session insuffisante) : la gestion des sessions de l'API ne réévalue pas les droits d'un utilisateur quand son groupe change ou après une période d'inactivité. Une session ouverte avec des droits élevés peut donc les conserver plus longtemps qu'elle ne le devrait.

Cette faille suppose donc un accès API préalable : soit par une attaque réussie de la première faille, soit par des identifiants déjà compromis ailleurs. Elle affecte, selon CISA, toutes les versions de RouterOS où l'API est active. Le score CVSS v3 attribué par MikroTik, 4,9, reflète cette condition d'accès préalable ; il ne faut pas le lire comme une faille mineure, mais comme une faille dont la gravité dépend entièrement de ce qui la précède.

Ce qui existe comme parade, faute de correctif

MikroTik n'a publié aucun correctif à la date de cet article pour l'une ou l'autre de ces CVE. CISA relaie les recommandations suivantes, à appliquer par configuration :

• Ne jamais exposer l'API (ports 8728 en clair, 8729 chiffré) directement sur Internet. Si un accès distant est nécessaire, le faire passer par un VPN.
• Dans le menu /ip service, restreindre l'adresse d'écoute de l'API au réseau local ou à une liste d'adresses de confiance.
• Configurer le délai entre tentatives de connexion invalides sur toutes les valeurs disponibles (l'avis cite une plage de 0,1 à 0,5 seconde) pour tous les services, API comprise.
• Se connecter une première fois uniquement depuis le port LAN, avant de configurer le reste des accès selon les besoins réels.
• Remplacer les mots de passe courts ou par défaut par des mots de passe longs générés aléatoirement, pour rendre le brute force impraticable même sans blocage automatique.

Ce qu'il faut faire aujourd'hui

Si un routeur ou un boîtier MikroTik est en service, la première chose à vérifier est simple : ouvrir /ip service sur l'interface RouterOS et regarder si l'API (port 8728 ou 8729) écoute sur une adresse accessible depuis Internet plutôt que sur le réseau local uniquement. Si le boîtier a été installé par un prestataire, c'est le bon moment pour lui demander de faire cette vérification et de fermer l'accès si rien ne le justifie. En l'absence de correctif, la seule protection réelle contre ces deux failles est de ne jamais laisser l'API RouterOS visible depuis l'extérieur du réseau.