MikroTik CVE-2026-14227 : votre clé privée WireGuard peut être lue, et désactiver l'API n'annule rien

Le 30 juillet 2026, la CISA a publié l'avis ICSA-26-211-01 couvrant la CVE-2026-14227, une faille de gestion de session dans l'API de MikroTik RouterOS. La conséquence rapportée est assez précise pour concerner quiconque auto-héberge un tunnel : la clé privée WireGuard du routeur peut être lue en clair par une session API qui ne devrait pas disposer de ce niveau d'accès.

La plupart des reprises s'arrêtent au titre. Or ce qui décide de ce que vous devez faire se trouve plus loin.

En quoi consiste la faille

Le service API de RouterOS écoute sur le port TCP 8728 en clair et 8729 en TLS. La vulnérabilité est classée expiration de session insuffisante : les sessions actives conservent le jeu de permissions qu'elles détenaient à leur ouverture, si bien que réduire les droits d'un utilisateur ou laisser une session expirer ne prend pas nécessairement effet sur une connexion déjà établie.

Il en résulte un décalage de privilèges. Une session qui aurait dû être rétrogradée continue de lire une configuration qu'elle ne devrait plus voir, et sur un routeur qui termine un tunnel WireGuard, cette configuration contient la clé privée statique.

Pourquoi le score induit en erreur

La gravité publiée est modérée : CVSS 4.0 base 6,9 et CVSS 3.1 base 4,9 selon la fiche Rapid7. Plusieurs médias ont parlé de faille critique. Ce n'est pas ce que dit la notation, et reprendre l'adjectif le plus fort ne vous aiderait pas.

Mais lire le chiffre comme s'il disait tout est l'erreur inverse. Un score CVSS mesure la difficulté d'exploitation et la portée. Il ne mesure pas la permanence de la conséquence. Une faille notée moyenne qui expose un jeton de session renouvelable est une mauvaise après-midi. Une faille notée moyenne qui expose une identité cryptographique statique appartient à une autre catégorie de problème, parce que l'exposition ne se périme pas.

Ce que l'on saute : la clé n'expire pas

C'est le cœur pratique du sujet. Dans WireGuard, chaque pair détient une paire de clés statique, et c'est cette identité que l'autre côté fait confiance. Un mot de passe se change, un jeton expire, une session meurt. Une clé privée posée dans la configuration d'un routeur ne fait rien de tout cela d'elle-même.

La séquence que suivent la plupart des administrateurs, désactiver l'API et considérer que c'est réglé, ferme la porte sans changer la serrure. Si la clé était lisible pendant que l'API était exposée, désactiver l'API ensuite ne la dé-fuit pas. La rotation est l'étape qui rétablit réellement la relation de confiance, et c'est celle que l'on reporte le plus souvent parce qu'elle oblige à toucher chaque pair.

Ce que la confidentialité persistante couvre, et ce qu'elle ne couvre pas

Il faut être précis, car la formule déchiffrement de tout le trafic associé a été largement reprise et se lit facilement comme pire qu'elle ne l'est.

La poignée de main de WireGuard dérive des clés de session éphémères, ce qui donne au protocole sa confidentialité persistante. Un attaquant qui détient votre clé privée statique, et rien d'autre, ne peut pas déchiffrer rétroactivement le trafic capturé auparavant. Cette propriété reste intacte.

Ce que la clé statique lui donne, c'est une identité. Il peut se présenter comme ce pair, mener des poignées de main à leur terme et intercepter activement de nouvelles sessions. En pratique, cela signifie usurpation et interception à venir, pas une archive lisible du passé. C'est sérieux, mais c'est une menace différente, et la distinction change votre réponse : vous n'évaluez pas les dégâts sur du trafic ancien, vous révoquez une identité.

Quoi faire, dans l'ordre

Établissez si l'API était seulement joignable. Si le service était désactivé, ou lié uniquement à une interface qu'un attaquant ne pouvait pas atteindre, votre exposition est théorique. Vérifiez avant de paniquer et avant de reconstruire quoi que ce soit.

Désactivez le service API si vous n'en avez pas besoin. C'est le contournement vers lequel pointe l'avis, et sur une installation domestique ou à administrateur unique, l'API est fréquemment activée sans jamais servir.

Déconnectez les utilisateurs quand vous réduisez leurs droits. La consigne de MikroTik est qu'un utilisateur dont les permissions sont réduites doit être complètement déconnecté pour que la nouvelle politique s'applique. Cela mérite d'entrer dans votre procédure, pas d'être fait une seule fois, car c'est précisément le comportement que la faille exploite.

Faites tourner les clés si l'exposition était plausible. Générez une nouvelle paire sur le routeur, mettez à jour chaque pair avec la nouvelle clé publique et supprimez l'ancienne. C'est l'étape fastidieuse, et la seule qui mette fin à l'exposition plutôt que de la suspendre.

Ne vous fiez pas à une plage de versions lue de seconde main. La presse dit que toutes les versions avec l'API activée sont concernées ; la fiche Rapid7 n'énonce aucune plage. Vérifiez votre propre équipement plutôt que de vous déclarer à l'abri parce qu'un numéro lu dans un article ne correspondait pas au vôtre.

Le point plus large pour l'auto-hébergement

Faire tourner son propre tunnel signifie que la clé vit sur du matériel que vous contrôlez, ce qui est exactement l'attrait et exactement l'exposition. La sécurité d'un VPN auto-hébergé est celle de la machine qui le fait tourner, y compris les interfaces d'administration dont vous aviez oublié qu'elles écoutaient.

Ce n'est pas un argument contre l'auto-hébergement, c'est un argument pour traiter le plan d'administration comme faisant partie du VPN. Si vous auditez votre propre installation, notre guide de dépannage du handshake WireGuard explique comment lire l'état des pairs, et le glossaire du VPN auto-hébergé définit les termes employés ci-dessus.

En bref

La CVE-2026-14227 est notée moyenne et expose quelque chose qui n'expire pas. Vérifiez si votre API était joignable, désactivez-la si vous ne vous en servez pas, déconnectez les utilisateurs quand leurs droits changent, et faites tourner la clé si l'exposition était plausible. La confidentialité persistante protège votre trafic passé ; rien ne protège une identité que vous laissez en place après qu'elle a été lue.