CVE-2026-0625 : Injection de commande non authentifiée dans les anciennes passerelles DSL de D-Link.

Pourquoi cette CVE est-elle importante au-delà du titre CVSS ?

CVE-2026-0625 est une Injection de commandes du système d'exploitation (mappé à CWE-78) affectant plusieurs passerelle DSL D-Link héritée appareils. La surface vulnérable est la pile de gestion web intégrée de l'appareil, en particulier le module dnscfg.cgi utilisé pour la configuration du DNS. Les paramètres DNS n'étant pas correctement assainis, un attaquant non authentifié peut injecter des métacaractères shell et obtenir ainsi l'exécution de code à distance (RCE). L'ANC (VulnCheck) a attribué une valeur de CVSS 9.3 (critique) score. (NVD)

Mais l'impact opérationnel ne se limite pas à un "RCE critique". La véritable histoire est la suivante gravité du cycle de vieCes appareils sont en fin de vie ou en fin de support, et les orientations publiques convergent systématiquement vers l'adoption d'un système de gestion de la qualité. se retirer et remplacer plutôt que d'appliquer des correctifs. En d'autres termes, les défenseurs sont contraints de mettre en place des contrôles compensatoires - réduction de l'exposition du réseau, segmentation et surveillance de l'intégrité du DNS - parce que la correction des microprogrammes est souvent exclue. (supportannouncement.us.dlink.com)

Ce qui est touché (confirmé) et ce qui reste incertain

Les rapports publics fournissent un ensemble concret et confirmé de modèles et de gammes de microprogrammes concernés. VulnCheck et la couverture en aval listent les éléments suivants (notez les plages d'inégalité) :

La nuance importante : D-Link affirme qu'il y a il n'existe pas de moyen fiable de déterminer les modèles concernés en se basant uniquement sur le numéro de modèleLa bibliothèque CGI vulnérable peut varier d'une version à l'autre du micrologiciel ; la vérification peut nécessiter l'utilisation d'un logiciel de gestion de l'information. inspection directe du microprocesseur. (supportannouncement.us.dlink.com)

Il s'agit d'un piège classique dans la gestion des vulnérabilités des appareils périphériques : les étiquettes d'inventaire ne correspondent pas toujours clairement à la lignée logicielle. Si vous exploitez des transporteurs, des succursales ou des passerelles "shadow IT", supposez que votre exposition est plus large que le tableau à quatre rangées jusqu'à preuve du contraire.

Contexte d'exploitation : comment les attaquants atteignent dnscfg.cgi dans des environnements réels

L'expression dominante à fort taux de clics dans les titres les mieux classés est essentiellement un composé : "zero-day activement exploité / RCE critique / routeurs en fin de vie". Vous verrez la même accroche répétée par les principaux organismes de sécurité parce qu'elle comprime trois signaux d'urgence en une seule ligne : l'exploitation a lieu maintenant, l'impact est l'exécution complète du code et l'application d'un correctif est peu probable. (The Hacker News)

Du point de vue du défenseur, la question pratique n'est pas "est-ce exploitable ?". (elle l'est), mais "Mon avion de gestion est-il joignable ? De nombreuses passerelles DSL grand public exposent des points d'extrémité CGI administratifs uniquement sur le réseau local par défaut. BleepingComputer note que l'exploitation de CVE-2026-0625 peut impliquer un chemin d'accès basé sur un navigateur ou un dispositif configuré pour l'administration à distance, étant donné que de nombreuses configurations limitent les points de terminaison de gestion tels que dnscfg.cgi aux réseaux locaux. (BleepingComputer)

