Routeurs SOHO : 6 CVE critiques à exploit public (TRENDnet, ipTIME, Comfast, UTT)

Entre le 19 et le 24 août 2026, six vulnérabilités classées CVSS 9.9 à 10.0 ont été publiées sur des routeurs et points d'accès SOHO de quatre constructeurs différents. Elles ont trois caractéristiques communes : exploitation à distance, aucune authentification, et exploit déjà public pour les six.

Ce dernier point change tout dans la priorisation. Une CVE critique sans code d'exploitation reste théorique quelques semaines. Une CVE critique avec exploit publié sur un équipement identifiable à distance est scannée par des botnets dans les heures qui suivent.

Ces six CVE sont regroupées dans un seul article parce que le mode opératoire est presque identique d'un constructeur à l'autre — et que cette répétition est justement l'information la plus utile.

Les six CVE

Le motif qui se répète : le formulaire de configuration NTP

Deux de ces six CVE, sur deux constructeurs différents, se situent dans la fonction de configuration du fuseau horaire et du serveur NTP :

• CVE-2026-77946 — TRENDnet TEW-821DAP, fonction uci_safe_get dans /cgi-bin/apply_time.cgi, sur les arguments system.ntp.server, system.ntp.enable_server, cameo.time.time_zone et cameo.cameo.syslog_server
• CVE-2026-78050 — Comfast CF-N1-S, fonction sub_41AD7C dans /cgi-bin/mbox-config?method=SET&section=ntp_timezone, sur les arguments timestr et ntp_client_enabled

Ce n'est pas une coïncidence, et ça s'explique. Le formulaire NTP est l'un des rares écrans de configuration où l'utilisateur saisit du texte libre : un nom d'hôte de serveur de temps, une chaîne de fuseau horaire. Ces valeurs sont ensuite copiées dans des tampons de taille fixe, puis souvent passées à des appels système pour reconfigurer l'horloge. Sur des firmwares écrits en C sans borne de longueur, c'est un candidat naturel au débordement.

Le nom de la fonction TRENDnet est ironique : uci_safe_get. Le préfixe safe désigne vraisemblablement la lecture sécurisée d'un paramètre de configuration UCI — mais rien n'indique que la longueur de la valeur retournée soit contrôlée avant sa copie.

À noter aussi, dans le cas TRENDnet, l'argument cameo.cameo.syslog_server : un firmware sous marque TRENDnet mais construit sur une base Cameo, un fournisseur OEM. C'est le rappel que ces vulnérabilités sont souvent partagées entre plusieurs marques revendant le même firmware sous un autre nom — donc que le périmètre réel peut dépasser les modèles nommés dans la CVE.

La plus grave n'est pas un débordement

CVE-2026-78167 (ipTIME T16000M, CVSS 10.0) sort du lot par sa nature :

The impacted element is the function httpcon_check_session_url of the component Session Validation Handler. This manipulation causes improper authentication. Remote exploitation of the attack is possible. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Deux choses la rendent pire que les cinq autres.

C'est un contournement d'authentification, pas une corruption mémoire. Un débordement de pile demande un exploit adapté à l'architecture et au firmware exact ; il peut échouer, faire planter l'équipement, nécessiter des ajustements. Contourner la validation de session, c'est juste envoyer la bonne requête. Fiable, reproductible, silencieux, sans plantage qui alerterait l'administrateur.

Le constructeur n'a pas répondu à la divulgation. Il n'y a donc aucun correctif à attendre. C'est la même situation que celle rencontrée sur les 22 CVE du routeur Totolink A8000RU : quand l'éditeur est silencieux, la seule mitigation réelle est l'isolation ou le remplacement.

Produits et versions affectés

Les données NVD n'exposent pas de version corrigée pour ces six CVE au moment de la rédaction. Je ne vais pas inventer de numéro : il faut consulter la page support de chaque modèle. Et pour l'ipTIME T16000M, l'absence de réponse du constructeur rend improbable la publication d'un correctif.

Exploitation et impact

Pourquoi ces équipements sont scannés en priorité

• Identifiables à distance : la bannière HTTP, le chemin des ressources statiques et la structure des URL CGI suffisent à reconnaître le modèle et souvent la version. Le ciblage s'automatise trivialement.
• Exposés par défaut : l'administration distante est activée sur une part significative des installations, parfois par le fournisseur d'accès, parfois par l'utilisateur qui voulait accéder à sa caméra.
• Jamais patchés : personne ne surveille les mises à jour d'un point d'accès installé dans un faux plafond il y a quatre ans.
• Exploits publics : aucune compétence de recherche n'est requise, seulement la capacité à lancer un scan.

Ce qui se passe après

Sur un routeur ou un point d'accès compromis :

