Une vulnérabilité zero-day récemment révélée dans des équipements réseau largement déployés a exposé des dizaines de milliers d’organisations à une compromission complète de leurs systèmes, alors qu’aucun correctif du fournisseur n’est actuellement disponible.
La faille permet à des attaquants de prendre à distance le contrôle total des appareils affectés — sans authentification —, suscitant de vives inquiétudes pour les entreprises qui s’appuient sur des infrastructures edge et SD-WAN.
« … il s’agit de la première RCE zero-day exploitable à distance découverte par un agent, » ont déclaré les chercheurs de pwn.ai dans leur rapport.
Portée et impact potentiel de la faille zero-day de SXZOS
La vulnérabilité affecte SXZOS, le firmware central utilisé par XSpeeder, un fournisseur chinois d’équipements réseau. Les produits concernés comprennent des appliances SD-WAN, des routeurs edge et des contrôleurs de téléviseurs connectés.
Selon les chercheurs, plus de 70 000 systèmes basés sur SXZOS sont actuellement exposés en ligne.
Anatomie de la faille d’exécution de code à distance de SXZOS
À la base, la vulnérabilité (CVE-2025-54322) découle d’un traitement non sécurisé des entrées au sein d’une application web basée sur Django et intégrée au firmware SXZOS.
Les chercheurs ont identifié une faille critique dans le point de terminaison /webInfos/ qui accepte plusieurs paramètres HTTP GET et les traite sans appliquer de validation ni de nettoyage pertinents des entrées.
Ce point de terminaison est accessible avant l’authentification et est exposé par défaut sur les interfaces d’administration accessibles depuis Internet.
Le problème le plus grave concerne le paramètre chkid. SXZOS décode ce paramètre depuis le format base64, puis transmet directement la valeur décodée à la fonction Python eval().
Comme eval() exécute des expressions Python arbitraires, toute entrée contrôlée par un attaquant qui parvient jusqu’à cette fonction est considérée comme du code de confiance.
Cette conception abolit de fait la frontière entre les données et la logique exécutable, créant un mécanisme direct d’exécution de code à distance.
Pour exploiter la faille, un attaquant élabore une requête dans laquelle des charges utiles Python malveillantes sont encodées en base64, puis intégrées au paramètre chkid.
Une fois décodée, la charge utile est évaluée dans le contexte de l’application web, ce qui permet d’exécuter immédiatement des commandes avec des privilèges de niveau root sur le système d’exploitation sous-jacent.
Les attaquants peuvent ainsi installer des portes dérobées, modifier les configurations réseau, intercepter le trafic ou se déplacer latéralement vers des environnements connectés.
SXZOS met effectivement en œuvre plusieurs mécanismes défensifs destinés à restreindre l’accès aux points de terminaison sensibles.
Ils comprennent un en-tête nonce synchronisé dans le temps (X-SXZ-R) conçu pour empêcher les attaques par rejeu, l’obligation d’initialiser un cookie de session avant d’accéder à certaines routes et un filtre d’entrée rudimentaire fondé sur la recherche de sous-chaînes, destiné à bloquer les motifs malveillants connus.
Cependant, ces protections sont appliquées au niveau des couches middleware et Nginx, plutôt que dans la logique même de l’application vulnérable.
Comme la logique de filtrage opère sur des entrées préalablement décodées et repose sur une correspondance statique de motifs, elle peut être contournée par l’encodage et une légère obfuscation de la charge utile.
Lorsqu’un attaquant respecte la structure et les exigences temporelles attendues pour la requête, celle-ci est transmise telle quelle à la vue Django, où l’appel à eval() non sécurisé est exécuté.
Par conséquent, les défenses en couches ne constituent qu’un obstacle superficiel et ne réduisent pas réellement la facilité d’exploitation.
La chaîne d’attaque globale est peu complexe et ne nécessite ni authentification, ni accès particulier, ni interaction de la part d’utilisateurs légitimes.
Les chercheurs n’ont pas fait état d’une exploitation active au moment de la publication.
Réduire les risques sans correctif
Puisque l’exploitation ne nécessite aucune authentification et cible des interfaces d’administration accessibles depuis Internet, les mesures défensives doivent donner la priorité à la réduction de l’accès, à la visibilité et au confinement.
- Retirer les interfaces d’administration SXZOS de toute exposition directe à Internet et restreindre l’accès au moyen de listes d’autorisation IP ou de listes de contrôle d’accès lorsque l’accès externe est inévitable.
- Mettre en place une segmentation réseau robuste et limiter les relations de confiance afin de réduire les déplacements latéraux et de contenir une éventuelle compromission.
- Bloquer ou restreindre l’accès au point de terminaison /webInfos/ vulnérable à l’aide de pare-feu, de reverse proxies ou de règles de pare-feu applicatif.
- Surveiller et journaliser de manière centralisée le trafic HTTP, les événements système et les modifications de configuration afin de détecter les activités suspectes et de faciliter la réponse aux incidents.
- Durcir les configurations des appareils en désactivant les services inutiles, en appliquant des restrictions au trafic sortant et en imposant une limitation du débit sur les interfaces d’administration.
Puisque le fournisseur n’a pas encore publié de correctif, ces mesures contribuent à réduire les risques et à limiter l’ampleur d’une éventuelle compromission.
Les appareils edge exposés élargissent la surface d’attaque
Cette vulnérabilité illustre la manière dont plusieurs facteurs de risque courants des infrastructures modernes se recoupent de plus en plus, notamment les pratiques de développement de firmware non sécurisées, l’exposition généralisée des appareils edge et la réactivité inégale des fournisseurs face aux problèmes de sécurité.
Elle montre également comment les progrès de la recherche autonome en sécurité permettent une analyse plus rapide et plus approfondie des systèmes embarqués, révélant souvent des failles critiques plus vite que les processus traditionnels de correction des fournisseurs ne peuvent suivre.
Pris ensemble, ces facteurs renforcent la nécessité de modèles de sécurité qui partent du principe qu’une compromission peut survenir et mettent l’accent sur des contrôles d’accès stricts et la segmentation, des principes au cœur des architectures zero-trust.