Cela dit, la compromission d'un appareil périphérique n'exige pas que l'administration du réseau étendu soit activée dans tous les cas de figure. Une fois qu'un attaquant a pris pied dans un réseau (hameçonnage, point d'extrémité compromis, extension malveillante ou service exposé), l'interface Web du routeur devient une cible à fort potentiel. La raison en est la suivante Contrôle DNSSi un attaquant peut modifier les résolveurs DNS au niveau de la passerelle, chaque appareil en aval hérite d'une primitive de pilotage silencieuse du trafic.

L'historique de D-Link établit un lien entre ce type de comportement et GhostDNS/DNSChanger campagnes : recherche de mots de passe par rapport aux identifiants par défaut (par exemple, admin/admin), recherche de chemins CGI exposés tels que dnscfg.cgiet de réécrire les valeurs DNS pour rediriger les utilisateurs vers l'infrastructure de l'attaquant. (supportannouncement.us.dlink.com)

Ce qu'il faut faire aujourd'hui : une vérification sûre sans militariser le bogue

Vous trouverez ci-dessous un flux de travail défendable pour les équipes de sécurité. Il se concentre sur identification de l'exposition et Contrôles d'intégrité du DNS-ne pas exploiter la reproduction.

Étape 1 : Trouver votre exposition potentielle à l'avion de gestion

Commencez par découvrir les actifs :

• Les adresses IP orientées vers l'internet qui exposent HTTP(S) sur des ports communs et peu communs (80/443/8080/8443, etc.).
• Les succursales et les installations de connectivité "temporaires" (les endroits où les passerelles traditionnelles persistent).
• Enregistrements DNS publics qui correspondent aux points d'extrémité de gestion du CPE (parfois désignés à tort comme "surveillance" ou "administration").

Étape 2 : Vérifier si dnscfg.cgi est accessible (pas de charge utile)

Cet extrait Python effectue une simple vérification de l'accessibilité et des limites de l'authentification.

demandes d'importation

def probe_dnscfg(base_url : str, timeout=6) :
    url = base_url.rstrip("/") + "/dnscfg.cgi"
    try :
        r = requests.get(url, timeout=timeout, allow_redirects=False)
        return {
            "url" : url,
            "status" : r.status_code,
            "server" : r.headers.get("Server", ""),
            "www_authenticate" : r.headers.get("WWW-Authenticate", ""),
            "location" : r.headers.get("Location", ""),
        }
    except requests.RequestException as e :
        return {"url" : url, "error" : str(e)}

targets = [
    "",
    # "",
]

for t in targets :
    print(probe_dnscfg(t))

Conseils d'interprétation :

• 200 sans authentification → votre plan de gestion peut être dangereusement exposé.
• 401/302 pour se connecter → risque toujours élevé si les informations d'identification sont faibles, réutilisées ou manquantes.
• Les erreurs/temporisations → peuvent indiquer un filtrage, un service non HTTP ou une absence pure et simple.

Étape 3 : Traiter les changements de DNS comme un indicateur de compromission primaire

Étant donné que CVE-2026-0625 se trouve sur le chemin de la configuration DNS, la question la plus pratique en matière de détection est de savoir si mes résolveurs ont changé. D-Link décrit explicitement les flux de travail de DNSChanger comme la réécriture du DNS du routeur pour rediriger le trafic bancaire et d'autres trafics de grande valeur. (supportannouncement.us.dlink.com)

Sur le plan opérationnel :

• Validez les résolveurs DNS configurés par le routeur par rapport à votre ligne de base approuvée.
• Valider le DNS géré par DHCP sur les clients échantillonnés (Windows ipconfig /all, macOS scutil --dns).
• Alerter sur les changements soudains de résolveur, en particulier vers des plages résidentielles ou des ASN inhabituels.

Atténuation des risques lorsque l'application de correctifs n'est pas envisageable : un guide des priorités

La couverture médiatique et les messages des fournisseurs insistent sur le fait que les modèles concernés sont anciens et doivent être remplacés ; SecurityWeek déclare explicitement que aucun correctif ne sera publié et conseille aux propriétaires de prendre leur retraite et de les remplacer. (SecurityWeek)

Une échelle d'atténuation pragmatique :

1) Remplacer (le seul état final propre).

Si l'appareil est EOL/EOS, la modernisation est une réduction des risques que l'on peut réellement mesurer.

2) Réduire la surface d'attaque.

Désactiver l'administration côté WAN, bloquer l'accès entrant aux ports de gestion à la périphérie du FAI et restreindre l'accès administrateur à un VLAN de gestion renforcé.