• Interception du trafic : le routeur voit tout ce qui transite. Modifier les serveurs DNS suffit à rediriger les utilisateurs vers des pages de phishing sans toucher à leurs postes.
• Pivot vers le LAN : caméras IP, NAS, imprimantes, automates — tout ce qui est derrière devient accessible depuis l'extérieur.
• Enrôlement dans un botnet : c'est le débouché le plus fréquent. Les dérivés de Mirai ciblent exactement cette catégorie d'équipements, et une fois enrôlé le routeur participe à des attaques dont l'adresse IP de ton organisation est l'origine visible.
• Persistance quasi indétectable : sans agent, sans journal exporté, sans supervision, un routeur compromis fonctionne normalement pendant des années.

Ce dernier point mérite d'être souligné. Contrairement à un serveur, rien ne signale le problème : la connexion marche, le Wi-Fi marche, les utilisateurs ne se plaignent pas. L'équipement continue de faire exactement ce qu'on attend de lui, en plus de ce que l'attaquant en attend.

Audit à mener

1. Recenser ce qui est réellement joignable depuis l'extérieur

C'est le contrôle qui a le meilleur rapport effort/résultat, et il vaut pour l'ensemble de ton parc réseau, pas seulement ces six modèles :

# Depuis une connexion EXTERNE, pas depuis le réseau interne
nmap -Pn -p 80,443,8080,8443,8081 <ip-publique>

Toute interface d'administration qui répond depuis Internet est un problème indépendamment de toute CVE.

2. Inventorier les modèles et versions de firmware

La question à laquelle il faut pouvoir répondre en quelques minutes : quels modèles de routeurs et de points d'accès sont déployés, en quelle version, et où ? Si la réponse demande une journée d'enquête, c'est le vrai problème à corriger.

3. Chercher les signes de compromission

Sur chaque équipement accessible :

• Serveurs DNS — un DNS modifié est le signal le plus fréquent et le plus révélateur
• Redirections de ports non documentées
• Comptes administrateurs inconnus
• Règles de pare-feu ajoutées
• Trafic sortant initié par l'équipement lui-même vers des destinations non liées à son fonctionnement (visible depuis l'équipement amont)

Mitigation

1. Couper l'administration distante

Applicable immédiatement, sans coût, et efficace contre les six CVE ainsi que les prochaines :

Interface d'administration → Gestion / Administration
  → désactiver « Accès distant » / « Remote management »

Cinq des six CVE deviennent inexploitables depuis Internet dès cette mesure appliquée.

2. Restreindre l'accès interne à l'interface d'administration

Le prérequis des six CVE est l'accès réseau à l'interface web. Sur un réseau segmenté, l'administration ne devrait être joignable que depuis un VLAN de management, jamais depuis le Wi-Fi invité ni depuis le VLAN utilisateurs.

Vérifie en particulier que ton réseau invité est réellement isolé de l'interface d'administration de l'équipement qui le sert. C'est une erreur de configuration extrêmement répandue.

3. Mettre à jour le firmware quand un correctif existe

Consulte la page support de chaque modèle. Pour les cinq constructeurs qui répondent encore, un correctif est possible.

4. Pour l'ipTIME T16000M : remplacer ou isoler

Constructeur silencieux, CVSS 10.0, contournement d'authentification, exploit public. Il n'y a pas de troisième option :

• Remplacer l'équipement par un modèle dont le constructeur maintient le firmware
• Ou l'isoler strictement : aucune exposition Internet, administration accessible depuis une seule IP de management, et considérer le LAN derrière comme potentiellement exposé

5. Si tu conclus à une compromission

Sur un équipement réseau compromis au niveau firmware, le nettoyage à chaud n'est pas fiable :

1. Réinitialisation d'usine, puis reconfiguration manuelle — ne restaure pas une sauvegarde, elle peut contenir la configuration altérée
2. Change tous les mots de passe : administration, PSK Wi-Fi, et les credentials de tout service dont le trafic a transité par l'équipement
3. Audite le LAN derrière : un routeur compromis a pu servir de point d'observation sur l'ensemble du trafic

Pourquoi surveiller en continu votre parc réseau

Ces six CVE illustrent un angle mort structurel. Les routeurs, points d'accès et petits équipements réseau n'apparaissent dans aucun inventaire logiciel : pas d'agent, pas de remontée dans les scans d'OS, et souvent aucun propriétaire déclaré côté IT parce qu'ils ont été installés par un prestataire ou un fournisseur d'accès. Ajoute à cela des constructeurs qui ne publient pas d'advisory, ou qui ne répondent pas du tout, et la question « suis-je concerné ? » devient une enquête de plusieurs jours — pendant lesquels les exploits publics circulent.

Avec cveo.tech, inventorie tes routeurs, points d'accès et équipements réseau au même titre que tes serveurs, et reçois une alerte automatique dès qu'une CVE critique cible une de tes versions exactes. Pour que l'arrivée d'un exploit public sur un modèle de ton parc soit une notification, pas une découverte.