Juniper corrige une faille qui donne le root du Session Smart Router avant son onboarding
Le 28 octobre 2026, Juniper corrige CVE-2026-103409, une authentification manquante (CVSS 9,8) qui livre les privilèges root du Session Smart Router à un attaquant réseau non authentifié tant que l’appareil n’est pas onboardé vers Mist ou Conductor. Montez vers 7.0.5, 7.1.7 ou 7.2.3 et onboardez immédiatement les boîtiers neufs, car c’est la fenêtre de provisioning qui est exposée.
28 octobre 2026. Juniper Networks publie JSA112183, un bulletin consacré au Session Smart Router (SSR), sa plateforme de routage SD-WAN héritée de l’acquisition de 128 Technology en 2020. CVSS 9,8. La faille, CVE-2026-103409, atteint le niveau critique. Aucune authentification. L’attaquant n’a besoin d’aucun compte pour prendre la main. Le point qui compte n’est pas le score, mais la condition d’exploitation, qui défie l’intuition : la faille n’est exploitable que tant que l’appareil n’est pas connecté à la plateforme cloud de Juniper.
Un endpoint root ouvert avant l’onboarding
La vulnérabilité est classée CWE-306, « authentification manquante pour une fonction critique ». Concrètement, le Session Smart Router expose un endpoint interne qui s’exécute avec les privilèges root et n’exige aucune authentification. Un attaquant situé sur le réseau, sans compte valide, peut y transmettre des paramètres d’URL forgés et obtenir des privilèges administratifs — puis, depuis cette position, un contrôle complet du routeur de bordure.
Le vecteur CVSS résume la gravité : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Réseau en vecteur d’attaque, complexité faible, aucun privilège requis, aucune interaction utilisateur, et des impacts hauts sur la confidentialité, l’intégrité et la disponibilité. C’est le profil type d’une faille que l’on ne veut pas laisser traîner sur un équipement qui fait face à Internet ou qui relie des sites distants.
La restriction tient en une phrase du bulletin : « cette vulnérabilité ne peut être exploitée qu’avant l’onboarding de l’appareil vers Mist/Conductor. Une fois l’appareil onboardé, elle ne peut plus l’être. » Autrement dit, le trou se referme par la connexion au cloud, pas par le patch seul — une mécanique rare, et lourde de conséquences opérationnelles.
La fenêtre paradoxale : le boîtier est vulnérable tant qu’il est « neuf »
C’est ici que la faille devient intéressante pour un exploitant. Le Session Smart Router est un routeur de bordure destiné à être déployé sur site, branché au réseau, puis rattaché à Mist ou Conductor, les contrôleurs cloud de Juniper. Entre le déballage et l’onboarding, il existe une fenêtre de provisioning pendant laquelle l’appareil est configuré, adressé, parfois testé — et, selon le bulletin, exposé.
Pendant cette fenêtre, l’endpoint vulnérable est joignable depuis le réseau sur lequel l’appareil est branché. Or un routeur de bordure fraîchement déballé est rarement placé derrière un pare-feu de gestion strict : on le raccorde, on le configure, on le met en production, puis on l’onboarde. Si l’onboarding intervient en fin de processus, la machine est vulnérable pendant toute la phase d’installation — exactement le moment où elle est le plus visible, parfois sur un réseau encore en cours de segmentation.
La conséquence est double. D’une part, l’onboarding n’est pas optionnel : c’est lui qui désactive la surface d’attaque, au-delà du correctif logiciel. D’autre part, un parc qui déploie des SSR en série — une chaîne de magasins, une flotte de sites industriels, un opérateur qui provisionne des routeurs en usine — expose potentiellement chaque boîtier neuf le temps de sa mise en service. La faille ne demande ni exploit sophistiqué ni accès préalable : il suffit d’être sur le réseau au bon moment.
Versions affectées et remédiation
Le périmètre est précis. Sont affectées les versions du Session Smart Router antérieures à 7.0.5, 7.1.7 et 7.2.3. Les correctifs sont livrés dans ces trois versions et toutes les suivantes. Les trois branches maintenues sont donc couvertes, mais aucune solution de contournement n’existe : le bulletin ne propose pas de mitigation intermédiaire côté configuration. La seule parade hors patch est de bloquer le trafic réseau interne vers l’endpoint vulnérable, ou d’onboarder l’appareil le plus tôt possible.
Le contexte de risque est, lui, mesuré. La CVE-2026-103409 n’est pas inscrite au catalogue KEV de la CISA au 31 octobre 2026, et son score EPSS reste inférieur à 1 % — un signal statistique de probabilité d’exploitation faible à court terme. Mais l’EPSS ne capture pas le scénario le plus probable ici : non pas une campagne automatisée à grande échelle, mais une compromission opportuniste d’un boîtier encore en cours de déploiement, ciblée ou fortuite.
# Vérifier la version d'un Session Smart Router et son état d'onboarding
show system version
show system software
# L'absence de ligne « conductor » ou « mist » indique un appareil non onboardé
show system platformUne flotte qui ne peut pas monter de version immédiatement doit, à défaut, restreindre l’accès réseau à l’appareil pendant sa mise en service : un segment de gestion isolé, un access-list dédié, ou un délai de provisioning minimal avant la mise en production.
Un produit de bordure, à ne pas confondre avec Junos
Une clarification d’inventaire s’impose avant d’agir. Le Session Smart Router n’est pas un routeur Junos OS : c’est une plateforme SD-WAN distincte, issue du rachat de 128 Technology en 2020, qui route à la session plutôt qu’au paquet. Le bulletin JSA112187 du 14 octobre corrigeait plus de 60 failles dans Junos ; JSA112183 du 28 octobre concerne ce produit de bordure différent. Les deux ne partagent ni le même code ni la même surface d’attaque, et un inventaire qui les confond risque de passer à côté de la présente faille en croyant l’avoir déjà traitée.
Ce positionnement de bordure explique aussi la mécanique de la vulnérabilité. Pour permettre un déploiement zero-touch, sans console ni opérateur sur site, l’appareil expose des services de bootstrap — découverte, enrôlement, configuration initiale — avant qu’aucune identité n’existe. L’endpoint vulnérable est un vestige de cette phase d’apprivoisement : il tourne en root, sans authentification, précisément parce qu’il doit fonctionner avant l’onboarding. Le compromis est structurel, et il ne se règle qu’en refermant cette fenêtre au plus vite.
La détection se ramène à deux questions d’inventaire. Quels SSR sont encore en cours de déploiement, ou simplement jamais onboardés ? Et depuis quel réseau leur interface est-elle joignable ? Un appareil rattaché à Mist/Conductor n’est plus concerné ; un appareil qui traîne hors du cloud depuis des semaines cumule, lui, la version vulnérable et la surface ouverte. C’est cette population — les boîtiers oubliés entre deux phases de déploiement — qu’il faut identifier en priorité, car elle cumule les deux conditions d’exploitation.
Le contexte ne fait qu’alourdir l’enjeu. Les passerelles SD-WAN sont devenues des cibles de choix : elles concentrent les tunnels, les clés et la politique de segmentation de tout un parc, et elles sont déployées en grand nombre sur des sites peu surveillés. Une compromission du routeur de bordure ne livre pas qu’un boîtier — elle livre une position de départ vers le cœur du réseau, au-delà des pare-feux périmétriques. C’est pour cette raison qu’un score EPSS faible et l’absence d’inscription au KEV ne doivent pas être lus comme un feu vert : le coût d’une compromission de ce type se mesure en heures d’indisponibilité de dizaines de sites, pas en probabilité statistique.
Verdict
Si vous déployez des Session Smart Router, traitez la fenêtre de provisioning comme une surface d’attaque à part entière. Montez vers 7.0.5, 7.1.7 ou 7.2.3 selon votre branche, et onboardez chaque boîtier vers Mist ou Conductor immédiatement — pas après la validation, pas après la mise en production, mais dès le premier branchement. Si vous provisionnez des routeurs en volume, ajoutez l’onboarding à la checklist d’usine et isolez le réseau de mise en service jusqu’à ce qu’il soit fait. Et si vous pensiez qu’un boîtier neuf est un boîtier sain, cette CVE est le contre-exemple exact : ici, c’est l’état « neuf et non rattaché au cloud » qui est vulnérable, et c’est la connexion au cloud qui verrouille la machine.