3) Rayon d'explosion du segment.

Séparer la gestion du routeur, les points d'extrémité des utilisateurs, l'IoT et les réseaux d'invités. Supposons qu'un compromis interne se produise ; concevez-le de manière à ce qu'il ne devienne pas un contrôle DNS de tout.

4) Hygiène des diplômes.

Les identifiants par défaut et les mots de passe faibles restent un thème récurrent dans les récits de GhostDNS/DNSChanger. (supportannouncement.us.dlink.com)

5) Contrôles de l'intégrité du DNS.

Dans la mesure du possible, imposez des résolveurs approuvés et surveillez les écarts. Même si une passerelle existante est compromise, votre détection devrait se déclencher en cas de dérive du résolveur.

CVE connexes : le modèle le plus large que vous devez optimiser

CVE-2026-0625 correspond à un modèle d'exploitation répétitif : dispositif périphérique + gestion du web + injection/ contournement + balayage compatible avec l'automatisation. C'est la raison pour laquelle ces problèmes attirent l'attention des botnets et que la fin de vie est un multiplicateur si douloureux.

Quelques parallèles à signaux élevés :

• CVE-2023-1389 (TP-Link Archer AX21) : NVD décrit une injection de commande non authentifiée dans l'interface de gestion web, et TP-Link reconnaît les rapports sur l'ajout du CVE à l'arsenal du botnet Mirai. (NVD)
• CVE-2024-3400 (Palo Alto Networks PAN-OS GlobalProtect) : L'avis de PAN décrit cette situation comme une chaîne menant à l'exécution de codes au niveau de la racine pour des configurations spécifiques, illustrant la manière dont le "Edge RCE" passe du consommateur au périmètre de l'entreprise. (security.paloaltonetworks.com)
• CVE-2024-12987 (DrayTek Vigor) : Armis le décrit comme une injection de commande OS critique dans un gestionnaire de gestion web de routeur. (Armis)

Si vous élaborez une rubrique de hiérarchisation des vulnérabilités, envisagez d'encoder ceci comme une règle : Les vulnérabilités du plan de gestion sur les appareils périphériques bénéficient d'une priorité élevéeMême si les produits concernés ne sont que quelques routeurs, le contrôle qu'ils exercent (DNS, routage, NAT) amplifie la compromission en aval.

Flux de travail négligent : De la découverte d'actifs aux rapports sur la chaîne de preuves

Si votre flux de travail inclut Penligent, CVE-2026-0625 est un candidat de choix pour un projet de recherche. pipeline répétable de l'exposition à la preuvePenligent : découvre les surfaces d'administration accessibles par Internet, prend des empreintes digitales et établit des corrélations entre les actifs en périphérie, et génère un rapport sur la chaîne de preuves indiquant où les plans de gestion sont accessibles et s'il existe un comportement suspect en matière de configuration DNS. Le positionnement public et la documentation de Penligent mettent l'accent sur l'orchestration des tests et la production de rapports à travers des flux de travail de bout en bout. (Penligent)

En pratique, la valeur n'est pas un " exploit en un clic ". Elle est opérationnelle : transformer la réalité désordonnée des dispositifs de périphérie existants en un programme de remédiation traçable (remplacer, restreindre, segmenter), soutenu par des artefacts sur lesquels vos propriétaires informatiques peuvent agir.

Liens de référence faisant autorité

• NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-0625 (NVD)
• Avis de D-Link (SAP10488) : https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10488 (supportannouncement.us.dlink.com)
• Avis de VulnCheck : https://www.vulncheck.com/advisories/dlink-dsl-command-injection-via-dns-configuration-endpoint (VulnCheck)
• CWE-78 : https://cwe.mitre.org/data/definitions/78.html (NVD)
• Couverture de BleepingComputer (versions + contexte du cycle de vie) : https://www.bleepingcomputer.com/news/security/new-d-link-flaw-in-legacy-dsl-routers-actively-exploited-in-attacks/ (BleepingComputer)