Deux RCE root non authentifiées frappent les appliances FatPipe en fin de vie
Les appliances SD-WAN et VPN FatPipe MPVPN, WARP et IPVPN en firmware 10.1.2r60p100, en fin de vie, exposent une injection de commandes et un débordement de tampon qui donnent un shell root sans authentification. Montez vers une release supportée et restreignez l’interface de gestion, désactivée par défaut.
17 septembre 2026. Deux avis publiés dans la NVD documentent une injection de commandes et un débordement de tampon dans les appliances FatPipe MPVPN, WARP et IPVPN tournant sur le firmware 10.1.2r60p100. 17 septembre 2026. Les deux failles, CVE-2026-90822 et CVE-2026-90823, mènent à une exécution de code à distance en root sans authentification, toutes deux notées CVSS 9,8. 17 septembre 2026. Le firmware concerné est en fin de vie : aucun correctif ne viendra, seule une montée vers une release supportée résout le problème. Pourquoi c’est important : une appliance VPN ou SD-WAN en fin de vie posée en bordure de réseau est déjà un risque par principe — ici, elle ajoute deux chemins directs vers root.
Deux chemins vers root dans une appliance en fin de vie
La première faille, CVE-2026-90822, est une injection de commandes OS (CWE-78) dans le démon xtremed. Un attaquant distant non authentifié qui atteint l’interface de gestion peut soumettre une entrée forgée au point d’accès AuthFormServlet : les données d’authentification sont alors traitées par un shell, ce qui permet d’exécuter des commandes arbitraires avec les privilèges root.
La seconde, CVE-2026-90823, est un débordement de tampon sur la pile (CWE-121) dans le binaire /usr/sbin/auth_user_pass. Une requête d’authentification forgée atteint une copie non vérifiée dans un tampon de taille fixe, ouvrant la voie à une exécution de code arbitraire en root.
Le score est identique et sans ambiguïté : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Réseau accessible, complexité faible, aucun privilège requis, aucune interaction utilisateur, impact élevé sur la confidentialité, l’intégrité et la disponibilité. La seule différence entre les deux failles est le mécanisme — un shell invoqué par une entrée non nettoyée d’un côté, une pile écrasée par une copie non bornée de l’autre — mais le résultat est le même : root sur l’appliance.
L’interface de gestion désactivée par défaut change la donne
Le détail qui tempère le tableau est dans l’avis lui-même. L’interface de gestion affectée est désactivée par défaut : elle doit être explicitement activée par le client avant que le point d’accès ne devienne joignable. Autrement dit, une appliance sortie de carton dans sa configuration d’usine n’expose pas ces failles tant que personne n’a ouvert l’accès d’administration.
C’est une nuance utile, pas une excuse. Les consoles de gestion des équipements réseau sont précisément activées parce qu’on a besoin de les administrer à distance — et c’est là qu’elles sont oubliées. FatPipe le reconnaît d’ailleurs dans sa propre recommandation : restreindre l’accès de gestion aux réseaux d’administration de confiance et utiliser des listes de contrôle d’accès WAN pour limiter les sources autorisées. Si l’éditeur conseille de fermer sa propre interface, c’est qu’elle n’a jamais été conçue pour affronter Internet.
Le vrai correctif n’existe plus
Le cœur du problème n’est pas la gravité des failles — 9,8 est courant pour ce type de vecteur — mais le statut du firmware. La version 10.1.2r60p100 est en fin de vie : FatPipe ne publiera pas de correctif pour elle. La seule issue logicielle est la migration vers une release actuellement supportée, ce qui transforme une mise à jour de routine en un projet de migration à planifier, tester et déployer.
Cette configuration est le pire des deux mondes. Une appliance VPN ou SD-WAN en fin de vie concentre trois défauts : elle n’est plus patchée, elle porte une fonction de bordure qui la place en première ligne, et elle sert de point d’entrée vers le réseau interne qu’elle protège. Chaque mois qui passe sans migration ajoute une couche de risque — non pas parce que l’appliance devient plus vulnérable, mais parce que la distance entre son état et l’état corrigé du monde s’élargit.
Le cas FatPipe n’est pas isolé. Les appliances VPN et de connexion à distance — SonicWall, Citrix, Fortinet, Ivanti, Pulse Secure — ont toutes connu des zero-day exploités en masse ces dernières années, souvent précisément parce que la console d’accès distant était joignable depuis Internet. La leçon est structurelle : une interface de gestion d’appliance de bordure n’a pas vocation à être exposée, qu’elle soit encore supportée ou non.
Ce qu’il faut faire
La remédiation se décline en trois actions, dans cet ordre.
- 1. Confirmer la version. Vérifier le firmware de chaque appliance MPVPN, WARP et IPVPN. Toute machine en 10.1.2r60p100 est concernée — FatPipe invite les clients à contacter son support pour confirmer la version et planifier la montée vers une release supportée.
- 2. Restreindre l’interface de gestion. Tant que la migration n’est pas faite, laisser l’interface désactivée si elle l’est encore, ou la restreindre aux seuls réseaux d’administration de confiance via des ACL WAN. C’est la mesure qui réduit réellement la surface d’attaque en attendant.
- 3. Programmer la migration. La fin de vie du firmware rend tout contournement provisoire. La sortie durable passe par une release supportée — à planifier comme une migration, pas comme un simple téléchargement.
Pour les équipes qui ne savent pas si l’interface est exposée, le réflexe est le même que pour toute appliance de bordure : un scan de surface des ports d’administration, une revue des règles de pare-feu qui les filtrent et une surveillance des journaux d’authentification pour repérer les tentatives anormales. Une appliance en fin de vie ne se découvre pas au moment de l’incident, mais au moment de l’inventaire.
Pourquoi ces appliances finissent en fin de vie sans alerter personne
La vraie question n’est pas technique, elle est organisationnelle. Une appliance VPN ou SD-WAN de bordure cumule les raisons de rester en place : elle fonctionne sans maintenance visible, sa migration est disruptive parce qu’elle touche le lien de toutes les agences ou de tous les télétravailleurs, et personne n’a la charge explicite de son cycle de vie. Résultat : le firmware glisse doucement vers la fin de vie sans qu’aucune alerte ne se déclenche — un équipement qui ne tombe pas en panne ne remonte jamais dans les priorités.
La fin de vie d’un firmware est pourtant un fait daté et public. FatPipe documente la version 10.1.2r60p100 comme obsolète, et la NVD indexe les failles qui la concernent. Le décalage entre la publication de ces informations et leur prise en compte dans les parcs est le vrai risque — pas la faille elle-même, mais le temps pendant lequel une machine exposée continue de tourner sur un firmware que l’éditeur ne maintiendra plus.
C’est ici que la veille doit se transformer en action de gouvernance : assigner un propriétaire à chaque appliance de bordure, inscrire sa date de fin de support dans l’inventaire, et faire de l’EOL un critère de remplacement au même titre qu’une panne. Une appliance en fin de vie n’est pas un actif qui vieillit, c’est une dette qui s’accumule.
Verdict
Si vous exploitez des appliances FatPipe en firmware 10.1.2r60p100, ne traitez pas ces deux CVE comme un patch à poser — il n’y en a pas. Votre seule issue est la migration vers une release supportée ; en attendant, désactivez ou restreignez immédiatement l’interface de gestion aux réseaux d’administration de confiance, car c’est elle qui rend les deux failles exploitables. Si l’appliance est encore en service en bordure de réseau, pesez le coût de la migration contre le coût d’un root aux mains d’un attaquant sur votre point d’entrée VPN — et planifiez la sortie de l’EOL comme un projet, pas comme un souhait.