CVE-2026-20131 : Interlock transforme une faille Cisco FMC en accès root

Interlock a exploité une faille critique de Cisco dans Secure Firewall Management Center, une vulnérabilité suivie sous le nom CVE-2026-20131 et notée 10.0 sur l’échelle CVSS. Le résultat est simple, brutal, et tu n’as pas besoin d’être admin pour comprendre l’impact, un attaquant peut exécuter du code à distance en tant que root, sans authentification, sur des appliances non corrigées.

Le point qui pique, c’est le calendrier. D’après les observations d’Amazon, l’exploitation a commencé le 26 janvier 2026, soit 36 jours avant la divulgation publique. Cisco a publié un correctif le 4 mars 2026. Entre-temps, les défenseurs cherchaient une aiguille dans une botte de foin, pendant que le groupe avait déjà sa chaîne d’attaque prête, testée, et industrialisée.

Amazon MadPot repère l’exploitation dès le 26 janvier 2026

Amazon explique avoir repéré l’activité grâce à MadPot, son réseau mondial de capteurs de type honeypot, conçu pour attirer et observer des tentatives d’intrusion. C’est ce type d’infrastructure qui te permet de dater une campagne, pas au doigt mouillé mais à partir de traces d’exploitation vues sur des systèmes exposés. Dans ce cas précis, les signaux remontent au 26 janvier.

CJ Moses, CISO d’Amazon Integrated Security, insiste sur le fait qu’Interlock ne s’est pas contenté d’exploiter une faille connue, le groupe disposait d’un zero-day. Son message est clair, cette avance a offert une fenêtre d’attaque avant que les équipes sécurité ne sachent quoi surveiller. Amazon dit avoir partagé ses constats avec Cisco pour soutenir l’enquête et la protection des clients.

Il y a aussi un angle plus embarrassant pour les attaquants, une erreur d’opsec. Amazon indique qu’une infrastructure mal configurée a exposé la boîte à outils opérationnelle du groupe, ce qui a aidé à comprendre une attaque en plusieurs étapes, avec scripts de reconnaissance, techniques d’évasion et charges utiles. Dit autrement, Interlock a laissé traîner des éléments qui facilitent l’attribution technique et la cartographie de sa méthode.

Cisco corrige CVE-2026-20131 le 4 mars après une note CVSS 10

La vulnérabilité touche Cisco Secure Firewall Management Center et, selon les informations publiées autour de l’incident, elle concerne aussi Security Cloud Control côté gestion des firewalls, indépendamment de la configuration. Le cur du problème, c’est une désérialisation non sécurisée d’un flux Java fourni par l’utilisateur, un classique qui devient catastrophique quand il est exposé via une interface web.

Le scénario décrit par Cisco est celui que tu redoutes, un attaquant non authentifié envoie un objet Java sérialisé spécialement conçu vers l’interface de gestion. Si ça passe, il obtient une exécution de code arbitraire et une élévation de privilèges jusqu’à root. Sur une console de management de firewalls, ça ne signifie pas seulement « une machine compromise », ça peut ouvrir la porte à une prise de contrôle de la supervision, des politiques, et potentiellement des chemins réseau.

Un point mérite une nuance, au moment de la publication initiale de l’avis, Cisco indiquait ne pas avoir de preuve d’exploitation active. Les observations d’Amazon racontent une autre histoire, avec des traces d’exploitation antérieures à la divulgation. Ce décalage arrive, les éditeurs publient avec les éléments confirmés à l’instant T, pendant que les chercheurs corrèlent sur plusieurs semaines. Mais pour toi, côté défense, ça ne change rien, le patch du 4 mars 2026 devait passer en priorité.

La chaîne d’attaque Interlock vise l’exécution Java en root via HTTP

Les détails techniques décrits par Amazon donnent une idée concrète de la mécanique. L’attaque commence par des requêtes HTTP spécialement construites vers un chemin précis de l’application vulnérable, dans le but d’exécuter du code Java. Dans les traces observées, des URL sont embarquées dans la charge, avec un objectif de contrôle et de validation. Ce n’est pas du bruit opportuniste, c’est une exploitation instrumentée.

Une fois le système compromis, le serveur ciblé effectue une requête HTTP PUT vers une infrastructure externe pour confirmer que l’exploitation a réussi, en déposant un fichier généré. C’est un marqueur utile pour les analystes, parce qu’il décrit un « ping » de succès côté attaquant. Après cette étape, des commandes sont envoyées pour récupérer un binaire ELF depuis un serveur distant, qui héberge aussi d’autres outils liés à Interlock.

Ce qui ressort, c’est une logique d’attaque en chaîne, exploitation, confirmation, téléchargement d’outils, puis phases suivantes. Amazon mentionne aussi des scripts de reconnaissance, dont un PowerShell destiné à l’énumération d’environnements Windows, ce qui suggère une volonté d’étendre l’accès au-delà de l’équipement initial. Et il faut le dire, viser une console de management, c’est souvent chercher l’effet domino, tu touches l’outil qui administre, pas seulement une machine isolée.